Linux-ядро

[Zhek@Ch]

[size="3"]Линус Торвальдс намерен выпустить вместо Linux-ядра 2.6.40 версию 3.0 [/size]

Линус Торвальдс опубликовал в списке рассылки разработчиков Linux-ядра сообщение, в котором кроме обычного напоминания о необходимости своевременной отправки патчей для будущей версии Linux ядра указал на то, что число выпусков в рамках ветки 2.6.x уже слишком велико, поэтому возможно имеет смысл выпустить вместо версии 2.6.40 релиз 2.8.0. В отличие от ранее возникавших дискуссий, не ушедших дальше обсуждений, переход к новой нумерации на этот раз можно приурочить к празднованию двадцатилетия с момента появления ядра Linux и завершению работы по реорганизации кода, связанного с платформой ARM.

В процессе обсуждения некоторые разработчики склоняются к мысли, что вместо 2.8.0 следует выпустить релиз 3.0.0 или кардинально реформировать процесс нумерации ядра. Тем не менее для обеспечения совместимости с различными системами сборки и системными скриптами в дистрибутивах, общее представление X.Y.Z планируется сохранить. Например, возможна привязка номеров к дате выпусков без изменения привычного трехзнакового представления (номер 3.1.1 можно рассматривать, как первый выпуск в 2011 году, 3.1.2 - как второй и т.п.). Другой вариант - отбрасывание префикса "2.6." и разбиение последних двух цифр номера (вместо 2.6.39 использовать версию 3.9, а вместо 2.6.40 - 4.0). Некоторые разработчики предлагали перейти к формату версий "Год.Номер.Корректирующий_номер" или "Год.Месяц.Корректирующий_номер" (например, 2011.0.0, 11.0.0 или 2011.5.0), но подобные схемы были отклонены, как нарушающие привычное представление версий ядра.

В итоге, был выделен наиболее оптимальный вариант, который скорее всего будет принят в качестве окончательного. В соответствии с предложенным методом, вместо версии 2.6.40 будет выпущен релиз 3.0.0, при этом вторая цифра будет указывать на номер версии, а третья на корректирующий выпуск. Т.е. после 3.0.0 будет представлен выпуск 3.1.0, за ним 3.2.0, 3.3.0 и т.д. В процессе накопления патчей корректирующие обновления будут представлены как 3.0.1 вместо 2.6.40.1, 3.0.2 вместо 2.6.40.2 и т.д. В будущем не исключено появление ветки 4.x.y, в качестве критериев выпуска которой названы нарушающие совместимость кардинальные изменения или накопление примерно 40 обычных версий. Цифра 40 выбрана, так как при текущем темпе разработки на выпуск 40 версий уходит примерно 10 лет, таким образом версия 4.0.0 будет выпущена в 2021 году, после того как ядру исполнится 30 лет.

В релизе 3.0.0 не ожидается кардинальных изменений, связанных с глобальной переработкой ключевых подсистем или нарушением совместимости. По своей сути версия 3.0.0 не будет отличаться от 2.6.40 - различия будут только в изменении номера ветки. В 2004 был совершен уход от схемы с разделением нестабильных и стабильных веток (X.Y.Z, четная Y - стабильная, нечетная - нестабильная) в сторону непрерывного цикла подготовки новых релизов с их последующей стабилизацией путем выпуска промежуточных кандидатов в релизы. Подобная модель разработки позволяет добавлять большие новшества не ломая при этом совместимости и не создавая отдельной нестабильной ветки.

# opennet.ru

[Zhek@Ch]

[size="3"]Представлен первый тестовый выпуск Linux-ядра 3.0 [/size]

Линус Торвальдс анонсировал выход тестовой версии Linux-ядра 3.0-rc1, окончательно утвердив план по изменению нумерации версий. Таким образом версию 2.6.39 можно считать последним выпуском ветки 2.6.x, которая развивается уже около 10 лет.

В анонсе отдельно подчеркивается, что версию 3.0 не стоит считать каким-то кардинальным шагом, какой можно было наблюдать при появлении GNOME 3.0 или KDE 4.0. Linux-ядро 3.0 - это просто формальная смена нумерации, приуроченная к двадцатилетию проекта и десятилетию существования ветки 2.6.x, не более. Никаких серьезных нарушений совместимости или специальных новшеств не будет. Новое ядро плавно продолжит развитие текущей кодовой базы и по уровню нововведений будет сравнимо с версией 2.6.40. Процесс разработки также останется прежним.

Следующим после 3.0 выпуском станет версия 3.1, затем 3.2 и так далее, пока не пройдут очередные 10 лет или не возникнет потребность коренных изменений, связанных с глобальной переработкой ключевых подсистем или нарушением совместимости. В процессе накопления патчей корректирующие обновления будут представлены как 3.0.1, 3.0.2, 3.0.3 и т.п.

В представленной версии 3.0-rc1 около 2/3 всех изменений связаны с кодом драйверов устройств. Из других изменений можно отметить:

