История с удалением имён российских разработчиков из файла MAINTAINERS ядра Linux получила продолжение. По информации ресурса Phoronix, ситуацию прокомментировал бывший член совета директоров Linux Foundation Джеймс Боттомли (James Bottomley), активно принимающий участие в разработке и по сей день.

Буквально на днях в Linux-сообществе разразился скандал — из файла MAINTAINERS удалили упоминания об 11 сопровождающих. Сообщалось, что записи могут вернуть, если будут предоставлены некие документы. Событие вызвало резонанс в Linux-сообществе, многие представители которого заявили, что отсутствие чётких критериев подобных репрессивных мер в будущем может грозить злоупотреблениями и ослаблением сообщества.

Позже меры утвердил и создатель ядра Linux Линус Торвальдс (Linus Torvalds), подтвердив слухи о том, что изменения связаны с санкциями США в отношении России и решение не подлежит отмене. Впрочем, от подробных комментариев отказался и он. Зато ситуацию прояснил Боттомли, принеся извинения за саму форму, в которой состоялось негласное «отлучение» от Linux. По его словам, меры были приняты в отношении людей, связанных с российскими компаниями, попавшими в санкционный список OFAC SDN Министерства финансов США — такие люди не могут остаться в файле MAINTAINERS.

Источник изображения: Bob Brewer / Unsplash

Каким образом можно доказать непричастность к работе в подсанкционных компаниях, не уточняется. В частности, в списке оказался разработчик, который когда-то действительно был трудоустроен в попавшую под санкции компанию «Байкал Электроникс», которой ранее уже было отказано в приёме патчей для ядра. Среди других оказались, в частности, сотрудники SberDevices, NetUP, МГУ, Metrotek, «Открытая мобильная платформа» (ОС «Аврора»).

Боттомли пояснил, что вся инфраструктура разработки Linux и огромное количество сопровождающих расположены в США, поэтому игнорировать законы этой страны не выйдет в любом случае. Разработчик выразил надежду, что из ядра не придётся удалять код уже добавленных патчей, и обещал посодействовать добавлению имён всех внёсших вклад в разработку Linux в файл CREDITS. Скоро юристы Linux Foundation, по его словам, должны опубликовать подробные материалы, посвящённые событиям.

