Основное внимание при подготовке новой редакции было уделено повышению производительности и эффективности кодирования. На уровне битового потока (bitstream) Theora 1.2 полностью соответствует стандартизированному в 2004 году формату кодирования видео Theora. API и ABI интерфейсы новой версии также сохраняют полную совместимость с прошлыми выпусками Theora. В состав Theora 1.2 включены 190-страничная спецификация, документация на API, черновик спецификации RTP-расширений для потокового вещания и эталонные реализации кодировщика и декодировщика.

Главным изменением в Theora 1.2 стала новая реализация эталонного кодировщика, предложенного под кодовым именем "Ptalarbvorm". В новой реализации значительно повышена производительность и обеспечен более высокий уровень сжатия. При этом создаваемые новым кодировщиком файлы полностью совместимы с декодировщиками, предлагавшимися в прошлых версиях.

Кроме того, в Theora 1.2 проведена оптимизация эталонного декодировщика, добавлена поддержка платформы RISC OS и значительно улучшена поддержка архитектуры ARM. Добавлены оптимизации для CPU ARM и DSP TI C64x+. Предложено три уровня скорости кодирования (старый уровень 2 переименован в 3, а вместо второго предложен новый промежуточный уровень).

1. OpenNews: Разработчики Chrome и Firefox рассматривают возможность прекращения поддержки видеокодека Theora
2. OpenNews: Финальный релиз видеокодека Theora 1.1
3. OpenNews: Сообщество Xiph.Org представило видеокодек Daala с технологиями, опережающими VP9 и H.265/HEVC
4. OpenNews: Доступен аудиокодек Opus 1.5
5. OpenNews: Опубликован свободный звуковой кодек FLAC 1.5

Спектральные изображения содержат не только информацию об интенсивности света в трех основных цветовых каналах (RGB), но охватывают часть ультрафиолетового и инфракрасного диапазонов. Подобные изображения используются в таких областях, как высококачественный рендеринг, анализ материалов и визуализация научных данных. Например, спектральные изображения могут использоваться для точного моделирования реальных оптических эффектов при рендеринге, для оценки того, как выглядит краска при различном освещении, и для идентификации материалов по их световым сигнатурам.

Съёмка с захватом диапазонов вне видимого спектра даёт возможность более точно моделировать взаимодействие света с материалами, но приводит к значительному увеличению информации, хранимой для каждого пикселя. Спектральные изображения могут включать десятки каналов, охватывающих различные диапазоны длин волн, и использовать для каждого канала 16- или 32-разрядные числа с плавающей запятой, что позволяет охватить более широкий диапазон значений яркости, чем на обычных фотографиях. Ценой подобной возможности становится существенное увеличение размера по сравнению с традиционными изображениями. В качестве примера упомянуто изображение с 81 дополнительным спектральным каналом, занимающее в формате OpenEXR 300 МБ. При помощи Spectral JPEG XL данное изображение удалось сжать до 3.9 МБ без потери спектральных характеристик.

Для сокращения размера Spectral JPEG XL использует разделение данных о яркости и форме спектра, и применяет дискретное косинусное преобразование, позволяющее сохранить основные спектральные характеристики, но отбросить несущественные высокочастотные спектральные детали. Суть метода в преобразовании плавного изменения волновых характеристик в набор волновых коэффициентов (коэффициентов частоты), при совмещении воссоздающих исходную спектральную информацию.

Более высокочастотные спектральные коэффициенты затем нормируются по отношению к общей яркости, что позволяет агрессивнее сжимать менее значимые данные. Идея в том, что с точки зрения восприятия наиболее важна средняя яркость и она сохраняется с наиболее высоким качеством, а коэффициенты высоких частот не столь важны и к ним применяется более высокий уровень сжатия и опционально более низкие разрешения. После этого информацию обрабатывает кодек, реализованный на базе существующего движка сжатия, разработанного для формата JPEG XL.

1. OpenNews: Уязвимости в реализации JPEG XL из состава FFmpeg
2. OpenNews: Samsung обеспечил поддержку формата изображений JPEG XL
3. OpenNews: В Safari 17 и WebKit включена поддержка формата изображений JPEG XL
4. OpenNews: Google упраздняет поддержку JPEG XL в Chrome
5. OpenNews: Представлен формат сжатия изображений QOI

CMake примечателен предоставлением простого языка сценариев, средствами расширения функциональности через модули, поддержкой кэширования, наличием инструментов для кросс-компиляции, поддержкой генерации файлов сборки для широкого спектра систем сборки и компиляторов, наличием утилит ctest и cpack для определения сценариев тестирования и сборки пакетов, утилитой cmake-gui для интерактивной настройки параметров сборки.

Основные изменения:

• Прекращена совместимость с версиями CMake до выпуска 3.5. При привязке к неподдерживаемым версиям в функциях cmake_minimum_required() и cmake_policy() теперь будет выводиться ошибка.
• Добавлена переменная окружения "CMAKE_POLICY_VERSION_MINIMUM" для переопределения минимальной версии CMake, функциональность которой необходима для сборки проекта. Добавленная переменная позволяет обойтись без изменения вызовов cmake_minimum_required(VERSION) и cmake_policy(VERSION) в самом проекте, например, для настройки политики версий в проектах, не предусматривающих такую возможность.
• В выражение генератора "$<PATH>" добавлена операция "NATIVE_PATH" для преобразования файлового пути из представления CMake (для разделения каталогов всегда используется "/"), в системный путь (в Unix-подобных системах используется "/", а в Windows - "\").
• На платформе macOS при использовании генераторов сборочных сценариев на базе инструментария Ninja и генераторов Makefile, если в каталоге "/usr/bin" присутствует компилятор, то он отныне оставляется как есть, без привязки к компилятору в Xcode. При сборке для платформы macOS по умолчанию прекращён выбор SDK и передача компилятору флага "-isysroot" (SDK теперь выбирает сам компилятор, а не CMake).
• Добавлено свойство LINK_WARNING_AS_ERROR, при котором предупреждения компоновщика будут трактоваться как ошибки. Для отключения действия данного свойства добавлена опция командной строки "--link-no-warning-as-error".
• В утилиту cmake добавлена опция "--project-file" для задания альтернативного имени файла CMakeLists.txt.
• В генератор CPack добавлена возможность создания несжатых tar-архивов.
• В команду target_link_libraries() и переменные CMAKE_EXE_LINKER_FLAGS*, CMAKE_SHARED_LINKER_FLAGS*, CMAKE_MODULE_LINKER_FLAGS* добавлена поддержка префикса "LINKER:".
• Добавлены новые переменные:
  • CMAKE_EXECUTE_PROCESS_COMMAND_ERROR_IS_FATAL,
  • CMAKE_<LANG>_LINK_MODE,
  • CMAKE_<LANG>_DEVICE_LINK_MODE,
  • CMAKE_LINK_WARNING_AS_ERROR,
  • CMAKE_MSVC_RUNTIME_CHECKS,
  • CMAKE_DEBUGGER_WORKING_DIRECTORY,
  • CMAKE_XCODE_SCHEME_LLDB_INIT_FILE,
  • CMAKE_XCODE_SCHEME_TEST_CONFIGURATION.
• Добавлены новые свойства: DEBUGGER_WORKING_DIRECTORY и VS_SOLUTION_ITEMS (для прикрепления файлов к .sln для Visual Studio).
• Обеспечено формирование готовых сборок CMake для SunOS для архитектур sparc64 и x86_64.

1. OpenNews: Релиз системы сборки CMake 3.28
2. OpenNews: Facebook опубликовал систему сборки Buck2
3. OpenNews: Проект Сicada развивает систему автоматизации сборок, похожую на GitHub Actions
4. OpenNews: Выпуск сборочной системы Meson 1.7.0
5. OpenNews: Компания Apple открыла код сборочной системы Swift Build

Пространства имён (namespace) в ядре Linux позволяют привязать к разным процессам разные представления ресурсов, например, процесс может быть помещён в окружение со своими точками монтирования, IPC, PID и сетевым стеком, которые не пересекаются с окружением других процессов. При помощи "user namespace" непривилегированный процесс в контексте изолированного контейнера может обращаться к подсистемам ядра, в обычных условиях требующих повышенных привилегий, но оставаться при этом непривилегированным вне контейнера.

Проблема в том, что изначально многие подсистемы ядра были написаны с расчётом на то, что работать с ними может только пользователь root, и проблемы в подобных подсистемах не рассматривались как уязвимость, так как непривилегированные пользователи не могли к ним обращаться. После того, как появился "user namespace" ошибки в подобных подсистемах стали иметь иное значение - эксплуатация уязвимости в ядре из изолированного окружения приводила к выполнению кода на уровне ядра и позволяла получить привилегированный доступ ко всей системе.

В Ubuntu в качестве дополнительного уровня защиты была реализована гибридная схема, выборочно оставляющая некоторым программам возможность создавать "user namespace" при наличии профиля AppArmor с правилом "allow userns create" или прав CAP_SYS_ADMIN. Подобная защита позволяла уменьшить риск эксплуатации уязвимостей в подсистемах ядра (сократить поверхность атаки), но при этом сохранить возможность полноценной sandbox-изоляции в избранных приложениях.

Создание "user namespace" с привилегированным доступом внутри контейнера представляет угрозу только если в системе не установлены все доступные обновления и в ядре присутствует известная неисправленная уязвимость. Выявлено три способа обхода механизма ограничения доступа к "user namespace", позволяющих непривилегированному локальному пользователю создать "user namespace" c привилегиями администратора внутри, достаточными для выполнения эксплоитов, требующих прав CAP_SYS_ADMIN или CAP_NET_ADMIN:

• Атакующий может использовать утилиту aa-exec, входящую в базовую поставку, для применения к себе имеющихся в системе профилей AppArmor, среди прочего и тех, что разрешают доступ к "user namespace". Например, можно применить к своему процессу профили от chrome, flatpak и trinity.

  
     $ aa-exec -p trinity -- unshare -U -r -m /bin/sh
  

• Атакующий может запустить командную оболочку из пакета busybox, поставляемого по умолчанию и снабжённого профилем AppArmor, допускающим создание "user namespace".

  
     $ busybox sh
     ~$ /usr/bin/unshare -U -r -m /bin/sh
  

• Атакущий может использовать переменную окружения LD_PRELOAD для загрузки своей библиотеки в контексте любой программы, имеющей AppArmor-профиль для доступа к "user namespace". Например, подобные права имеет файловый менеджер nautilus в Ubuntu Desktop.

  
     LD_PRELOAD=./shell.so /usr/bin/nautilus
  

Для блокирования найденных лазеек разработчики Ubuntu рекомендуют отключить возможность изменения профилей AppArmor утилитой aa-exec, выставив настройку "sysctl kernel.apparmor_restrict_unprivileged_unconfined=1". Также рекомендовано деактивировать профили AppArmor у приложений, имеющих доступ к "user namespace". В поставке по умолчанию подобные профили присутствуют у busybox и nautilus, а для проверки наличия отдельно установленных программ с подобными правами можно использовать команду "sudo aa-status --filter.mode=unconfined". Для отключения AppArmor-профилей busybox и nautilus (если не требуется использование утилит busybox с "user namespace" и можно обойтись без генерации миниатюр в nautilus) следует использовать команды:

   sudo ln -s /etc/apparmor.d/busybox /etc/apparmor.d/disable
   sudo apparmor_parser -R /etc/apparmor.d/busybox
   sudo ln -s /etc/apparmor.d/nautilus /etc/apparmor.d/disable
   sudo apparmor_parser -R /etc/apparmor.d/nautilus

Дополнительно можно отметить раскрытие сведений об уязвимости (CVE-2025-0927) в драйвере HFS+, позволяющей получить root-привилегии в системе. Проблема вызвана переполнением буфера, возникающем при обработке специально сформированных образов ФС. Для эксплуатации уязвимости требуется доступ к созданию "user namespace" или монтированию дисковых образов (например, пользователям Ubuntu с активным локальным сеансом polkit предоставляет право создания loop-устройств и монтирования блочных устройств, применяемые для автоподключения USB Flash). Проблема проявляется только в ядрах Linux до версии 6.12. Опубликован рабочий эксплоит, использование которого продемонстрировано в Ubuntu 22.04 с ядром 6.5.0-18-generic.

1. OpenNews: Уязвимости в утилите needrestart, позволяющие получить root-доступ в Ubuntu Server
2. OpenNews: Уязвимость в OpenSSH, позволяющая удалённо выполнить код с правами root на серверах с Glibc
3. OpenNews: Уязвимость в glibc, позволяющая получить root-доступ в системе
4. OpenNews: Уязвимость в Glibc ld.so, позволяющая получить права root в большинстве дистрибутивов Linux
5. OpenNews: Локальная уязвимость в ядре Linux, эксплуатируемая через nftables

Основные изменения:

• Рабочий стол обновлён до выпуска GNOME 48, в котором реализована поддержка HDR, тройной буферизации, стековой компоновки уведомлений, глобальных сочетаний клавиш. Расширен конфигуратор. Добавлены оптимизации потребления памяти и производительности.
• В Ubuntu Desktop вместо Evince для просмотра PDF задействована программа Papers (форк Evince, переведённый на GTK4 и частично переписанный на языке Rust).
• По умолчанию задействована обвязка xdg-terminal-exec, упрощающая замену эмулятора терминала, вызываемого комбинацией клавиш Ctrl+Alt+T.
• После сворачивания проекта Mozilla Location Service, сервисы определения местоположения переведены на базу BeaconDB с информацией о размещении известных точек беспроводного доступа.
• Отключено по умолчанию звуковое сопровождение запуска системы.
• В инсталлятор в Ubuntu Desktop добавлен режим для замены существующих установок Ubuntu. При установке в режиме двойной загрузки, если в системе уже используются другие операционные системы, разрешена установка на шифрованные разделы и предоставлены расширенные настройки для дисковых разделов. Добавлена возможность установки Ubuntu на одном накопителе с Windows-системами, использующими шифрованные разделы на базе BitLocker.
• Вместо публикации отдельных сборок, специфичных для каждого ARM64-устройства, дистрибутив перешёл к предоставлению одного общего ISO-образа Ubuntu Desktop для устройств на базе архитектуры ARM64. Образ можно использовать для установки на рабочих станциях с процессорами Ampere, ноутбуках с чипами Snapdragon и в виртуальных машинах на Mac-системах Apple Silicon.
• Улучшены возможности для использования устройств на базе архитектуры ARM64 в качестве рабочих станций с графическим окружением. Добавлена поддержка новых устройств, например, на базе Qualcomm Snapdragon X Elite 13. Добавлены пакеты ubuntu-x1e-settings и qcom-firmware-extract.
• В дополнение к initramfs-tools добавлена опциональная поддержка инструментария Dracut для формирования образов начального RAM-диска (initrd). В Ubuntu осеннем выпуске 25.10 инструментарий Dracut намерены задействовать по умолчанию. Из проблем с initramfs-tools, которые будут решены после перехода на Dracut, упомянуты: невозможность использования systemd в initrd, отсутствие поддержки NVMe over Fabric (NVM-oF), сложность сопровождения из-за раздельной работы с initrd и корневой ФС, стагнация разработки initramfs-tools и обилие кода на shell в initrd.
• В репозиторий добавлен инструментарий crypto-config, предназначенный для работы с общим для всей системы профилем настроек, связанных с криптографией. В настоящее время доступны профили default, legacy и future.
• Обновлены системные пакеты: ядро Linux 6.14, glibc 2.41, systemd 257.4, binutils 2.44, OpenSSL 3.4.1, GnuTLS 3.8.9, BlueZ 5.79, NetworkManager 1.52, Pipewire 1.2.7, Poppler 25.03, xdg-desktop-portal 1.20.
• Обновлены средства для разработчиков: GCC 14.2, LLVM 20, Python 3.13.2, Go 1.24, Rust 1.84, .NET 9.0, PHP 8.4, Ruby 3.3, OpenJDK 24, PostgreSQL 17, Valkey (форк Redis) 8.0.2, MySQL 8.4.4, Qt 6.8.3.
• Обновлены пользовательские приложения: GIMP 3.0, LibreOffice 25.2, Firefox 136, Thunderbird 128.
• Обновлены серверные пакеты: Nginx 1.26.3, Apache httpd 2.4.63, OpenSSH 9.9, cloud-init 24.3.1, runc 1.2.5, Docker 27.5.1, Containerd 2.0.2, HAProxy 3.0.7, libvirt 10.10.0, ClamAV 1.4.2, OpenLDAP 2.6, QEMU 9.2.0, Squid 6.13, SSSD 2.10.1, Samba 4.21.
• В Chrony для синхронизации времени по умолчанию задействованы серверы точного времени от проекта Ubuntu, использующие протокол NTS.
• Командная оболочка Fish обновлена до ветки 4.0, переписанной на Rust.
• На ноутбуках с GPU NVIDIA по умолчанию включён сервис nvidia-powerd, обеспечивающий поддержку механизма Dynamic Boost, позволяющего балансировать энергопотребление между CPU и GPU для повышения производительности.
• Прекращено создание файла /run/utmp с данными о пользователях, в данный момент работающих в системе. Формат utmp, в котором задействовано 32-разрядное значение time_t, признан устаревшим из-за подверженности проблеме 2038 года. В следующем выпуске будет прекращена поддержка cgroup v1 и сервисов, запускаемых через скрипты в стиле System V init.
• Инструментарий для настройки параметров сети обновлён до выпуска Netplan 1.1.2, в котором появилась возможность использования метода аутентификации "wpa-psk-sha256" в беспроводных сетях и добавлена поддержка параметра "routing-policy" в NetworkManager.
• В сборки для плат Raspberry Pi добавлен стек для работы с камерами, основанный на libcamera 0.4 и libpisp. Для начальной настройки системы задействован пакет gnome-initial-setup, выполняемый при первом запуске. Утилиты libraspberry-bin заменены на raspi-utils. Обеспечена возможность загрузки по сети при помощи nbd-client.
• Продолжена работа над атомарно обновляемым вариантом Ubuntu Core Desktop, использующим технологии Ubuntu Core и включающим только приложения, оформленные с использованием пакетов в формате Snap.
• В Xubuntu задействован выпуск среды рабочего стола Xfce 4.20.
• В Ubuntu Cinnamon предложена версия рабочего стола Cinnamon 6.4.8. Проведена чистка пакетов, в которых нет необходимости, позволившая немного сократить размер сборки. Улучшена тема оформления Yaru-Cinnamon. Добавлены тёмный и светлый варианты применяемых по умолчанию обоев рабочего стола.
• В Ubuntu Mate продолжает поставляться рабочий стол MATE 1.26.
• В Lubuntu включён выпуск среды рабочего стола LXQt 2.1.0. Осуществлён переход с ветки Qt 6.6 на Qt 6.8. Значительно ускорена работа инсталлятора, основанного на фреймворке Calamares.
• В Ubuntu Studio по умолчанию использован рабочий стол KDE Plasma 6.3 и тёмный набор пиктограмм на панели. Обновлены версии программ, например, доступны Darktable 5.0.0, Ardour 8.12.0, Qtractor 1.5.3, Audacity 3.7.3, digiKam 8.5.0, Kdenlive 24.12.3, Krita 5.2.9 и GIMP 3.0.0.
• В Kubuntu задействованы выпуски KDE Plasma 6.3, Qt 6.8, KDE Frameworks 6.12.0 и KDE Gear 24.12.3. По умолчанию предложен сеанс на базе Wayland, а поддержка X11 реализована в форме опции.

1. OpenNews: В Ubuntu 25.10 решено заменить GNU Coreutils на uutils, написанные на Rust
2. OpenNews: В Ubuntu 25.04 появится поддержка Dracut и будут унифицированы сборки для ARM64
3. OpenNews: Выпуск Ubuntu 24.04.2 LTS c обновлением графического стека и ядра Linux
4. OpenNews: Разработчики Ubuntu проанализировали эффективность включения оптимизации PGO
5. OpenNews: Ubuntu переходит на использование самых свежих версий ядра в предстоящих релизах

Трою пришло письмо от имени сервиса Mailchimp c предупреждением о приостановке работы его списка рассылки и необходимости выполнения определённых проверок. Трой перешёл по ссылке в письме, ввёл на открывшейся странице параметры учётной записи в Mailchimp, подтвердил запрос двухфакторной аутентификации и страница зависла...., а атакующие получили доступ к пользовательской базе его списка рассылки и выгрузили сведения о email и IP-адресах 16627 подписчиков. Примечательно, что в выгрузку вошли 7535 адресов пользователей, ранее отписавшихся от рассылки, но сервис Mailchimp сохранил их несмотря на отписку и включил в экспортируемые данные.

Трой не стал умалчивать свою оплошность и подробно разобрал инцидент в своём блоге, а также добавил информацию об утечке на свой сервис haveibeenpwned.com. Трой считает, что он не заподозрил подвоха из-за стечения нескольких факторов. Во время получения письма Трой был в поездке, не адаптировался после смены часовых поясов и был сильно уставшим. Письмо было прочитано именно в тот момент, когда бдительность была подавлена.

Вторым фактором стало то, что письмо вначале было просмотрено на iPhone с почтовым клиентом Outlook, который показал только имя отправителя и не отобразил email. Затем, когда письмо было повторно открыто утром на компьютере, Трой не стал перепроверять параметры и не обратил внимание на то, что письмо отправлено с подозрительного адреса "hr@group-f.be".

Текст был стилизован под стандартное сообщение Mailchimp и предупреждал об ограничении отправки рассылки из-за получения жалобы на спам. Информация была подана ровно в той мере, чтобы вызвать беспокойство, но не переусердствовать. В письме предлагалось проверить недавно отправленные рассылки и предпринять действия для разблокировки. По ссылке вместо mailchimp.com открылся сайт mailchimp-sso.com. Менеджер паролей 1Password автоматически не заполнил форму входа, но и это было проигнорировано. После зависания формы аутентификации Трой очнулся и перезашёл на реальный сайт Mailchimp, но было уже поздно - атакующие использовали захваченные учётные данные для получения токена для доступа к API и выполнили экспорт информации.

1. OpenNews: Взлом Internet Archive привёл к утечке 31 миллиона учётных записей
2. OpenNews: В Chrome добавлен AI-режим для автоматической смены скомпрометированных паролей
3. OpenNews: Mozilla отказывается от сервиса Onerep из-за связи его основателя со сбором информации о людях
4. OpenNews: Открыт код сервиса проверки паролей HaveIBeenPwned
5. OpenNews: Сервис проверки скомпрометированных учётных записей опубликовал 500 млн паролей

Во всём репозитории Debian 12, насчитывающем 33223 исходных пакетов, поддержка повторяемых сборок достигла 96.9% для архитектуры x86_64 и 96.5% для архитектуры ARM64. В репозиториях Debian Testing уровень повторяемых сборок оценён в 96.5% для архитектуры ARM64 и 96.3% для x86_64 при пересборке 37322 исходных пакетов. Тест повторяемых сборок в репозитории Debian Testing провален для 819 пакетов (2.2%), а у 428 пакетов (1.1%) возникли общие проблемы при компиляции из исходного кода. Для сравнения в Arch Linux возможность повторяемой сборки реализована для 86.3% пакетов из репозиторев core и extra, насчитывающих 12800 пакетов. В репозитории openSUSE Factory, насчитывающем 15754 пакета, уровень повторяемых сборок составляет 98.24%.

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

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

1. OpenNews: openSUSE тестирует поддержку повторяемых сборок
2. OpenNews: В NixOS обеспечена поддержка повторяемых сборок для iso-образа
3. OpenNews: Доступен rebuilderd для независимой верификации Arch Linux при помощи повторяемых сборок
4. OpenNews: Связывание повторяемых сборок GNU Guix с архивом исходных текстов Software Heritage
5. OpenNews: Для 94% пакетов Debian обеспечена возможность повторяемой сборки

Изначально возможность использования Linux в роли хост-окружения для системы виртуализации Hyper-V была представлена в 2020 году. Linux для управления Hyper-V уже применяется в дистрибутиве Azure Linux и инфраструктуре Microsoft, но для сторонних проектов подобная возможность была доступна только в форме отдельных патчей. Теперь данные патчи включены в основной состав ядра. Драйверы Hyper-V для гостевых систем были добавлены в ядро Linux в 2009 году и поставляются начиная с выпуска 2.6.32.

Необходимость использования Linux для управления гипервизором Hyper-V обусловлена желанием упростить сопровождение и повысить производительность серверов, обслуживающих облачные системы Microsoft, в условиях того, что с 2018 года число гостевых систем с Linux в облачном сервисе Azure превышает число окружений с Windows.

Отдельно компания Microsoft опубликовала обновление открытого проекта Hyperlight, развивающего гипервизор для встраивания в приложения. Гипервизор оформлен в виде разделяемой библиотеки, обеспечивающей выполнение отдельных функций в легковесных виртуальных машинах (micro-VM) и организующей обмен данными с этими функциями. Hyperlight может потребоваться, например, при необходимости изоляции части кода, не заслуживающего доверия или требующего особой защиты.

Из изменений отмечается реализация надстройки hyperlight-wasm, позволяющей запускать в отдельных виртуальных машинах Wasm-модули и компоненты, скомпилированные в промежуточный код WebAssembly. Предполагается, что использование виртуальной машины обеспечит более надёжную изоляцию при необходимости запуска стороннего WebAssembly-кода. Hyperlight-Wasm может использоваться в Windows (WHP - Windows Hypervisor Platform) и в Linux (KVM или Hyper-V через /dev/mshv).

Для выполнения WebAssembly-кода применяется специальный урезанный образ гостевой системы, применяющий runtime Wasmtime для запуска WebAssembly-компонентов, скомпилированных из кода на различных языках программирования. В виртуальной машине используется единый линейный фрагмент памяти. Работа осуществляется без виртуальных устройств, без операционной системы и без разделения на процессы. Запуск виртуальной машины производится с минимальными задержками и накладными расходами - создание легковесной виртуальной машины hyperlight занимает всего 1-2 миллисекунды, что в 100 раз меньше, чем при запуске обычной виртуальной машины.

Дополнительно можно отметить принятие в ветку ядра Linux 6.15 патча с поддержкой блочных устройств, у которых размер блока превышает страницу памяти. Например, Linux теперь сможет работать с устройствами с размером сектора 64Кб на системах со страницами памяти, размером 4Кб.

1. OpenNews: Первый выпуск платформы виртуализации SEAPATH
2. OpenNews: Microsoft открыл Hyperlight, гипервизор для изоляции отдельных функций в приложениях
3. OpenNews: Microsoft открыл код гипервизора OpenVMM и платформы паравиртуализации OpenHCL
4. OpenNews: Microsoft реализовал поддержку корневого окружения для Hyper-V на базе Linux
5. OpenNews: Microsoft начал продвижение в ядро Linux компонентов хост-окружения Hyper-V

В настоящее время какие-то части платформы, такие как Bluetooth-стек, развиваются публично, а какие-то вначале создаются во внутреннем репозитории Google и становятся доступны только при публикации кода очередного релиза. Публикация кода с новыми API зависит от их пригодности для тестирования - для некоторых версий Android код реализаций API публиковался до релиза, а для некоторых - после. Кроме Google доступ к внутренней ветке имеют производители устройств, подписавшие лицензионное соглашение GMS (Google Mobile Services).

Компания Google решила отказаться от практикуемой до сих пор смешанной модели и в будущем перенесёт разработку всех компонентов Android в свою внутреннюю ветку. Вместо двух веток - открытой и внутренней, при разработке будет использоваться только внутренняя ветка, код из которой станет открываться в привязке к релизам.

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

Предполагается, что изменение не повлияет на разработчиков производных продуктов и прошивок, основанных на AOSP, так как подобные сборки, как правило, формируются на основе определённых тегов или веток в репозитории, а не используют находящуюся в разработке нестабильную ветку "main". Затруднения могут возникнуть у разработчиков, заинтересованных в отслеживании изменений - вместо анализа непрерывного потока изменений придётся изучать целиком все изменения в релизе. Усложнится и участие сторонних разработчиков, желающих вносить свой вклад в проект, так как состояние кодовой базы в AOSP будет сильно отставать от ветки, находящейся в разработке.

Целью изменения называется желание упростить процесс разработки Android. Наличие двух веток, при том, что часть компонентов развивается в одной ветке, а часть в другой, приводит к тому, что по мере разработки релиза в ветках накапливаются различия и Google приходится тратить ресурсы на синхронизацию изменений и слияние патчей между открытой и внутренней ветками. Основная работа по развитию API ведётся во внутренней ветке, и открытая ветка часто сильно отстаёт от неё, что приводит к возникновению конфликтов при переносе во внутреннюю ветку изменений из компонентов, развиваемых в открытой ветке.

1. OpenNews: Vulkan стал официальным графическим API платформы Android. Третий бета-выпуск Android 16
2. OpenNews: Google прекратил поддержку приложений Dialer и Messaging в открытой кодовой базе Android
3. OpenNews: Google намерен перевести Chrome OS на платформу Android
4. OpenNews: Методы безопасной работы с памятью позволили существенно снизить число уязвимостей в Android
5. OpenNews: Выпуск мобильной платформы Android 15

В качестве золотого стандарта, на который стоит ориентироваться при создании нового менеджера входа, отмечен GDM (GNOME Display Manager). GDM базируется на технологиях GNOME Shell и Mutter, и сильно завязан на них, что позволило добиться уровня интеграции с GNOME, недостижимого при использовании SDDM. В Plasma Login Manager пытаются воплотить похожую на GDM архитектуру, позволяющую более тесно интегрировать менеджер входа со средой рабочего стола KDE Plasma и композитным сервером Кwin.

Проблемы возникли из-за того, что SDDM развивается как универсальный менеджер входа, написанный на Qt и подходящий для всех графических окружений. SDDM рассчитан на вывод одного окна с экраном входа, но разработчикам KDE требуется более тесная интеграция, чем просто окно, показывающее сеансы и пользователей. В SDDM также применяется собственная реализация функций управления энергопотреблением со своей системой настройки. Без усложнений SDDM не получается интегрировать с имеющимися в KDE Plasma средствами управления громкостью, яркостью, энергопотреблением и сетевыми соединениями. В SDDM также имеется проблема с дублированием функциональности, которая уже имеется в KDE, что значительно усложняет сопровождение.

В итоге был подготовлен прототип нового многопроцессного менеджера входа Plasma Login Manager, использующий бэкенд на основе урезанной версии SDDM и механизм запуска, идентичный тому, что применяется для запуска сеанса рабочего стола KDE Plasma. Оформление экрана входа приближено к существующему блокировщику экрана KDE, а настройки унифицированы с KDE Plasma. Разработчики отказались от использования QML для кастомизации тем оформления в пользу поддержки существующих плагинов обоев рабочего стола, цветовых схем и тем оформления Plasma.

Для тестирования доступен рабочий прототип Plasma Login Manager, который пока не доведён до уровня качества, пригодного для использования в стабильной ветке KDE Plasma. Бэкенд на основе кода SDDM и новый фронтэнд, а также модуль для конфигуратора (KCM) пока развиваются в отдельных репозиториях, которые в будущем планируют объединить. По возможностям Plasma Login Manager почти достиг паритета со старым менеджером входа.

Среди возможностей, которые намерены реализовать в Plasma Login Manager:

• Качественная работа в конфигурациях с несколькими мониторами, экранами с высокой плотностью пикселей и HDR.
• Переключение раскладки клавиатуры.
• Возможность использования виртуальной клавиатуры.
• Поддержка ввода на китайском, японском, корейском и вьетнамском языках.
• Управление подсветкой экрана и клавиатуры.
• Полноценное управление энергопотреблением.
• Поддержка экранных ридеров.
• Возможность сопряжения с Bluetooth-устройствами.
• Возможность подключения к известным точкам доступа Wi-Fi.
• Поддержка удалённой работы через VNC/RDP.

1. OpenNews: Инцидент с темой оформления KDE, удаляющей пользовательские файлы
2. OpenNews: Для Wayland развивается расширение для перезапуска оконной среды без остановки приложений
3. OpenNews: Представлены сервис идентификации MyKDE и механизм запуска KDE при помощи systemd
4. OpenNews: SDDM рекомендован в качестве дисплейного менеджера для KDE Plasma 5
5. OpenNews: Локальная уязвимость в дисплейном менеджере SDDM

Opkssh совместим с OpenID-провайдерами Google, Microsoft/Azure и Gitlab, что позволяет настроить вход через имеющиеся учётные записи в сервисах gmail.com, microsoft.com и gitlab.com. При использовании opkssh вместо не ограниченных по времени ключей SSH генерируются временные ключи, действующие считанные часы и формируемые на основе подтверждения от провайдера OpenID. Утечка подобных ключей после окончания срока действия не представляет угрозы безопасности. По умолчанию время действия ключа составляет 24 часа, после которых необходимо повторно идентифицировать себя через OpenID Connect.

Интеграция с OpenSSH основана на возможности создания расширений протокола SSH, допускающих прикрепление произвольных данных к сертификатам SSH. После прохождения аутентификации через OpenID Connect клиент формирует открытый ключ, содержащий PK-токен, подтверждающий принадлежность ключа заявленному пользователю. Токен интегрируется в протокол SSH через поле с дополнительными данными SSH-сертификата. Создание PK-токенов и их проверка на стороне сервера осуществляется с использованием криптографического протокола OpenPubKey.

OpenPubKey позволяет сгенерировать открытый ключ и привязать его к токену, выданному OpenID-провайдером. Через цифровую подпись провайдер подтверждает, что этот ключ создан заявленным аутентифицированным пользователем. Например, OpenID-провайдер Google может подтвердить, что пользователь аутентифицирован как test@gmail.com. На стороне севера выполняется проверка подписан ли прикреплённый токен провайдером OpenID и соответствует ли цифровая подпись заявленному открытому ключу, т.е. сервер может удостовериться, что именно пользователь test@gmail.com создал открытый ключ для подключившегося SSH-клиента.

Интеграция с OpenSSH организована через указание программы opkssh в файле конфигурации "sshd_config" через директиву "AuthorizedKeysCommand" (например: "AuthorizedKeysCommand /usr/local/bin/opkssh verify %u %k %t"). Настройка связывания учётных записей с OpenID Connect осуществляется на стороне сервера SSH. На стороне клиента SSH изменения настроек не требуется, но перед входом необходимо запустить команду "opkssh login" и в появившемся окне браузера выбрать провайдера OpenID и выполнить через него аутентификацию.

Утилита opkssh сгенерирует ключи SSH и получит PK-токен, подтверждающий, что пользователь прошёл аутентификацию и позволяющий проверить, что созданные ключи принадлежат заявленному пользователю. Открытый ключ SSH, к которому через поле с дополнительными данными прикреплён PK-токен, будет записан в файл ~/.ssh/id_ecdsas и начнёт передаваться при подключении к серверу утилитой ssh.

Подключение к серверу производится с использованием штатной для SSH схемы "ssh логин@сервер", при этом на сервере логин предварительно должен быть отождествлён с учётной записью в OpenID, которую использует пользователь. Таким образом работа сводится к тому, что ssh-клиент отправляет на ssh-сервер публичный ключ, а сервер запускает команду "opkssh verify" для проверки ключа.

Для привязки учётной записи к OpenID администратор сервера выполняет команду "opkssh add". Например, для того чтобы разрешить вход на сервер под пользователем "root" с OpenID-аутентификацией через учётную запись test@gmail.com в Gmail следует выполнить "sudo opkssh add root test@gmail.com google", после чего клиент сможет подключаться под параметрами данной учётной записи командой "ssh root@хост_сервера".

Привязку учётной записи также можно выполнить вручную через файл конфигурации /etc/opk/auth_id (или ~/.opk/auth_id), в который для вышеприведённого примера будет записана строка "root test@gmail.com https://accounts.google.com". Дополнительно через файл /etc/opk/providers можно определить список допустимых OpenID-провайдеров, их параметры и список разрешённых идентификаторов клиентов.

1. OpenNews: Представлен OpenPubKey, протокол криптографической верификации объектов
2. OpenNews: Уязвимость в пакетах с OpenSSH из состава RHEL 9, допускающая удалённое выполнение кода
3. OpenNews: Уязвимость в поставляемом во FreeBSD варианте OpenSSH, допускающая удалённое выполнение кода
4. OpenNews: В OpenSSH код аутентификации вынесен в отдельный процесс sshd-auth
5. OpenNews: Обновление OpenSSH 9.9p2 с устранением возможности совершения MITM-атаки

Ingress-контроллер выступает в роли шлюза и используется в Kubernetes для организации доступа из внешней сети к сервисам внутри кластера. Контроллер ingress-nginx является наиболее популярным и применяет сервер NGINX для проброса обращений к кластеру, маршрутизации внешних запросов и балансировки нагрузки. Проект Kubernetes предоставляет базовые ingress-контроллеры для AWS, GCE и nginx, последний из которых никак не связан с контроллером kubernetes-ingress, сопровождением которого занимается компания F5/NGINX (рассматриваемые уязвимости не затрагивают проекты, развиваемые разработчиками NGINX, упоминание nginx в названии ingress-nginx связано лишь с задействованием nginx в качестве прокси).

Уязвимости позволяют неаутентифицированному атакующему добиться выполнения своего кода в контексте контроллера ingress-nginx, при возможности отправки запроса к web-обработчику Admission. В ходе сканирования сети выявлено более 6500 уязвимых кластеров Kubernetes, использующих общедоступные уязвимые контроллеры с открытым для внешних запросов обработчиком Admission.

В конфигурации по умолчанию запущенный атакующим код может получить доступ к настройкам объекта Ingress, в которых, среди прочего, хранятся и учётные данные для обращения к серверам Kubernetes, что позволяет добиться привилегированного доступа ко всему кластеру. В качестве обходного пути защиты рекомендуется отключить в ingress-nginx функцию "Validating Admission Controller".

Контроллер Admission запускается в отдельном pod-окружении и выполняет операцию проверки входящих ingress-объектов перед их развёртыванием. По умолчанию web-обработчик Admission принимает запросы без аутентификации из публичной сети. При выполнении проверки контроллер Admission создаёт конфигурацию для http-сервера nginx на основе содержимого полученного ingress-объекта и проверяет её корректность.

Выявленные уязвимости позволяют добиться подстановки своих настроек в nginx через отправку специально оформленного ingress-объекта напрямую в контроллер Admission. Исследователи обнаружили, что некоторые свойства проверочных запросов, выставленные в поле ".request.object.annotations", напрямую подставляются в конфигурацию nginx. При этом сгенерированная конфигурация не применяется, а лишь тестируется путём запуска исполняемого файла "nginx" c опцией "-t".

В частности, подстановка внешних данных в конфигурацию выполняется для параметров "mirror-target", "mirror-host" (CVE-2025-1098), "auth-tls-match-cn" (CVE-2025-1097) и "auth-url" (CVE-2025-24514). Например, в строке конфигурации "set $target {{ $externalAuth.URL }};" вместо "{{ $externalAuth.URL }}" подставляется URL, указанный в параметре "auth-url". При этом корректность URL не проверяется. Соответственно, атакующий может передать в качестве URL значение вида "http://example.com/#;\nнастройки" и подставить свои настройки в файл конфигурации.

Для выполнения произвольного кода в процессе проверки конфигурации командой "nginx -t" исследователи воспользовались тем, что помимо проверки синтаксиса nginx загружает библиотеки с модулями и открывает файлы, упомянутые в конфигурации, для оценки их доступности. Среди прочего, при обработке директивы ssl_engine производится загрузка указанной в директиве разделяемой библиотеки для SSL-движка.

Для загрузки своей библиотеки на сервер Kubernetes исследователи воспользовались (CVE-2025-1974) тем, что при обработке больших запросов nginx сохраняет тело запроса во временном файле, который сразу удаляется, но в файловой системе "/proc" для этого файла остаётся открытый файловый дескриптор. Таким образом, можно одновременно отправить запросы для сохранения временного файла и инициирования проверки конфигурации, в которой в директиве "ssl_engine" указан путь к дескриптору в файловой системе "/proc".

Для того, чтобы файловый дескриптор длительное время оставался доступен значение "Content-Length" в запросе можно указать заведомо большим, чем фактически переданные данные (сервер будет ждать приёма оставшихся данных). Дополнительной сложностью является необходимость угадать PID процесса и номер файлового дескриптора, связанного с загруженной разделяемой библиотекой, но так как в контейнере обычно используется минимальное число запущенных процессов, нужные значения угадываются путём перебора в несколько попыток. В случае успеха и загрузки подставленной разделяемой библиотеки, атакующий может получить доступ к хранимым внутри pod-окружения параметрам, достаточным для управления всем кластером.

Для проверки использования уязвимого ingress-nginx можно выполнить команду:

   kubectl get pods --all-namespaces --selector app.kubernetes.io/name=ingress-nginx

Дополнение: Опубликован готовый прототип эксплоита для тестирования проявления уязвимости.

1. OpenNews: Уязвимости в ingress-nginx, позволяющие скомпрометировать кластеры Kubernetes
2. OpenNews: Уязвимость в runc, позволяющая выбраться из контейнеров Docker и Kubernetes
3. OpenNews: Root-уязвимость из-за некорректных настроек в пакете nginx для Debian и Ubuntu
4. OpenNews: Критическая уязвимость в http-сервере Nginx
5. OpenNews: Уязвимость в runc, позволяющая выбраться из контейнеров Docker и Kubernetes

Инициатива пока позиционируется как отдельный эксперимент, который не будет влиять на разработку GRUB2. В качестве оптимального применения Rust в GRUB упоминается написание модулей для новых файловых систем. Также не исключается переписывание на Rust кода для работы с дисковыми разделами и GPT.

Предполагается, что использование Rust поможет проекту уменьшить вероятность появления некоторых видов ошибок, особенно в коде модулей, содержащем множество больших и сложных процедур парсинга. В феврале в результате аудита кодовой базы GRUB были выявлены 72 проблемы с безопасностью, 21 из которых признана опасной уязвимостью, пригодной для обхода механизма верифицированной загрузки UEFI Secure Boot. 20 из 21 уязвимости вызваны ошибками при работе с памятью, приводившими к переполнению буфера или обращению к памяти после её освобождения.

Дополнительно можно отметить выпуск проекта GNU Boot 0.1 RC6, в состав которого вошли вышеотмеченные исправления уязвимостей (в самом GRUB2 исправления продолжают распространяться в виде патчей без формирования отдельного релиза). Проект GNU Boot развивает замену проприетарным прошивкам UEFI и BIOS, основанную на CoreBoot, но применяющую более жёсткие требования к включению бинарных компонентов. GNU Boot преподносится как "coreboot-libre", т.е. как редакция CoreBoot, избавленная от блобов и несвободных компонентов, по аналогии с тем, как проект Linux-libre развивает очищенный вариант ядра Linux. Отдельно развиваются похожие проекты Libreboot и Canoeboot.

1. OpenNews: В загрузчике GRUB2 выявлена 21 уязвимость
2. OpenNews: Уязвимость в GRUB2, позволяющая обойти блокировку загрузки, нажав 28 раз Back Space
3. OpenNews: Уязвимость в патчах Red Hat к загрузчику GRUB2, позволяющая обойти проверку пароля
4. OpenNews: Релиз загрузочного менеджера GNU GRUB 2.12
5. OpenNews: Уязвимость в NTFS-драйвере из состава GRUB2, позволяющая выполнить код и обойти UEFI Secure Boot

Драйвер WinRing0 востребован в проектах, управляющих настройками оборудования, как свободных (OpenRGB, Libre Hardware Monitor, FanControl), так и проприетарных (SignalRGB, Razer Synapse 3). Среди программ, использующих драйвер, есть официальное ПО от десятков производителей оборудования, в том числе популярных. Стоит отметить, что драйвер был подписан самостоятельно автором (разработчиком CrystalDiskMark) и принят Microsoft.

Отмеченная Microsoft проблема, из-за которой произведена блокировка, связана с тем, что доступ к установленному в системе драйверу может получить любая программа, и посредством драйвера программа может манипулировать любым устройством в системе или повысить свои привилегии (CVE-2020-14979).

В свете произведённой блокировки, многие компании были вынуждены отреагировать. Например, SignalRGB перевели программу на использование собственной проприетарной замены, в то время как Steelseries полностью отключили в своём ПО функциональность для вывода показателей системы на встроенные экраны их оборудования.

На данный момент для WinRing0 выпущено исправление, ограничивающее использование драйвера только программами, запущенными с правами администратора, однако, из-за изменений политики Microsoft в отношении драйверов, получить для новой сборки подпись является затруднительным.

Китайская компания HYTE, разрабатывающая ПО для мониторинга оборудования HYTE Nexus, в котором также используется этот драйвер, вызвалась взять бюрократическую процедуру на себя, и анонсировала, что опубликует подписанную сборку для свободного использования. Тем не менее, даже если Microsoft примет обновлённый драйвер, множество программ для управления настройками оборудования и мониторинга потребуется запускать с правами администратора или адаптировать для работы с изменённым драйвером.

У драйвера WinRing0 существует единственный аналог под названием inpout32, который на данный момент не блокируется Windows Defender и антивирусами, однако он блокируется популярными античитами (наиболее известен этим Vanguard от RIOT, используемый в таких играх, как Valorant).

1. OpenNews: Большинство антивирусов оказались подвержены атаке через символические ссылки
2. OpenNews: Уязвимость в Symantec Antivirus, позволяющая получить полный контроль над системой
3. OpenNews: Проект GNU GMP заблокировал доступ с IP-адресов Microsoft из-за DDoS-атаки
4. OpenNews: Выпуск OpenRGB 0.8, инструментария для управления RGB-подсветкой периферийных устройств
5. OpenNews: Ошибка в обновлении к Windows блокировала загрузку Linux при использовании UEFI Secure Boot

В новую версию принято 12115 исправлений от 1984 разработчиков, размер патча - 39 МБ (изменения затронули 10170 файлов, добавлено 531586 строк кода, удалено 235999 строк). В прошлом выпуске было 14172 исправлений от 2086 разработчиков, размер патча - 46 МБ. Около 41% всех представленных в 6.14 изменений связаны с драйверами устройств, примерно 13% изменений имеют отношение к обновлению кода, специфичного для аппаратных архитектур, 14% связано с сетевым стеком, 7% - с файловыми системами и 4% c внутренними подсистемами ядра.

Основные новшества в ядре 6.14:

• Дисковая подсистема, ввод/вывод и файловые системы
  • В файловой системе Btrfs появилась поддержка новых методов балансировки операций чтения между накопителями, входящими в массив RAID1. Помимо ранее действующего распределения нагрузки на основе идентификаторов процессов (pid), в новой версии предложены три новых режима балансировки: "rotation" (равномерное распределение нагрузки по всем накопителям, режим включён по умолчанию); "latency" (распределение с учётом задержек, может быть полезным при сбоях или нестабильной работе накопителей); devid (ручное управление). Для изменения режима балансировки добавлен интерфейс "/sys/fs/btrfs/<UUID>/read_policy". Среди других изменений в Btrfs - реализация ioctl FS_IOC_READ_VERITY_METADATA.
  • Добавлен режим некэшируемого буферизированного ввода/вывода, при котором данные удаляются из страничного кэша сразу после того, как завершены операции по их чтению или записи. Изменение может быть полезным при использовании очень быстрых устройств хранения, кэширование операций с которыми в оперативной памяти избыточно. Для таких устройств новый режим позволяет исключить излишнее расходование памяти страничным кэшем не прибегая к использованию усложнённого API прямого ввода/вывода (Direct I/O).
  • В fsnotify, механизм отслеживания изменений в ФС, добавлено новое событие FS_PRE_ACCESS, генерируемое на стадии перед обращением к содержимому файла. Событие обрабатывается в синхронном режиме, т.е. ядро отправляет событие и ожидает получения ответа. Если ответ получен - операция выполняется, а если произошёл сбой - системный вызов возвращает в пространство пользователя код ошибки. При помощи FS_PRE_ACCESS процессом в пространстве пользователя, например, может быть организовано заполнение файла по мере готовности данных в медленном хранилище.
  • В подсистему FUSE, позволяющую создавать реализации файловых систем в пространстве пользователя, добавлена поддержка обмена данными между ядром и обработчиком в пространстве пользователя с использованием механизма ввода/вывода io_uring. Изменение позволяет повысить производительность FUSE за счёт сокращения переключений контекста между ядром и пространством пользователя.
  • В файловую систему XFS добавлена возможность использования обратного маппинга (rmap, reverse-mapping) в режиме работы с предсказуемыми задержками ("realtime device"). Обратный маппинг позволяет определить для хранения какого файла используется указанный блок на устройстве хранения. При помощи rmap в XFS для realtime-режима реализована поддержка операции reflink, позволяющей создавать копии файлов путём клонирования метаданных файла и создания ссылки на уже имеющиеся данные без их фактического копирования.
  • В VFS реализовано кэширование размера символических ссылок, позволившее на 1.5% ускорить выполнение операции readlink (в тесте с /initrd.img в ext4). Кэширование включено в ФС ext4 и tmpfs.
  • В реализацию NFSv4.2 добавлена поддержка делегирования атрибутов файлов, позволяющая управлять такими атрибутами файлов, как время изменения (mtime), на стороне NFS-клиента, без необходимости сброса изменений на сервер. В NFS также улучшена поддержка протокола "LOCALIO", позволяющего определить находятся ли клиент и сервер NFS на одном и том же хосте, для задействования соответствующих оптимизаций, таких как использование клиентом прямого ввода/вывода (Direct I/O).
  • Повышена производительность операций чтения в файловых системах NETFS, CIFS и AFS (Andrew File System).
  • В Squashfs включён режим прямой загрузки блоков в страничный кэш (SQUASHFS_FILE_DIRECT), позволяющий обойтись без отдельного кэша read_page. Изменение позволило сократить размер памяти, потребляемой при работе Squashfs.
  • В системном вызове statx() реализован флаг STATX_DIO_READ_ALIGN, для определения требуемого выравнивания для операций чтения из файла.
  • В файловой системе Bcachefs обновлён и стабилизирован формат дисковых структур. Любые дальнейшие изменения формата будут отнесены к категории необязательных и будут реализовываться в форме опциональных дополнений. Значительно повышена скорость проверки целостности ФС. Кроме того, в Bcachefs улучшена работа в режиме только для чтения; устранены проблемы, приводящие к обращению к памяти после её освобождения (use after free); решены проблемы c reflink-указателями в fsck; исправлена обработка перезапуска транзакции.
  • Возвращён модуль md-linear, предназначенный для объединения блочных устройств. Данный модуль ранее был объявлен устаревшим и удалён из ядра 6.8, но как оказалось он был востребован и поэтому теперь восстановлен.
  • Файловые системы F2FS и SQUASHFS переведены на использование фолиантов страниц памяти (page folios).
  • Файловые системы OCFS2 и DLMFS переведены на использование нового API монтирования разделов.
  • В драйвере null_blk реализован атрибут "rotational", выставляемый через configfs и позволяющий симулировать работу с устройством на базе вращающихся дисков для упрощения тестирования функций ядра.
  • В системе Device mapper и в модулях dm-mirror, dm-io, dm-table, dm-linear, dm-stripe и dm-raid1 реализована поддержка атомарной записи.
• Память и системные сервисы
  • Завершена интеграция в ядро драйвера ntsync, реализующего символьное устройство /dev/ntsync и набор примитивов для синхронизации, применяемых в ядре Windows NT. Реализация подобных примитивов на уровне ядра позволяет существенно поднять производительность Windows-игр, запускаемых при помощи Wine. Прирост производительности достигается благодаря избавлению от накладных расходов, связанных с применением RPC в пространстве пользователя. Создание отдельного драйвера для ядра Linux объясняется проблематичностью корректной реализации API синхронизации NT поверх существующих примитивов в ядре.
  • Добавлен новый контроллер cgroup DMEM для раздельного учёта областей памяти устройств, таких как GPU. DMEM позволяет создавать отдельные cgroup для различных задач, работающих с GPU, чтобы они могли выполняться не влияя друг на друга. Новая возможность решает проблему с принудительным завершением операций с GPU при исчерпании доступной памяти, благодаря учёту отражённой памяти GPU и используемой драйверами памяти CPU в отдельных cgroup.
  • Внесены оптимизации по масштабированию операции сброса (flush) кэша TLB (Translation Lookaside Buffer), применяемого для ускорения преобразования виртуальных адресов в физические. Добавленные оптимизации сводятся к отложенному обновлению некоторых структур данных во время переключения контекста, что позволяет повысить производительность при прохождении некоторых тестов.
  • Повышена производительность механизма MGLRU (Multi-Generational LRU), применяемый для определения какие страницы памяти используются, а какие можно вытеснить в раздел подкачки.
  • Продолжен перенос изменений из ветки Rust-for-Linux, связанных с использованием языка Rust в качестве второго языка для разработки драйверов и модулей ядра (поддержка Rust не активна по умолчанию, и не приводит ко включению Rust в число обязательных сборочных зависимостей к ядру). Предоставлена возможность использования в коде ядра макроса "derive(CoercePointee)", позволяющего использовать умные указатели с trait-объектами. В состав ядра включены Rust-обвязки для PCI, платформ, Open Firmware, символьных устройств и некоторых функций ввода/вывода. Грег Кроа-Хартман (Greg Kroah-Hartman), отвечающий за поддержку стабильной ветки ядра Linux, охарактеризовал текущее состояние, как "почти готовность к написанию реального драйвера на Rust".
  • В сборочных сценариях предложен новый код для генерации версий отладочных символов для загружаемых модулей, который теперь использует информацию из отладочных записей в формате DWARF, а не разбирает исходный код напрямую. Изменение позволяет применять версионирование отладочных символов для модулей, написанных на языке Rust. Старая реализация тоже оставлена в ядре, а выбор генератора производится на уровне сборочных опций.
  • Для архитектуры PowerPC реализована поддержка режима ленивого вытеснения задач (PREEMPT_LAZY, lazy preemption), который соответствует режиму полного вытеснения ("full preemption") для realtime-задач (RR/FIFO/DEADLINE), но задерживает вытеснение обычных задач (SCHED_NORMAL) до границы тика.
  • В подсистему профилирования производительности "perf" добавлена поддержка счётчиков энергопотребления процессоров AMD. Добавлена возможность работы на системах, насчитывающих до 2048 ядер CPU.
  • Предоставлена возможность использования sysctl-параметра pid_max с пространствами имён идентификаторов процессов (ID namespace). Параметр pid_max предназначен для ограничения максимального значения идентификаторов процессов (PID) и теперь может использоваться для ограничения максимально возможного числа процессов, запущенных в указанном пространстве имён. Обработка параметра производится иерархически, т.е. ограничения во внешних пространствах имён распространяются на вложенные пространства имён.
  • При использовании для запуска процесса системного вызова execveat в файловой системе /proc теперь будет отображаться имя запущенного файла, а не номер файлового дескриптора.
  • В состав исходного кода ядра (в каталог samples/vfs) добавлена утилита mountinfo, демонстрирующая использование системных вызовов statmount() и listmount().
  • В подсистеме BPF предложены новые функции bpf_local_irq_save() и bpf_local_irq_restore() для временного отключения прерываний на локальном CPU. Функции могут применяться для реализации структур, обработка которых не приостанавливается прерываниями.
  • В системном вызове madvise() при использовании флагов MADV_DONTNEED и MADV_FREE обеспечено освобождение таблиц страниц памяти, связанных с освобождаемым диапазоном адресов, так как в некоторых ситуациях пустые страницы памяти могут занимать достаточно много памяти.
  • Для архитектуры OpenRISC реализована поддержка механизма перезапускаемых последовательностей (rseq, restartable sequences), предназначенного для быстрого атомарного выполнения операций, которые в случае прерывания другим потоком очищаются и предпринимается повторная попытка выполнения.
  • Проведена реорганизация кода с реализацией алгоритмов CRC32 и CRC-T10DIF, который больше не пересекается с подсистемой crypto и вызывается напрямую из библиотечного интерфейса. Изменение позволило упростить код и повысить его эффективность.
  • В систему асинхронного ввода/вывода io_uring добавлен интерфейс для передачи дополнительных метаданных о целостности при выполнении операций чтения и записи.
• Виртуализация и безопасность
  • В системный вызов execveat добавлен флаг AT_EXECVE_CHECK, позволяющий выполнить проверку допустимости исполнения файла без его фактического запуска, но c учётом политик безопасности, прав доступа и активных LSM-модулей. Для использования в сочетании с AT_EXECVE_CHECK предложены securebit-флаги SECBIT_EXEC_RESTRICT_FILE и SECBIT_EXEC_DENY_INTERACTIVE, которые можно использовать для ограничения исполнения файлов со скриптами на интерпретируемых языках программирования. Флаг SECBIT_EXEC_RESTRICT_FILE предписывает компоновщикам и интерпретаторам использовать опцию AT_EXECVE_CHECK для проверки допустимости исполнения, а флаг SECBIT_EXEC_DENY_INTERACTIVE запрещает обрабатывать интерактивные команды. Основная идея изменения в возможности применения политик безопасности не только к традиционным исполняемым файлам, но и к текстовым файлам со скриптами, которые можно загрузить через запуск интерпретатора (т.е. запрет на исполнение может быть реализован не только при запуске "./script.sh" но и при выполнении в форме "sh script.sh").
  • На системах x86 реализована поддержка защищённых счётчиков времени для гостевых систем, не позволяющих изменять системные часы гостевой системы из хост окружения. Возможность реализована на базе механизма AMD SEV (Secure Encrypted Virtualization), применяемого в системах виртуализации для защиты виртуальных машин от вмешательства со стороны гипервизора или администратора хост-системы.
  • В систему мандатного контроля доступа SELinux добавлена поддержка xperm-правил, позволяющих привязывать политики SELinux к определённым вызовам ioctl() или сообщениям netlink.
  • Для заверения модулей ядра цифровой подписью вместо SHA1 по умолчанию задействован алгоритм SHA512.
  • В драйверах для гостевых систем VirtualBox включена поддержка архитектуры ARM64.
  • В гипервизоре KVM продолжена работа над задействованием механизма Intel TDX (Trusted Domain Extensions) для шифрования памяти гостевых систем.
  • В virtio_blk добавлена поддержка режима восстановления ошибок.
• Сетевая подсистема
  • В реализации протокола RxRPC появилась возможность использования больших кадров UDP для повышения пропускной способности.
  • Для TCP добавлена поддержка алгоритма RACK-TLP для определения потери пакетов.
  • Добавлен новый параметр sysctl tcp_tw_reuse_delay, действующий в привязке к пространству имён (network namespace) и позволяющий определить задержку, вносимую перед тем как система сможет повторно использовать номер сетевого порта после закрытия TCP-сокета.
  • Добавлена возможность выбора провайдера точного времени (PTP) для формирования временных меток на уровнях PHY и MAC.
  • Для IPsec реализована поддержка механизма агрегирования и фрагментирования инкапсулированных IP-пакетов - IP-TFS/AGGFRAG (IP Traffic Flow Security/Aggregation and Fragmentation Mode for Encapsulating Security Payload).
  • В систему сетевых сокетов добавлена поддержка передачи информации о приоритете (SO_PRIORITY) в форме управляющих сообщений (cmsg - control messages). Для сетевых сокетов добавлена опция SO_RCVPRIORITY, включающая в функции recvmsg() передачу информацию о приоритете сокета.
• Оборудование
  • Добавлен драйвер amdxdna для интегрированных в CPU AMD ускорителей NPU (Neural Processing Unit) на базе архитектуры XDNA, предназначенных для ускорения операций, связанных с машинным обучением. NPU на базе архитектуры XDNA поставляется в сериях 7040 и 8040 процессоров AMD Ryzen, ускорителях AMD Alveo V70 и SoC AMD Versal.
  • В драйвер i915 добавлены идентификаторы новых GPU, реализован обработчик сбоев инициализации HDMI, повышена надёжность сброса движков GPU на Haswell и более старых системах.
  • Продолжена работа над drm-драйвером (Direct Rendering Manager) Xe для GPU на базе архитектуры Intel Xe, которая используется в видеокартах Intel семейства Arc и интегрированной графике, начиная с процессоров Tiger Lake.
  • В драйвере Nouveau добавлена возможность передачи буферов с логами GSP-RM через debugfs.
  • В драйвере AMDGPU реализована поддержка механизма DRM panic, отображающего подобие "синего экрана смерти" при сбоях. Продолжена подготовка к поддержке будущей серии графических карт Radeon RX 9000 на базе архитектуры RDNA4. Обновлена поддержка DCN 3.5, GG 9.5, IH 4.4, PSP 13.x, SMU 13.x, VCN 5.x, JPEG 5.x, GC 12.x, DC FAMS, RAS и ISP.
  • В DRM-драйвер msm (GPU Qualcomm Adreno) добавлена поддержка платформы Qualcomm SM6150 (QCS615).
  • В DRM-драйвер panfrost добавлена поддержка SoC MediaTek MT8188 c GPU Mali-G57.
  • В DRM-драйвер vc4 добавлена поддержка SoC Broadcom BCM2712 (Raspberry Pi 5).
  • В vfio-драйвер nvgrace-gpu добавлена поддержка чипов NVIDIA Grace Blackwell 200.
  • В состав включён драйвер для контроллеров Intel THC (Touch Host Controller), применяемый для взаимодействия с сенсорными экранами и тачпадами на некоторых ноутбуках. Добавлена поддержка устройств Wacom с интерфейсом PCI. Добавлена поддержка игровых контроллеров QH Electronics.
  • Добавлена поддержка ARM-плат, SoC и устройств: Qualcomm Snapdragon 8 Elite (SM8750), Qualcomm Snapdragon AR2 (SAR2130P), Qualcomm IQ6/IQ8, Snapdragon 425 (MSM8917), Samsung Exynos 9810, Blaize BLZP1600, Microchip SAMA7D65, Renesas R-Car V4H ES3.0, Renesas RZ/G3E. Добавлена поддержка SoC SpacemiT K1 на базе архитектуры RISC-V.
  • В звуковой подсистеме ALSA для MIDI 2.0 расширены API rawmidi и sequencer. В API для выноса операций сжатия на сторону звуковой карты добавлена поддержка ASRC (Asynchronous Sample Rate Conversion).
  • Добавлена поддержка звуковых систем устройств Allwinner suinv F1C100s, Awinc AW88083, Realtek ALC5682I-VE, TAS2781, Focusrite Scarlett 4th Gen 16i16, 18i16 и 18i20. Добавлена поддержка беспроводных наушников SteelSeries Arctis 9.

1. OpenNews: Релиз ядра Linux 6.13
2. OpenNews: Релиз ядра Linux 6.12 с поддержкой Realtime-режима
3. OpenNews: Релиз ядра Linux 6.11
4. OpenNews: Релиз ядра Linux 6.10
5. OpenNews: Релиз ядра Linux 6.9