• Добавление реализации нового типа кэша Cleancache, который может использоваться ядром для хранения восстановимых из других источников данных, которые не страшно потерять, но при наличии ресурсов неплохо держать в памяти. Например, в Cleancache могут храниться ассоциированные с файлами на диске страницы памяти, которые в случае очистки кэша впоследствии могут быть перечитаны с диска. Поддержка CleanCache уже добавлена в Ext3, Ext4, Btrfs, OCFS2 и Xen. Cleancache является первой практической реализацией появившейся в ядре 2.6.39 техники трансцендентного управления памятью ("Transcendent memory"), позволяющей улучшить поведение системы при работе с не представляющими важность данными (например кэш) в условиях дефицита оперативной памяти. По сути Transcendent memory напоминает RAM-диск, имеющий ряд особенностей: размер RAM-диска не известен, запись данных не всегда может быть гарантирована и уже записанные данные могут быть очищены (удалены).
• Поддержка раздельных номеров файловых дескрипторов внутри изолированных пространств Namespace. Namespace является своеобразной легковесной техникой виртуализации, при которой некоторые процессы могут быть отрезаны от остальной системы, работая в отдельном пространстве имен и не влияя на другие части системы.
• Продолжение реорганизации кода, связанного с платформой ARM;
• Проведение оптимизации и чистки кода в подсистеме VFS;
• Добавление разработанного в рамках проекта OpenKinect драйвера для устройств Microsoft Kinect. В настоящее время драйвер способен принимать с устройства видеопоток, взаимодействуя с RGB-сенсором или монохромным сенсором, т.е. позволяет использовать Microsoft Kinect в роли web-камеры или инфракрасной камеры. Датчики глубины пока не поддерживаются;
• Обновлен код DRM-модулей Intel, Radeon и Nouveau. Проведена оптимизация производительности для гибридных процессоров Intel Sandy Bridge, обеспечена начальная поддержка Intel Ivy Bridge и AMD Fusion Llano APU;
• Добавлен недостающий storage-бэкенд Xen, который ознаменовал завершение добавления всех компонентов Xen, необходимых для работы Dom0 без установки дополнительных патчей;
• В код netfilter интегрирован JIT-компилятор правил, поддерживающий работу на системах x86-64, что позволит значительно увеличить производительность обработки пакетов пакетным фильтром.
• Для беспроводных карт Realtek представлен новый драйвер rtl8192se;
• Поддержка непривилегированных ICMP-сокетов, при помощи которых можно организовать работу ping и других отладочных утилит без предоставления дополнительных привилегий через suid-бит или capabilities.

# opennet.ru

[Zhek@Ch]

[size="3"]Обновление Linux-ядра: 2.6.38.8 и 2.6.39.1 [/size]

Представлены очередные корректирующие релизы Linux-ядра: 2.6.38.8 (144 исправления) и 2.6.39.1 (165 исправлений). Как обычно, в анонсе выхода новых версий подчеркивается обязательность проведения обновления.

Подсистемы, в которые внесены исправления: AppArmor, Ext4, Ext3, Xen, NFS, drm/radeon, drm/i915, tmpfs, UBIFS, eCryptfs, VFS, mac80211, iwlwifi, ath9k, USB, ALSA, bridge, netfilter, libata, SATA.

Из известных уязвимостей, исправленных в новых версиях ядра, можно отметить решение проблемы с разыменованием NULL-указателя в функции key_replace_session_keyring(), которую можно использовать для совершения локальной DoS-атаки.

# opennet.ru

[Zhek@Ch]

[size="3"]Для SoC Freescale i.MX51 и i.MX53 представлен открытый KMS-драйвер [/size]

Для Linux-ядра подготовлен новый открытый KMS-драйвер imx-ipu-kms (KMS - Kernel Mode Setting), в котором обеспечена поддержка SoC-платформ Freescale i.MX51 и i.MX53, используемых в таких устройствах, как планшеты под управлением Google Chrome OS. Возможности драйвера пока ограничены переключением видеорежимов на уровне ядра - поддержка механизмов управления видеопамятью GEM или TTM пока не реализована.

# opennet.ru

[Zhek@Ch]

[size="3"]Представлен набор патчей с поддержкой снапшотов для файловой системы Ext4 [/size]

Разработчики проекта NEXT3, в рамках которого уже несколько лет развивается неофициальная реализация поддержки мгновенных снимков состояния файловой системы Ext3 (снапшотов), представили первый выпуск набора патчей ext4-snapshots, обеспечивающих работу снапшотов в файловой системе Ext4.

Вопрос об интеграции представленного набора патчей в Linux-ядро пока не решен. Набор состоит из 36 патчей и интегрируется с Ext4 через систему стандартных хуков. Предусмотрена возможность монтирования разделов с отключением поддержки снапшотов, в этом случае код никак себя не проявляет и ФС Ext4 функционирует как раньше. В качестве причины развития проекта указано желание интегрировать возможность работы со снапшотами в уже зарекомендовавшую себя и повсеместно используемую ФС Ext4, вместо использования экспериментальной ФС Btrfs или системы dm_multisnap.

Разработка проекта ведется компанией CTERA Networks, которая использует код проекта NEXT3 в своих NAS-хранилищах и гибридных системах хранения данных. Несмотря на то, что патчи уже достаточно хорошо протестированы и отлажены в недрах компании CTERA, для интеграции их в ядро требуется более широкомасштабное тестирование и оценка их влияния на производительность. По заявлению разработчиков проекта патчи готовы к интеграции в состав Linux-ядра. Так как окно по принятию патчей для ядра 3.0 уже закрыто, а следующее будет только в августе, у энтузиастов есть несколько месяцев на проведение дополнительного тестирования.

В отличий от снапшотов на базе LVM, система снапшотов на уровне файловой системы обладает следующими преимуществами:

• Снапшоты не требуют предварительного резервирования места, что позволяет гибко управлять доступным свободным пространством. Снапшоты Next3 являются компактными и требуют дополнительного места только для хранения изменений;
• Близкая к линейной масштабируемость - даже при огромном количестве снапшотов скорость остается на уровне, близком к Ext4;
• Поддержка инкрементальных снапшотов, доступных только на чтение (создаем снапшот: "snapshot.ext4dev take Monday", монтируем его: "snapshot.ext4dev mount Monday", удаляем: "snapshot.ext4dev delete Monday");
• Снапшоты создаются и удаляются практически мгновенно. Сразу же после удаления снапшота занятое им пространство автоматически освобождается;
• Полная прямая и обратная совместимость с Ext4. Миграция с Ext4 на вариант с поддержкой снапшотов и обратно выполняется буквально в три команды ("umount /dev/xxx; snapshot.ext4dev on /dev/xxx; mound -t ext4dev /dev/xxx").