С дополнительными комментариями поспешил выступить известный разработчик Теодор Цо (Theodore Ts'o). Он подчеркнул, что разработчики не устанавливают правила и обязаны соблюдать существующее законодательство. Он также отметил, что между санкциями против Huawei и российских разработчиков есть разница, поскольку в США существуют разные санкционные режимы для отдельных структур и людей. Кроме того, аналогичные правила на самом деле действовали и раньше, например, в отношении авторских прав и копирайта.

Не желая повторения инцидента, который вывел из строя миллионы компьютеров на Windows из-за бага в ПО CrowdStrike, Microsoft собрала ключевых разработчиков решений кибербезопасности на закрытой встрече Windows Endpoint Security Ecosystem Summit, где предложила им новый подход к защите Windows-систем. По данным PC Mag, речь идёт о новой платформе, позволяющей отказаться от доступа антивирусных программ к ядру операционной системы.

В блоге компании по итогам мероприятия сообщается, что Microsoft намерена развивать принциы, уже применяемые в Windows 11 и позволяющие во многих случаях обеспечивать защиту системы без непосредственного доступа к ядру. Инцидент с антивирусным ПО CrowdStrike, затронувший миллионы компьютеров по всему миру, во многом произошёл потому, что ПО имело доступ к ядру ОС. С одной стороны, без подобной функциональности со многими угрозами справиться трудно, с другой — именно из-за неё пользователи увидели «синий экран смерти» на миллионах ПК. Microsoft обвинила в случившемся власти Евросоюза, в своё время вынудившие компанию обеспечить подобный доступ разработчикам антивирусов.

Источник изображения: Jefferson Santos/unsplash.com

Впрочем, ни о каком закрытии доступа к ядру Windows речи пока не идёт. Клиенты и партнёры попросили компанию «предоставить дополнительные возможности обеспечения безопасности вне режима ядра», что позволило бы разработчикам создавать антивирусное ПО, не обращающееся к ядру, по крайней мере — на регулярной основе. В ходе встречи Microsoft и партнёры обсудили требования к новой платформе и основные вызовы, с которыми придётся столкнуться при её разработке. Компания сообщила, что речь идёт о долговременном проекте, в рамках которого Microsoft вместе с партнёрами намерена добиться повышенной надёжности защитного ПО без ущерба безопасности.

При этом Microsoft признала, что все участники саммита согласились с тем, что вендорам антивирусного ПО и клиентам выгодно, когда у них есть выбор различных вариантов для Windows в контексте обеспечения безопасности. Например, ESET прямо заявила, что доступ к ядру должен остаться одной из опций для эффективной защиты от киберугроз. Кроме того, стороны намерены делиться практиками безопасных обновлений ПО. Именно сбой на одном из этапов выпуска обновлений ПО CrowdStrike и привёл к эпохальному сбою, обошедшемуся некоторым компаниям в сотни миллионов долларов.

В ядре Linux Kernel 6.12, по сообщению ресурса Phoronix, появится функция отображения QR-кода во время критических сбоев ядра (kernel panic). Идея заключается в том, чтобы предоставлять пользователям максимально подробную информацию о причинах появления «экрана смерти» и возможных способах устранения проблемы.

Как отмечает Tom's Hardware, попытки интеграции информационных QR-кодов в Linux осуществлялись и раньше. Так, возможность внедрения данного инструмента обсуждалась в 2014 году. А в декабре 2023-го состоялся релиз systemd 255 с модулем systemd-bsod, который в случае сбоя отображает «синий экран смерти» и QR-код с ошибкой.

Источник изображения: Phoronix

Аналогичный инструмент интегрируется непосредственно в ядро Linux 6.12, поэтому даже если произойдет полный сбой операционной системы, пользователь всё равно увидит QR-код с описанием проблемы. QR-код — достаточно мощный и важный инструмент для выяснения причины критического сбоя, особенно с учётом того, что обычно вывод о причинах неполадок обрезан. Поддержка новой функции реализована в виде Rust-модуля. Работа инструмента контролируется параметром DRM_PANIC_SCREEN_QR_CODE.

Нужно отметить, что Microsoft добавила QR-код к «синему экрану смерти» Windows в 2016 году. Но при его сканировании пользователь попадает лишь на общую страницу поддержки, не получая никаких дополнительных подробностей. Вместо этого предлагается перезапустить компьютер, открыть приложение Get Help и затем ввести «Troubleshoot BSOD error». Однако такой подход бесполезен, если «экран смерти» возникает при каждом включении ПК.

Пока ИТ-инфраструктура по всему миру восстанавливается после критического сбоя, бизнес, эксперты и политики уже ищут виноватых в произошедшем. По данным The Wall Street Journal, в Microsoft заявили, что инцидент может оказаться результатом вынужденного соглашения 2009 года между IT-гигантом и Евросоюзом.

Эксперты уже задаются вопросом, почему CrowdStrike, занимающейся решениями для обеспечения кибербезопасности, обеспечили доступ к ядру Windows на столь низком уровне, где ошибка может оказаться очень масштабной и дорого обойтись огромному числу пользователей.

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

Как сообщает WSJ, в Microsoft отметили, что соглашение 2009 года компании с Еврокомиссией и стало причиной того, что ядро Windows не защищено так, как, например, ядро macOS компании Apple, прямой доступ к которому для разработчиков закрыт с 2020 года. Соглашение о совместимости фактически стало результатом повышенного внимания европейских регуляторов к деятельности Microsoft.

Источник изображения: Sunrise King/unsplash.com

В соответствии с одним из его пунктов, Microsoft обязана своевременно и на постоянной основе обеспечивать информацию об API, используемых её защитным ПО в Windows — пользовательских и серверных версиях. Соответствующая документация должна быть доступна и сторонним разработчикам антивирусного ПО для создания собственных решений, что должно способствовать честной конкуренции. Однако вместо использования API без доступа к ядру CrowdStrike и ей подобные предпочли работать напрямую с ядром ОС для максимизации возможностей своего защитного ПО. Правда, при этом велика вероятность, что в случае сбоя последствия могут быть чрезвычайно серьёзными — что и произошло.

Windows — не единственная операционная система, предлагающая доступ к ядру с возможностью вывести его из строя в случае некорректной работы. Тем не менее, повсеместное присутствие продуктов Microsoft приводит в случае сбоев в сторонних приложениях к массовым проблемам и большой огласке событий, даже если прямой вины компании в произошедшем нет.

Портал Phoronix обратил внимание на необычный патч, заметно повышающий производительность Raspberry Pi 5. Инженеры Igalia в результате экспериментов с эмуляцией NUMA на UMA-системах с чипами ARM64 (AArch64) добились повышения эффективности использования памяти. Так, простой патч для ядра Linux позволил улучшить результаты в Geekbench на 6 % в однопоточном режиме и на целых 18 % — в многопоточном.

Авторы патча пишут, что разделение RAM на несколько независимых блоков с последующим попеременными доступом (interleaving) позволяет контроллеру в Broadcom BCM2712 более полно использовать параллелизм на уровне физической организации чипов памяти (parallelism in physical memory chip organisation). Почему так происходит, авторы не уточняют, но, вероятно, это связано с особенностями организации кеша в SoC.

Источник изображения: Raspberry Pi

16-нм SoC BCM2712 включает четыре ядра Cortex-A76 (2,4 ГГц), каждому из которых полагается по 64 Кбайт кеша для инструкций и данных и 512 Кбайт L2-кеша. Объём общего L3-кеша составляет 2 Мбайт. Встроенный 32-бит контроллер памяти предлагает LPDRR4x-интерфейс, теоретическая пропускная способность которого достигает 17 Гбайт/с. Важно отметить, что этот чип не создавался эксклюзивно для Raspberry Pi — он был выбран среди актуальных массовых решений Broadcom из-за удачного сочетания цены, производительности и доступности.

Патч добавляет в Kconfig новую опцию, а для активации эмуляции NUMA (Non-uniform memory access) нужно передать соответствующий параметр при загрузке ядра. Дальнейшая работы осуществляется с помощью стандартной утилиты numactl.

Из ядра Linux, по сообщению ресурса Phoronix, исключена поддержка продуктов Intel семейства Carillo Ranch, добавленная более 15 лет назад. Любопытно, что эти изделия никогда не были доступны на коммерческом рынке, а информацию о них практически невозможно найти в интернете.

Судя по имеющимся данным, серия Carillo Ranch задумывалась как платформа для встраиваемых процессоров EP80579 на ядре Pentium M с кодовым именем Tolapai. Кроме того, упоминаются набор логики Vermillion Range и сопутствующий контроллер памяти. Внедрение поддержки Carillo Ranch в Linux уходит корнями в 2006 год.

Источник изображения: Intel

На сайте Intel присутствует информация об изделии EP80579 с частотой 1,2 ГГц. Однако в драйверах Linux платформа Carillo Ranch фигурирует как LE80578, а поиск по запросу «LE80578» в Google выдаёт информацию о принтерах HP Laserjet с процессором, работающим на частоте 800 МГц. Если же попытаться найти в Google собственно решения «Intel Carillo Ranch», то поисковик предложит исправить запрос на «Carrillo Ranch», добавив дополнительную букву «r». В этом случае выдаётся информация об одноимённом ранчо в Калифорнии.

Так или иначе, для Linux выпущены два патча, которые очищают немногим более 2 тыс. строк кода, связанных с поддержкой Carillo Ranch. Удаление соответствующих драйверов, скорее всего, останется незамеченным для сообщества.

Кроме того, как стало известно, из ядра Linux может быть убрана основная часть кода, связанного с поддержкой 32-битных процессоров SPARC для старых рабочих станций Sun. В процессорах Frontgrade Gaisler LEON3 по-прежнему используется 32-битная архитектура SPARC, поэтому основное ядро Linux не может полностью исключить соответствующую поддержку. Тем не менее, будут удалены примерно 10,5 тыс. строк старого кода SPARC32. В корпоративных же решениях данная архитектура фактическа мертва.

Некоммерческий консорциум Linux Foundation обнародовал годовой отчёт о развитии экосистемы open source. Говорится, что в 2023-м в состав организации вошли приблизительно 270 новых участников, а общее количество курируемых проектов достигло 1133.

В течение 2023 года выручка Linux Foundation составила примерно $262,6 млн, а расходы — $269,0 млн. Общая доля затрат, связанных с разработкой ядра Linux, составила всего 2,9 %, или около $7,8 млн. Это почти на $400 тыс. меньше по сравнению с 2022-м, когда доля расходов на ядро равнялась 3,2 %. В 2021-м это значение оценивалось в 3,4 %.

На различные проекты пришлось в общей сложности 64 % всех расходов Linux Foundation — около $171,8 млн. Наибольший вклад в эту сумм внесли инициативы, связанные с облачными технологиями, контейнерами и виртуализацией (25 %), а также сетевыми технологиями (13 %).

Источник изображений: Linux Foundation

Доля затрат Linux Foundation в сфере ИИ, машинного обучения и аналитики данных в 2023 году составила примерно 12 %. На средства обеспечения безопасности и конфиденциальности потрачено 4 % от общей суммы, приблизительно столько же ушло на Интернет вещей (IoT) и встраиваемые решения. На технологии блокчейна также направлено 4 % затрат.

На поддержание инфраструктуры в 2023-м потрачено $22,58 млн (9 %), на программы обучения и сертификации — $18,57 млн (7 %), на корпоративную деятельность — $17,12 млн (6 %), на различные мероприятия — $14,60 млн (6 %), на поддержку сообщества — $13,53 млн (5 %), на международные операции — $2,96 млн (1 %).

Что касается денежных поступлений, то 45 % всех полученных средств (118,2 млн долларов) пришлось на пожертвования и взносы членов организации. Ещё 26 % ($67 млн) составила целевая поддержка проектов, 19 % ($49,5 млн) — поддержка мероприятий, а также регистрационные сборы на конференциях, 10 % ($27,2 млн) — оплата обучающих курсов и получение сертификатов.

Ядро Linux прекращает поддержку архитектуры Intel Itanium (IA-64). Как сообщает Phoronix, падение интереса к соответствующей архитектуре, отсутствие тестировщиков и ключевых активных участников привели к закономерному результату. Поддержка полностью прекратится начиная с ядра Linux 6.7. Линус Торвальдс (Linus Torvalds) констатировал смерть архитектуры ещё в 2021 году.

Архитектура Itanium, разрабатываемая Intel и HP, была представлена в 2001 году. В своё время она рассматривалась как решение для высокопроизводительных вычислений и в качестве 64-бит замены x86. Впрочем, ещё в 1999 году код и драйверы для Itanium включили в основную ветку ядро Linux. Поддержка была заранее добавлена в GCC (GNU Compiler Collection), появился и бесплатный симулятор CPU для отладки ПО.

Изображение: Intel

Тем не менее, Itanium так и не удалось получить по-настоящему сильного импульса к развитию, во многом из-за сложности создания ПО и инструментария для VLIW. Кроме того, уже в 1999 году была анонсирована архитектура AMD x86_64, обратно совместимая с 32-бит x86. Появление такого конкурента не просто сдержало развитие Itanium IA-64, но и способствовало её упадку. В частности, уже в 2004 году Intel начала применять x86_64 в своём процессоре Xeon (Nocona). В 2021 году Intel прекратила поставки Itanium.

На мероприятии Open Source Summit Europe редактор Linux Weekly News Джонатан Корбет (Jonathan Corbet) сообщил о том, что срок долгосрочной поддержки (LTS) ядер Linux, вероятно, будет сокращён с шести до двух лет. Заявление вызвало обеспокоенность в сообществе open source, и на этом фоне компания Canonical обнародовала собственные планы в отношении поддержки Ubuntu.

Все версии Ubuntu подразделяются на две категории: «обычные» и LTS. В первом случае срок поддержки составляет девять месяцев. В случае LTS-редакций, которые выходят раз в два года, стандартная поддержка достигает пяти лет. При этом клиенты могут продлить период обслуживания до 10 лет с помощью платной опции Expanded Security Maintenance (ESM).

Canonical отмечает, что в дальнейшем планирует сохранить такую практику. Несмотря на изменения в поддержке LTS в целом, пользователи Ubuntu смогут рассчитывать на сопровождение ядер, получение обновлений безопасности и других критических апдейтов ОС в течение десятилетнего периода.

Источник изображения: Canonical

«Приверженность Canonical долгосрочной поддержке приобретает ещё большее значение в свете возможных изменений в обслуживании ядра Linux. Безопасность является ключевым элементом программной инфраструктуры. Canonical по-прежнему стремится предоставлять сообществу Linux безопасное ядро Ubuntu LTS на десятилетия вперёд», — говорится в заявлении компании.

Таким образом, LTS-версия Ubuntu 22.04 и ядро Linux 5.15, лежащее в её основе, будут поддерживаться до апреля 2032 года. В свою очередь, редакция Ubuntu 24.04 получит поддержку до апреля 2034-го.

В современных ИИ-системах огромную роль играет перемещение больших объёмов данных, однако механика этого перемещения далеко не оптимальны. Google представила экспериментальную реализацию механизма Device Memory TCP для ядра Linux, который позволяет избавиться от ненужного копирование данных в буфер хост-системы, сообщает Phoronix.

Инициатива Device Memory TCP как раз и нацелена на то, чтобы избавиться от лишних перемещений больших объёмов данных при копировании их с устройств хранения на удалённые ускорители GPU/TPU в тех случаях, когда эти данные не требуют обработки хост-системой. То есть Devmem TCP позволяет открыть прямой сетевой доступ к ресурсам памяти GPU, TPU и прочих сопроцессоров.

Google: TPU Pod. В системах такого масштаба использование Devmem TCP позволит существенно поднять эффективность

Если технология Devmem TCP будет внедрена в Linux, то в ОС появятся новые API для работы с сокетами, позволяющие непосредственно отсылать содержимое памяти по сети, а также и принимать напрямую в память пакеты, приходящие из сети, без промежуточной буферизации. По словам Google, это позволит существенно снизить нагрузку на подсистемы памяти и более эффективно использовать доступную пропускную способность PCI Express. В тестовой реализации уже удалось добиться утилизации сетевого канала на уровне 96,6 %.