Инструкцию по установке можно найти здесь (вместо модуля next3 следует указать ext4dev, а вместо скрипта next3 - snapshot.ext4dev). Тестовые патчи подготовлены для Linux-ядра 2.6.38 и протестированы в дистрибутивах Ubuntu 11.4 и Fedora 15. Загрузить предкомпилированную версию для систем x86_64 можно здесь.

# opennet.ru

[Zhek@Ch]

[size="3"]Разработка нативной реализации файловой системы ZFS для Linux приостановлена [/size]

Сообщается о почти полном прекращении активности, связанной с разработкой нативного порта ZFS для Linux, работающего на уровне ядра. Два месяца назад компания KQ Infotech была куплена фирмой STEC, специализирующейся на разработке SSD-накопителей. После поглощения сайт и блог проекта прекратил свое существование, а разработчики порта не отвечают на запросы прокомментировать ситуацию. Активным остается репозиторий с исходными текстами, размещенный на GitHub, но последний коммит в нем произведен месяц назад.

Разработка компании KQ Infotech основана на кодовой базе проекта Native ZFS, развиваемой Брайаном Белендорфом и сотрудниками Ливерморской национальной лаборатории по контракту с Министерством энергетики США. Силами KQ Infotech проект Native ZFS был расширен реализацией поддержки уровня ZPL (ZFS POSIX Layer), позволяющего использовать ZFS как файловую систему, а не только как менеджер томов. Так как созданные компанией KQ Infotech наработки опубликованы под открытой лицензией, остается надеяться, что проект Native ZFS продолжит их развитие под своим крылом.

# opennet.ru

[B@F]

Жалко, очень жалко.

[Zhek@Ch]

[size="3"]Видеоинтервью с Линусом Торвальдсом про смену версии Linux и про грядущий 20-летний юбилей [/size]
 
На конференции Linuxсon в начале июня Линус Торвальдс дал интервью, в котором рассказал про 20-летний юбилей ядра и про изменение нумерации версии ядра (переход на версию 3). Интервью проводил разработчик ядра Грег Кроа-Хартман (Greg Kroah-Hartman).

# opennet.ru

[Zhek@Ch]

[size="3"]Компания AVM попыталась запретить изменение используемого в прошивках ядра Linux [/size]

21 июня в окружном суде Берлина состоялось слушание дела с разбором претензий компании AVM Computersysteme Vertriebs GmbH (AVM), выпускающей DSL-маршрутизаторы, к компании Cybits AG (Cybits), производящей ПО для веб-фильтрации. Обе компании в своих продуктах используют ядро Linux, лицензированное под GNU GPLv2. Дело было инициировано по заявлению AVM, которая хочет запретить Cybits любые изменения прошивки, используемой в маршрутизаторах, включая и изменения ядра Linux. Европейское отделение фонда FSF (FSFE) и проект gpl-violations.org считают действия компании AVM прямой атакой против принципов свободного ПО и также, соответственно, атакой против тысяч энтузиастов и компаний, разрабатывающих и распространяющих свободное ПО.

При инициировании судебного разбирательства в 2010 году компания AVM заявила, что когда клиенты устанавливают фильтрующее ПО компании Cybits на маршрутизаторы AVM, это ПО изменяет встроенную прошивку маршрутизаторов и, соответственно, нарушает авторские права AVM. По мнению AVM, даже изменение компонентов ядра Linux в составе прошивки не должно разрешаться. В сентябре 2010 года Берлинский Апелляционный суд отверг этот аргумент в решении по запросу предварительного судебного запрета, после того, как основатель gpl-violations.org и разработчик некоторых компонентов ядра Linux, Харальд Вельте (Harald Welte), вступил в судебное дело.

Теперь окружной суд Берлина, уже в процессе основных слушаний должен будет вынести решение. По мнению FSFE, если успех будет на стороне AVM, то это будет означать прямое противоречие законным правам авторов программ, придерживающихся принципов свободы ПО и сотрудничества, а не получения лицензионных сборов. Более того, это даст производителям устройств возможность наложить вето на стороннее ПО в своих продуктах, что в свою очередь повлечёт ухудшение пользовательских качеств продуктов и развяжет руки в направлении привязки к определённому вендору. Кроме того, такое решение даст таким компаниям, как AVM, несправедливое преимущество перед теми конкурентами, кто соблюдает условия лицензии GPL на те продукты, которые они используют. Такой подход несёт угрозу модели разработки ПО на основе сотрудничества, которая успешно применяется многими компаниями во всём мире уже более трёх десятилетий.

"AVM нападает на сами основы Свободного ПО - они хотят отнять свободу у других. Мы должны действовать когда видим, что какая-то компания привлекает другую компанию за то, что она прибегает к законному праву изменять свободное ПО. Такое поведение нельзя допускать. Если решение будет в их пользу, то это разрушительно повлияет на глобальный рынок встраиваемых устройств, куда входят мобильные телефоны, сетевое оборудование и другие устройства на базе Linux", - сказал немецкий координатор FSFE, Маттиас Киршнер (Matthias Kirschner).

"Ирония состоит в том, что запрещая другим реализовывать права, предоставляемые GNU GPL, компания AVM сама нарушает условия лицензии. Следовательно, у них нет права на распространение ПО", - сказал Тилл Йегер (Till Jaeger), представляющий в суде Харальда Вельте.

# opennet.ru

[Zhek@Ch]

[size="3"]Изучение изменения размера кодовой базы Ext4, Btrfs и XFS [/size]

Эрик Сандин (Eric Sandeen) из компании Red Hat проанализировал интенсивность развития файловых систем Ext4, Btrfs и XFS, изучив число связанных с данными ФС строк кода в различных версиях Linux-ядра. Результаты получились довольно интересными: на протяжении нескольких лет, размер кода (комментарии не учитывались), связанного с XFS уменьшается, что свидетельствует о проводимых оптимизациях и избавлении от лишнего груза. XFS постепенно избавляется от изначально присущей данной ФС усложненности и запутанности кодовой базы.

В отличие от XFS, файловые системы Ext4 и Btrfs идут по пути постоянного усложнения. Наибольший рост кодовой базы Ext4 наблюдался во время выпуска ядер 2.6.24-2.6.27, в дальнейшем размер кодовой базы почти линейно постоянно увеличивается (за время существование размер Ext4 увеличился с 17 до 30 тысяч строк). Размер кодовой базы Btrfs опережает по темпу роста Ext4 - с момента первой интеграции Btrfs в ядро 2.6.29 размер кода увеличился с 33 до 49 тысяч строк.

Некоторые другие выводы:

• Код XFS значительно лучше документирован, комментарии составляют примерно 39% от всего размера кода. В EXT4 доля комментариев составляет 33%, а в Btrfs - 17%;
• В коде XFS выявлено 4806 дублирующихся строк в 561 блоках в 55 файлах. В ext4+jbd2 найдено 917 дубликатов, затрагивающих 116 блоков в 23 файлах. В Btrfs присутствует 2252 дубликатов в 272 блоках в 31 файле.

# opennet.ru

[Zhek@Ch]

[size="3"]Обновление Linux-ядра: 2.6.39.2, 2.6.32.42, 2.6.33.15 и 2.6.34.10[/size]

Представлены очередные корректирующие релизы Linux-ядра: 2.6.39.2 (92 исправления), 2.6.32.42 (91 исправление), 2.6.33.15 (84 исправления) и 2.6.34.10 (255 исправлений, которые накопились с апреля). Как обычно, в анонсе выхода новых версий подчеркивается обязательность проведения обновления.

Из подсистем в которые внесены исправления можно отметить: cifs, AppArmor, md/raid5, FAT, USB, usb-storage, UBIFS, Xen, lguest, intel-iommu, iwlwifi, iwlegacy, iwl4965, ath9k, mac80211, igb, CPUFREQ, drm/radeon, drm/i915, ALSA. Отдельно можно выделить исправление нескольких проблем, имеющих отношение к безопасности: возможность совершения DoS-атаки на CIFS-сервер и переполнение буфера в драйвере nl80211, возникающие при выполнении операции сканирования для SSID некорректного размера.

Неисправленными остаются несколько уязвимостей: проблема в реализации технологии Transparent Hugepage (THP), которая может быть использована для инициирования краха ядра; 4 уязвимости, приводящие к утечке содержимого областей памяти ядра на архитектуре Alpha; "race condition" в "scan_get_next_rmap_item()", приводящий к краху; зацикливание в коде мониторинга проходящих через сокет пакетов; излишнее потребление ОЗУ и ресурсов CPU при некорректном использовании netlink-интерфейса TASKSTATS.

# opennet.ru

[Zhek@Ch]

[size="3"]Для Linux-ядра представлен фреймворк, позволяющий управлять всеми процессорами SoC-систем[/size]

Охад Бэн-Кохен (Ohad Ben-Cohen), Linux-разработчик и создатель само-обучаемой HIDS Korset, опубликовал в списке рассылки Linux-ядра набор патчей, реализующих универсальный механизм управления работой специализированных микропроцессоров, выполняющих вспомогательные роли на современных системах-на-кристалле (SoC). Обычно такие процессоры управляются с помощью специализированной ОС реального времени и выполняют такую работу как цифровая обработка сигналов, ускорение обработки мультимедиа-данных или управления разными видами сенсоров, требующих немедленной реакции системы, а для их связи с центральным процессором используются специфические механизмы, разработанные производителем чипа и накладывающие ряд ограничений на программистов.

 Патч, реализованный Охадом Бэн-Кохеном и двумя другими программистами фактически устраняет эти ограничения благодаря основанному на технологии VirtIO универсальному механизму обмена сообщения между центральным процессором и остальными процессорами чипа. Протокол, получивший имя rpmsg, позволил реализовать такие возможности как OMX offloading, менеджер ресурсов и дисплейный драйвер для Netra (dm8168), который работает в ядре Linux, посылая управляющие команды микропроцессору M3 (чип TI OMAP4). Также патч включается в себя реализацию механизма remotproc, позволяющего управлять работой выбранного процессора: останавливать, перезапускать или загружать альтернативный прошивки.

 В настоящее время полная поддержка технологии (включая открытый firmware) реализована для чипа TI OMAP4, используемого в популярной платформе PandaBoard (также тестировались Davinci da850-evm и hawkboard).

# opennet.ru

[Zhek@Ch]

[size="3"]Линус Торвальдс не видит для ФС пространства пользователя серьезного применения[/size]

"Те, кто думают, что файловые системы (ФС) пространства пользователя могут быть чем-то большим, чем игрушки, просто введены в заблуждение" - так Линус Торвальдс прокомментировал сообщение Эндрю Мортона о том, что проблемы производительности файловых систем, основанных на FUSE, нельзя решить только за счет перемещения их кода в ядро. "Fuse подходит тогда, когда речь идет о редко используемом интерфейсе к изначально низкоскоростному устройству. Но для чего-то вроде корневой ФС ? Нет. Из этого ничего не выйдет." - добавил Линус.

Спор о файловых системах пространства пользователя начался после того, как Миклос Жереди (Miklos Szeredi) отправил в список рассылки linux-fsdevel письмо с просьбой добавить код драйвера OverlayFS в Linux-ядро версии 3.1. Эндрю Мортон (Andrew Morton) спросил его о причинах реализации ФС в виде драйвера ядра, вместо использования FUSE, на что Миклос ответил, что по его мнению, реализация ФС в пространстве пользователя никогда не будет такой же быстрой как ФС пространства ядра. Мортон принял этот аргумент, но в ходе дальнейшей дискуссии добавил, что если ФС, основанная на FUSE имеет низкий уровень производительности, то сначала стоит задуматься о ее правильной реализации, а лишь затем о переносе кода в пространство ядра. После этого в дискуссию вступил Торвальдс.

 Громкое заявление Торвальдса вызвало большой резонанс не только в среде пользователей, но и программистов, использующих FUSE. Так, разработчики файловых систем CloudFS и GlusterFS независимо друг от друга опубликовали в своих блогах сообщения о том, что взгляд Линуса Торвальдса на файловые системы слишком ограничен, так как существует масса самых разнообразных применений механизма FUSE, где выгода от простоты и гибкости разработки с его использованием перевешивает любые преимущества пространства ядра в плане производительности. "Что плохого в том, что FUSE делает разработку файловых систем такой же простой как создание игрушек? - написал Джон Марк (John Mark) в конце своего сообщения.

Тем не менее, попытка сторонников FUSE привести драйвер NTFS-3G в качестве примера возможности создания высокопроизводительных FUSE-драйверов была опровергнута одним из разработчиков NTFS-драйвера для Linux, который указал на то, что выполненная той же компанией реализация NTFS в виде модуля ядра значительно превосходит по производительности NTFS-3G.

# opennet.ru

[Zhek@Ch]

[size="3"]Обновление Linux-ядра: 2.6.39.3 [/size]

Представлен корректирующий релиз Linux-ядра - 2.6.39.3, в котором отмечено 109 исправлений. Как обычно, в анонсе выхода новых версий подчеркивается обязательность проведения обновления. Из подсистем, в которых исправлены ошибки, можно выделить: USB, xhci, drm/i915, drm/radeon, conntrack, KVM, Xen, vlan, netfilter, ipset, FS-Cache, cfq-iosched, NFSv4, nfsd, ALSA, ath9k, ath5k, IPVS.

Среди исправленных проблем: устранение ошибки в ipv4-стеке, приводившей к потере первого пакета в mulicast-потоке; решение проблемы в драйвере USB Hub, которая мешала переходу в спящий режим; устранение зацикливания в подсистеме md, проявляющегося при определенных обстоятельствах в процессе восстановления программного RAID.

Несколько исправлений связаны с безопасностью:

• Отсутствие должной инициализации структур, обеспечивающих работу блокировок в коде, связанном с файловыми системами может привести к утечке информации из области ядра при использовании FUSE-модулей.
• Ошибка в реализации функции inet_diag_bc_audit() из состава подсистемы inet_diag может привести к подстановке кода локальным пользователем или инициированию бесконечного цикла.
• Возможность разыменования NULL-указателя в ksmd.

# opennet.ru

[Zhek@Ch]

[size="3"]Microsoft занял седьмое место в рейтинге самых активных контрибьюторов ядра Linux 3.0 [/size]

343 изменения в грядущем ядре Linux 3.0 - дело рук разработчика по имени K. Y. Srinivasan, работающего в компании Microsoft. Согласно проведенным подсчетам общее количество изменений в Linux-ядре, проделанных Microsoft, составило 361, что вывело компанию на седьмое место в списке самых активных контрибьюторов Linux-ядра (для сравнения: компании Red Hat принадлежит 1000 изменений, Intel - 839, независимым разработчикам - 1085). Среди участвующих в разработке ядра корпораций Microsoft заняла 5 место, уступив только Red Hat, Intel, Novell и IBM.

 Все проделанные Microsoft изменения связаны с драйверами для поддержки интерфейса виртуализации Hyper-V, разработанных ей же и открытых под лицензией GPL в середине 2009 года. Из-за несоответствия драйверов предъявляемым требованиям качества, их код долгое время оставался частью тестовой ("staging") ветки ядра Linux и уже два раза был кандидатом на полное удаление из дерева исходного кода. Однако после нескольких оправданий Microsoft все-таки довела код до требуемого состояния, в результате чего и появилось такое большое количество изменений со стороны компании.

 Интересно, что если пересчитать вклад Microsoft в количестве измененных строк кода, то компания окажется на 15 месте с 11564 строками кода или 1.3% от общего количества изменений (для сравнения размер изменений от компании Intel - 163232 строк или 18.1%).

# opennet.ru

[Zhek@Ch]

[size="3"]Релиз Linux-ядра 3.0 отложен на несколько дней [/size]
 
Линус Торвальдс объявил о незначительной задержке релиза Linux-ядра 3.0, который планировалось выпустить в понедельник. Задержка связана с обнаружением в последний момент проблемы, связанной с работой кода проверки файловых путей. Несмотря на то, что в настоящий момент уже доступен патч и известна причина возникновения проблемы, релиз будет немного задержан из-за необходимости провести дополнительное тестирование.

Отдельно отмечается, что выявленная ошибка проявляется крайне редко и требует достаточно специфичного стечения обстоятельств. Например, для того чтобы повторить условия проявления проблемы потребовалось несколько недель стресс-тестирования. По словам Линуса на подобную редкую проблему можно было бы не обращать внимание, спокойно выпустить релиз и включить патч в состав одного из корректирующих обновлений, но выпуск релиза, в котором заведомо есть известные ошибки, какими бы редкими они ни были, заведомо порочная практика, до которой не следует опускаться.

# opennet.ru

[Zhek@Ch]

[size="3"]Первое за 18 лет обновление dmesg(1) [/size]
 
Karel Zak, один из разработчиков пакета util-linux, содержащего основные системные утилиты Linux, впервые подверг изменению утилиту dmesg этого пакета. Обновление станет доступным для пользователей с выходом util-linux версии 2.20.

dmesg выводит все сообщения ядра, начиная с этапа загрузки системы, в stdout.

Новые функции включают:

• Ключ --decode, преобразующий числовое значение уровней загрузки и параметры операции в понятные текстовые примечания:
  Код [Выделить] Expand
  $ dmesg --decode
kern :info : [26443.677632] ata1.00: configured for UDMA/100
kern :info : [26443.830225] PM: resume of devices complete after 2452.856 msecs
kern :debug : [26443.830606] PM: Finishing wakeup.
kern :warn : [26443.830608] Restarting tasks ... done.
• Фильтрация сообщений в соответствии с опциями --facility и --level:
  Код [Выделить] Expand
  $ dmesg --level=err,warn
$ dmesg --facility=daemon,user
$ dmesg --facility=daemon --level=debug
• Ключ -u, --userspace для вывода сообщений, полученных с пользовательского уровня;
• Ключ -k, --kernel для вывода сообщений уровня ядра;
• Ключ -t, --notime для удаления из вывода временных отметок;
• Ключ -T, --ctime для вывода времени в формате, подобном ctime(). Однако этот ключ бесполезен после использования ждущего режима и выхода из него. (Для printk() после окончания ждущего режима ядро не использует обычное системное время и поэтому временные значения не изменяются.)
• Ключ --show-delta для вывода длительности промежутка между сообщениями:
  Код [Выделить] Expand
  $ dmesg --show-delta
[35523.876281 < 4.016887>] usb 1-4.1: new low speed USB device using hci_hcd and address 12
[35523.968398 < 0.092117>] usb 1-4.1: New USB device found, idVendor=413c, idProduct=2003
[35523.968408 < 0.000010>] usb 1-4.1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[35523.968416 < 0.000008>] usb 1-4.1: Product: Dell USB Keyboard

>>> Подробности

# linux.org.ru

[Zhek@Ch]

[size="3"]Представлен первый тестовый набор RT-патчей для ядра Linux 3.0[/size]

Томас Глейкснер (Thomas Gleixner), основной разработчик и мейнтейнер RT-ветки ядра Linux, сообщил о выпуске тестовой верcии набора патчей с реализацией режима реального времени (Realtime-Preempt", PREEMPT_RT или "-rt") для ядра Linux 3.0. Ядро "-rt" с реализацией жёсткого режима реального времени используется в real-time редакциях промышленных Linux дистрибутивов MontaVista, Red Hat и Novell. Это первое крупное обновление RT-Linux за последние несколько лет, которое знаменует собой уход от ядра версии 2.6.33, которое было использовано в качестве базы для RT-ветки несколько лет подряд.

В письме, отправленном в список рассылки Linux-ядра, Томас Глейкснер отмечает существенное отличие новой версии патчей от предыдущих. Логика работы многих подсистем была кардинально переработана, код стал намного чище и проще для анализа, общий размер патчей сократился более чем в два раза. Теперь код затрагивает гораздо меньше подсистем и структур данных ядра, что, по мнению автора, позволит ускорить процесс его включения в основную ветку.

 Ядро с наложенными патчами было протестировано на платформах x86 и x86_64, а также на ARM, MIPS и PowerPC и, по словам Thomas Gleixner оказалось "удивительно стабильным" (amazinlgy stable). Событие знаменательно тем, что это первый случай когда RT-патчи адаптированы для последней актуальной версии Linux-ядра, ранее выпуск патчей существенно отставал, что было связано с большой трудоемкостью процесса портирования и тестирования.

# opennet.ru

[Zhek@Ch]

[size="3"]Релиз Linux-ядра 3.0 [/size]

Линус Торвальдс анонсировал релиз Linux-ядра 3.0, в котором завершена интеграция поддержки XEN dom0, интегрирован JIT-компилятор BPF-правил, добавлена реализация кэша Cleancache, обеспечена поддержка "Wake on WLAN", реализована автоматическая дефрагментация в Btrfs. Выпуск 3.0 ознаменовал завершение развития ветки 2.6.x, которая развивается уже около 10 лет и переход к новой схеме нумерации. Следующим после 3.0 выпуском станет версия 3.1, затем 3.2 и так далее, пока не пройдут очередные 10 лет или не возникнет потребность коренных изменений, связанных с глобальной переработкой ключевых подсистем или нарушением совместимости. В процессе накопления патчей корректирующие обновления будут представлены как 3.0.1, 3.0.2, 3.0.3 и т.п.

Отдельно подчеркивается, что версию 3.0 не стоит считать каким-то кардинальным шагом, какой можно было наблюдать при появлении GNOME 3.0 или KDE 4.0. Linux-ядро 3.0 - не более чем формальная смена нумерации, приуроченная к двадцатилетию проекта и десятилетию существования ветки 2.6.x. В новой версии нет каких-либо серьезных нарушений совместимости или специальных новшеств. Новое ядро плавно продолжает развитие текущей кодовой базы и по уровню нововведений сравнимо с выпуском версии 2.6.40. Более того, число изменений по сравнению с прошлыми выпусками выглядит достаточно скромно. Процесс разработки также остаётся прежним.

В новую версию принято 9862 исправлений от 1276 разработчиков, размер патча - 44 Мб (добавлено 8002 тыс. строк кода, удалено - 7946 тыс. строк). Около 41% всех представленных в 3.0 изменений связаны с драйверами устройств, примерно 25% изменений имеют отношение к обновлению кода специфичного для аппаратных архитектур, 15% связано с сетевым стеком, 5% - файловыми системами и 5% c внутренними подсистемами ядра.

Наиболее интересные новшества ядра 3.0:

• Виртуализация и безопасность
  • Окончание интеграции полной поддержки Dom0 и DomU в Linux-ядро. В состав ядра 3.0 принят бэкенд xen-blkback, необходимый для обеспечения работы виртуальных блочных устройств. Таким образом в стандартном ядре теперь содержится полный набор средств, необходимых для работы Xen в качестве управляющего хоста и гостевой системы. Отныне поддержка Xen будет неотделима от ядра Linux и будет развиваться вместе с ним, без ведения отдельных веток и поддержания дополнительных патчей;
  • Поддержка раздельных номеров файловых дескрипторов внутри изолированных пространств Namespace. Namespace является своеобразной легковесной техникой виртуализации, при которой некоторые процессы могут быть отрезаны от остальной системы, работая в отдельном пространстве имен и не влияя на другие части системы;
  • Поддержка аппаратного режима SMEP (Supervisor Mode Execution Protection), поддержка которого заявлена в будущих моделях процессоров Intel. Использование SMEP не позволяет переходить из режима ядра к выполнению кода, находящегося в пользовательских областях. Запрет на выполнение ядром кода пользовательского уровня позволяет существенно усложнить эксплуатацию многих уязвимостей в ядре (shell-код не будет выполнен, так как он находится в пространстве пользователя);
• Дисковая подсистема, ввод/вывод и файловые системы
  • Улучшение файловой системы Btrfs:
    • Поддержка автоматической дефрагментации. Btrfs больше подвержена фрагментации, так как использует при записи данных подход COW (copy-on-write), при котором при изменении содержимого файла данные не переписываются в уже распределенных блоках, а копируются и сохраняются в новом свободном блоке, что позволяет организовать работу снапшотов. Кроме ранее доступной команды "btrfs filesystem defragment" и отключающей COW опции монтирования "-o nodatacow", в новой версии ядра представлена поддержка автоматической дефрагментации, включаемая через опцию монтирования "-o autodefrag". Суть механизма автоматической дефрагментации сводится к обнаружению небольших случайных операций записи в файлы и построению специальной очереди, которую разбирает специальный внутренний дефрагментатор. Данный метод еще плохо адаптирован для работы с большими БД или виртуализацией, но уже хорошо работает при изменении небольших файлов, в процессе использования таких систем, как rpm, sqlite и bdb;
    • Реализация процесса проверки целостности данных ("Scrubbing") в файловой системе путем сверки указанных в экстентах контрольных сумм с контрольными суммами, вычисленными на основе фактических данных. В случае выявления расхождений предпринимается попытка поиска неповрежденной копии данных;
    • Увеличение скорости создания и удаления файлов. Основные проблемы с производительностью при создании и удалении файлов связаны с необходимостью выполнения большого числа сопутствующих действий с b+ деревьями. Для ускорения подобных операций реализован метод отложенного изменения b+ деревьев. В итоге производительность создания файлов возросла на 15%, а удаления на 20%;
    • Ускорение выполнения операций по сбросу буферов на диск (при выполнении fsync на диск теперь сбрасываются только изменившиеся с момента последней синхронизации данные). Скорость выполнения теста sysbench при сочетании случайно записи с вызовом fsync возросла с 112.75 запросов в сек. до 1216 запросов в сек.
    • Поддержка метода "Quasi-round-robin" при распределении блоков в конфигурациях с несколькими дисками. Новый метод позволяет полностью использовать при разнесении данных (stripe) все доступное дисковое пространство, используя для хранения в первую очередь диски, на которых больше доступного места;
  • Проведение оптимизации и чистки кода в подсистеме VFS. Например, за счет реализации кэширования сокращено число проверок xattr при выполнении операций записи;
  • В tmpfs реализована поддержка xattr;
  • В реализацию файловой системы CIFS добавлена поддержка монтирования DFS-шар Windows 2008. Добавлена новая опция "rwpidforward", включающая режим, при котором CIFS перенаправляет pid процессов, открывших файл на запись или чтение;
  • В файловую систему OCFS2 добавлена возможность перемещения экстентов и интегрирована поддержка операций TRIM, что позволит увеличить производительность при работе с SSD-накопителями и повысить их срок службы;
  • В EXT4 добавлена возможность "punch hole", позволяющая пометить область внутри файла в качестве необязательной, которую можно при необходимости очистить. Кроме того, добавлена защита, недопускающая одновременное монтирование одного раздела несколько раз ;
• Сетевая подсистема
  • Интегрирован JIT-компилятор для правил BPF (Berkeley Packet Filter), поддерживающий работу на системах x86-64, что позволит значительно увеличить производительность обработки пакетов при использовании инструментов, подобных libpcap/tcpdump;
  • Поддержка отправки ICMP_ECHO ICMP-пакетов и приема ICMP_ECHOREPLY ответов в непривилегированном режиме, что позволяет организовать работу ping и других отладочных утилит без предоставления дополнительных привилегий через suid-бит или capabilities;
  • В беспроводной стек добавлена поддержка функции "Wake on WLAN", позволяющей перевести систему в режим низкого потребления энергии (ACPI S3 suspend) с сохранением активности беспроводного сетевого интерфейса, т.е. в момент сна может быть сохранено соединение с точкой доступа и обеспечено просыпание при появлении адресованного текущему хосту трафика;
  • В ipset добавлена поддержка SCTP и UDPLITE;
  • Добавлен новый планировщик пакетов QFQ (quick fair queue), используемый в ipfw из состава FreeBSD;
• Память и системные сервисы
  • Реализация нового типа кэша Cleancache, который может использоваться ядром для хранения восстановимых из других источников данных, которые не страшно потерять, но при наличии ресурсов неплохо держать в памяти. Например, в Cleancache могут храниться ассоциированные с файлами на диске страницы памяти, которые в случае очистки кэша впоследствии могут быть перечитаны с диска. Поддержка CleanCache уже добавлена в Ext3, Ext4, Btrfs, OCFS2 и Xen. Cleancache является первой практической реализацией появившейся в ядре 2.6.39 техники трансцендентного управления памятью ("Transcendent memory"), позволяющей улучшить поведение системы при работе с не представляющими важность данными (например кэш) в условиях дефицита оперативной памяти. По сути Transcendent memory напоминает RAM-диск, имеющий ряд особенностей: размер RAM-диска не известен, запись данных не всегда может быть гарантирована и уже записанные данные могут быть очищены (удалены);
  • Поддержка системного вызова sendmmsg(), который позволяет организовать передачу в рамках одного системного вызова сразу нескольких сообщений, которые ранее потребовали бы отдельных вызовов sendmsg(). Технология значительно повышает эффективность работы приложений передающих большие объемы данных или оперирующих пакетами небольшого размера. Тестирование показало, что использование sendmmsg() позволяет повысить скорость отправки данных через UDP-сокет на 20%, а через RAW-сокет на 30%. Напомним, что поддержка парного вызова recvmmsg() была добавлена в ядре 2.6.33;
  • Поддержка системного вызова setns(), который позволяет использовать для файлового дескриптора определенное изолированное пространство имен (namespace);
  • Реализация Alarm-таймеров CLOCK_REALTIME_ALARM и CLOCK_BOOTTIME_ALARM, позволяющих организовать автоматический выход системы из спящего режима в определенное время;
• Оборудование и аппаратные архитектуры
  • Переработка кода, связанного с организацией процесса перезагрузки. Алгоритм выполнения перезагрузки максимально приближен к методам, используемым на платформе Windows, что позволило решить проблемы с перезагрузкой на отступающих от стандартов устройствах, например, на некоторых ноутбуках Thinkpad и компьютерах Apple;
  • Продолжение реорганизации кода, связанного с платформой ARM;
  • Добавление разработанного в рамках проекта OpenKinect драйвера для устройств Microsoft Kinect. В настоящее время драйвер способен принимать с устройства видеопоток, взаимодействуя с RGB-сенсором или монохромным сенсором, т.е. позволяет использовать Microsoft Kinect в роли web-камеры или инфракрасной камеры. Датчики глубины пока не поддерживаются;
  • Обновление кода DRM-модулей Intel, Radeon и Nouveau. Проведена оптимизация производительности для гибридных процессоров Intel Sandy Bridge, обеспечена начальная поддержка Intel Ivy Bridge и AMD Fusion Llano APU. В драйвере gma500 реализована базовая поддержка механизма управления видеопамятью GEM;
  • Для беспроводных карт Realtek представлен новый драйвер rtl8192se;
  • Экспериментальный драйвер с поддержкой Intel MEI (Intel Management Engine Interface);
  • Экспериментальный драйвер nvec с реализацией совместимого с NVidia протокола для взаимодействия со встраиваемыми контроллерами;
  • Расширение поддержки устройств хранения: в SATA-драйвер pata_marvell добавлена поддержка чипов 88SE91A0 и 88SE91A4; SCSI-драйвер для Intel C600; в драйвер mvsas добавлена поддержка Marvell 88SE9445/88SE9485;
  • Расширение поддержки сетевых карт: в ixgbe добавлена поддержка чипов 82599; в rt2x00 обеспечена поддержка USB-устройств RT5370 и PCI-устройств RT53xx; в rtlwifi добавлена поддержка rtl8192se и rtl8192de; в ath6kl добавлена поддержка AR6003; в ath9k - AR9340; r8169 - RTL8168DP и RTL8168E; добавлен драйвер для Samsung GT-B3730.
  • Множество других изменений, связанных с поддержкой аппаратных устройств.

# opennet.ru
 

[Zhek@Ch]

[size="3"]В ядро Linux 3.1 добавлена поддержка открытого микропроцессора OpenRISC [/size]

В понедельник Линус Торвальдс добавил в дерево исходных кодов ядра Linux 3.1 код, обеспечивающий поддержку открытого микропроцессора OpenRISC, разработанного сообществом энтузиастов. Размер принятого патча составляет примерно 11 тысяч строк кода и затрагивают 82 файла ядра. Набор патчей с поддержкой OpenRISC изначально был создан еще для ядра Linux 2.6.35 и постепенно развивался и стабилизировался до тех пор, пока не был признан созревшим для интеграции в состав основной ветки ядра.

OpenRISC был создан сообществом OpenCores, объединяющем людей, занимающихся проектированием полностью открытой микроэлектроники. Наработки проекта уже производятся многими коммерческими компаниями в виде интегральных микросхем ПЛИС и БМК. Полный исходный код процессора на языке описания аппаратуры Verilog, схемы, firmware, а также модифицированный инструментарий GNU открыты всем желающим на условиях лицензий GPL и LGPL. Текущая версия процессора, именуемая OpenRISC 1200, включает в себя процессорное ядро, реализующее набор инструкций ORBIS32, опциональный блок арифметики с плавающей точкой ORFP32X, пятиступенчатый конвейер, блок DSP, раздельные блоки управления памятью для данных и инструкций. По заявлениям создателей производительность процессора должна быть близка к ARM10.

Члены сообщества OpenCores разработали также и большое число других устройств, включая различные контроллеры, DSP-модули, сопроцессоры, системы-на-кристалле, среди которых есть клон микропроцессора Zilog Z80, используемого в домашнем компьютере Spectrum, контроллер USB 2.0, ethernet-контроллер, обеспечивающий скорость обмена данными до 1000 Mбит/с, реализация шины HyperTransport, Zet (ядро x86-совместимого процессора).

# opennet.ru