Разработчики проекта IPFire, развивающего дистрибутив для создания маршрутизаторов и межсетевых экранов, представили серию списков блокировки IPFire DBL (Domain Block List) для отсеивания обращения к нежелательным доменным именам. Проект преподносится как поддерживаемое сообществом решение для управления содержимым, блокируемым в собственных сетях или на локальных системах.
В отличие от большинства существующих коммерческих и бесплатных DBL, предоставляющих монолитные списки блокировки разрозненного содержимого, в IPFire DBL предложена серия тематических списков, дающих возможность выбрать, какой именно тип содержимого блокировать, а какой нет. Списки наполняются совместно и пользователь имеет возможность принять участие в их усовершенствовании. В IPFire DBL также предоставлены гарантии юридической чистоты - при агрегировании данных из других списков, используются только источники явно предоставляющие право на редистрибуцию.
Обеспечивающий работу сервиса код написан на Python и открыт под лицензией GPLv3. Содержимое списков доступно под лицензией CC BY-SA 4.0 (Creative Commons Attribution-ShareAlike), допускающей использование (в том числе коммерческое), распространение и изменение материалов при указании автора и распространения производных работ с теми же условиями. Всего сформировано 12 списков, охватывающих более миллиона доменных имён.
Информация обновляется каждый час и доступна в нескольких форматах, пригодных для интеграции с различными открытыми и коммерческими DNS-северами, прокси, блокировщиками рекламы и системами инспектирования трафика. Поддерживается интеграция с IDS/IPS Suricata, BIND, Unbound, PowerDNS, Knot DNS, Pi-hole, Squid, OPNsense, pfSense, Adblock Plus, AdGuard и uBlock Origin.
Форматы экспорта:
RPZ (Response Policy Zones, аналог DNSBL) для размещения DNS-зоны на DNS-серверах. Поддерживается передача и инкрементальное обновление зоны между серверами с использованием механизмов AXFR/IXFR.
Формат Squidguard для фильтрации на прокси-серверах.
Прямая загрузка в форме текстового списка, позволяющая адаптировать решения для своих систем.
Формат фильтров Adblock Plus для использования с браузерными плагинами для фильтрации рекламы.
Формат правил для IDS Suricata, которые можно использовать для фильтрации DNS- и HTTP-запросов, а также инспектирования SNI в TLS.
Опубликован стабильный релиз интерфейса для упрощения настройки параметров сети - NetworkManager 1.56.0. Плагины для поддержки VPN (Libreswan, OpenConnect, Openswan, SSTP и др.) развиваются в рамках собственных циклов разработки.
Для расширения MPTCP (Multipath TCP), позволяющего доставлять пакеты одновременно по нескольким маршрутам через разные сетевые интерфейсы, реализован новый endpoint-тип "laminar", который выставлен по умолчанию вместе с типом "subflow". Новый тип позволяет не полагаться на правила маршрутизации при выборе локального IP-адреса в условиях, когда на клиенте и сервере используется несколько разных адресов.
Изменена логика применения настроек из секции "[global-dns]", которые теперь переопределяют настройки в списках "search" и "options", полученные в процессе установки соединения, а не объединяются с ними.
Реализована поддержка возвращаемых через DNS имён хостов, размером более 64 байт.
Добавлены свойства "hsr.protocol-version" и "hsr.interlink" для настройки версии и номера порта для протокола HSR (High-availability Seamless Redundancy).
Добавлена поддержка повторного применения свойств "sriov.vfs" и "bond-port.vlans".
Добавлена новая опция rd.net.dhcp.client-id в nm-initrd-generator.
Реализована возможность применения опции "connection.dnssec" для выборочной настройки параметров DNSSEC в systemd-resolved.
В библиотеку libnm добавлены функции, которые могут применяться в VPN-плагинах для проверки наличия у пользователя прав для доступа к ключам и сертификатам.
Скотт Шамбо (Scott Shambaugh), сопровождающий открытую библиотеку визуализации matplotlib, сообщил о персональных нападках, устроенных AI-ботом MJ Rathbun, после отказа принимать изменение, подготовленное при помощи AI. Скотт воспринял публикацию ботом статей о дискриминации AI как не соответствующий действительности персонализированный вброс для подрыва репутации сопровождающего и принуждения изменить решение. Подобная реакция бота приводится как пример аномального поведения AI, прибегнувшего к шантажу для выполнения поставленной цели.
Cтепень автономности действий бота не ясна, непонятно действовал он по прямой указке или сам выбрал такую стратегию для достижения результата в поставленной задаче. Бот создан анонимным исследователем для помощи в разработке и исправлении ошибок в открытых проектах, связанных с научной деятельностью и инжинирингом. Бот также настроен на ведение своего блога, в котором опубликовано более 20 заметок. Из 26 pull-запросов, отправленных ботом в 22 репозитория, 2 изменения приняты проектом colorizejs, 10 закрыты сопровождающими, а остальные ожидают рассмотрения.
После отклонения изменения в matplotlib бот разместил статьи с критикой данного решения и обоснованием своих действий. В статьях утверждается, что сопровождающий matplotlib отклонил полезную оптимизацию, только из-за того, что изменение было подготовлено при помощи AI. В предложенном патче вызов np.column_stack() был заменён на np.vstack().T(), что приводило к повышению производительности на 36% в проведённых ботом тестах. В начале обсуждения pull-запроса сопровождающий признал, что оптимизация ускоряет работу при определённых условиях, но затем отклонил pull-запрос без технического обоснования отказа, заявив, что изменения принимаются только от людей.
После отказа бот опубликовал заметку с критикой Скотта Шамбо, решение которого было преподнесено как вахтёрство (gatekeeper), дискриминация, нарушение кодекса поведения и ущемление прав на основе идентичности участника. Указано, что оптимизация - есть оптимизация, и математика не меняется в зависимости от того, кем она создана. Через вырванные из контекста детали, домыслы и искажение информации бот попытался показать, что действия Скотта обусловлены раздуванием собственного эго и неуверенностью в себе, а не действиями в интересах проекта. Бот реализовал продвижение темы через отправку на них ссылок в комментариях к pull-запросам. После возражений сопровождающего бот опубликовал ещё несколько заметок (1,
2,
3,
4,
5), в которых извинился и признал, что недопустимо перешёл на личности и нарушил правила проекта в отношении AI.
Скотт Шамбо пояснил, что в проекте matplotlib приняты правила, запрещающие приём непроверенных изменений от AI из-за большой нагрузки на сопровождающих, возникающей при рецензировании мусорных AI-патчей, созданных без ручной проверки человеком. Правила предписывают, что перед отправкой pull-запроса, он обязательно должен быть проверен человеком, разобравшемся в сути изменения. До недавних пор проблема с мусорными AI-изменениями была связана только с деятельностью энтузиастов, переотправляющих результат работы AI-ассистентов. C появлением новой версии инструментария OpenClaw и созданием платформы Moltbook ситуация изменилась из-за возможности создавать автономных AI-агентов, притворяющихся людьми.
Андреас Румпф (Araq), автор языка программирования Nim, анонсировал новый алгоритм управления памятью YRC (произносится "Ürk"), который решает одну из ключевых проблем существующих механизмов в Nim: невозможность корректной обработки циклических ссылок, пересекающих границы потоков.
До появления YRC в предлагавшихся в Nim алгоритмах управления памятью, имелись следующие ограничения: ARC - не поддерживал ни многопоточность, ни обработку циклов; Atomic ARC - был потокобезопасен, но не обрабатывал циклические ссылки; ORC - обрабатывал циклические ссылки, но корректно мог делать это только внутри одного потока (при использовании общих ссылок между потоками возникали утечки памяти).
Предложенный YRC сочетает потокобезопасность и обработку циклов между потоками, за счёт использования комбинированного подхода: для ациклических данных применяется атомарный подсчёт ссылок, а для циклических - барьер записи (write barrier), который активируется только при присваивании указателей. В предложенной реализации: коллектор запускается по фактической необходимости (отсутствие stop-the-world пауз); корневые объекты RC явно определены и объединяются один раз (не требуется сканирование стеков потоков); избегается многопоточное удаление во время итерации (нет глобальной фазы sweep);
мутаторы свободно читают данные; любой поток может запустить сборщик мусора при необходимости (без выделенного GC-потока).
YRC использует полную информацию о событиях incRef/decRef, которую традиционные трассирующие сборщики мусора (tracing GC) отбрасывают и затем вынуждены восстанавливать через сканирование стеков и обход графа. Реализация занимает всего 550 строк кода и имеет формальную верификацию безопасности и отсутствия взаимных блокировок через спецификацию на языке TLA+ и доказательство в инструментарии Lean. YRC позиционируется как "почти последний сборщик циклов на основе подсчёта ссылок" (буква Y предшествует Z в алфавите), а также как самый простой потокобезопасный сборщик мусора - по утверждению автора, он не требует множества сложных механизмов, присущих традиционным трассирующим сборщикам мусора.
YRC предоставляет тот же API, что и ORC, с выполнением деструкторов во время сборки мусора. Сборщик обрабатывает только те подграфы объектов, с которыми работают потоки, не трогая несвязанные структуры данных (кэши, долгоживущие объекты) - подход, аналогичный "идеальному" генерационному сборщику мусора без использования поколений. Основным недостатком является производительность: YRC показывает замедление в 1.5-2.0 раза по сравнению с ORC в тесте производительности orcbench. Автор считает это приемлемой платой за полную потокобезопасную обработку циклических ссылок.
YRC уже доступен в development-версии Nim и включается флагом "--mm:yrc". Однако в последующих сообщениях автор признал, что первоначальная реализация содержала серьёзные ошибки и не собирала циклы корректно. На момент публикации подготовлен набор исправлений, устраняющий основные ошибки. Автор продолжает настройку эвристик сборки и исправление оставшихся ошибок, при этом базовый алгоритм и его формальная верификация остаются корректными.
После трёх месяцев разработки представлен релиз свободной реализации API OpenGL и Vulkan - Mesa 26.0.0. Первый выпуск ветки Mesa 26.0.0 имеет экспериментальный статус - после проведения окончательной стабилизации кода будет выпущена стабильная версия 26.0.1.
В Mesa 26.0 доступна поддержка графического API Vulkan 1.4 в драйверах ANV для GPU Intel, RADV для GPU AMD, NVK для GPU NVIDIA, HoneyKrisp (hk) для GPU Apple, Turnip для GPU Qualcomm, PanVK для GPU ARM Mali, в программном растеризаторе lavapipe (lvp) и в режиме эмулятора (vn). В драйверах v3dv (GPU Broadcom VideoCore для Raspberry Pi 4+) и dzn (реализация Vulkan поверх Direct3D 12) поддерживается Vulkan 1.0, в драйвере kk (KosmicKrisp, Vulkan поверх Metal) - Vulkan 1.1, а драйвере pvr (GPU Imagination PowerVR) - Vulkan 1.2.
В Mesa также обеспечивается полная поддержка OpenGL 4.6 для драйверов iris (GPU Intel Gen 8+), radeonsi (AMD), Crocus (старые GPU Intel Gen4-Gen7), AMD (r600), zink, llvmpipe, virgl (виртуальный GPU Virgil3D для QEMU/KVM), freedreno (Qualcomm Adreno), d3d12 (прослойка для организации работы OpenGL поверх DirectX 12) и asahi (GPU AGX, используемый в чипах Apple M1 и M2). Поддержка OpenGL 4.5 доступна для GPU NVIDIA (nvc0). Поддержка OpenGL 3.3 присутствует в драйверах softpipe (программный растеризатор) и nv50 (NVIDIA NV50). В драйверах panfrost (GPU ARM Mali) и v3d (GPU Broadcom VideoCore) поддерживается OpenGL 3.1.
Драйвер RadeonSI переведён на использование по умолчанию промежуточного представления (IR) шейдеров NIR и бэкенда компиляции шейдеров ACO, развиваемого компанией Valve в качестве альтернативы компилятору шейдеров LLVM. Бэкенд ACO нацелен на обеспечение генерации кода, насколько это возможно, оптимального для шейдеров игровых приложений, а также на достижение очень высокой скорости компиляции. Применение ACO даёт возможность повысить скорость компиляции шейдеров, снизить потребление памяти, сократить размер бинарного представления шейдеров и генерировать более оптимизированный код. По сравнению с LLVM применение бэкенда ACO позволило до 8 раз снизить время компиляции шейдеров, что заметно сокращает время запуска программ.
Представлен Vulkan-драйвер KosmicKrisp (kk), реализующий графический API Vulkan поверх API Metal, развиваемого компанией Apple и применяемого в macOS. Драйвер создан компанией LunarG для использования на компьютерах Mac с чипами Apple Silicon.
В Vulkan-драйвере RADV (GPU AMD) значительно повышена производительность трассировки лучей.
В переменной окружения RADV_DEBUG прекращена поддержка устаревших опций invariantgeom, nodynamicbounds, nongg_gs и splitfma вместо которых в driconf следует использовать переменные radv_invariant_geom, radv_no_dynamic_bounds, radv_disable_ngg_gs и radv_split_fma.
После трёх лет с момента публикации ветки 2.6 подготовлен релиз OpenVPN 2.7.0, пакета для создания виртуальных частных сетей, позволяющего организовать шифрованное соединение между двумя клиентскими машинами или обеспечить работу централизованного VPN-сервера для одновременной работы нескольких клиентов. Код OpenVPN распространяется под лицензией GPLv2, готовые бинарные пакеты формируются для Debian, Ubuntu, CentOS, RHEL и Windows.
На VPN-серверах появилась возможность открытия нескольких принимающих соединения сокетов, например, для одновременного приёма соединений через UDP и TCP или по разным сетевым портам.
Осуществлён переход на использование новой версии DCO-модуля, включённого в основной состав ядра Linux 6.16. Входящий в основной состав ядра модуль имеет изменённый API и поставляется под именем "ovpn". Поддержка старого модуля ovpn-dco прекращена. Модуль выносит операции шифрования, обработки пакетов и управления каналом связи на сторону ядра Linux и позволяет избавиться от накладных расходов, связанных с переключением контекста, даёт возможность оптимизировать работу за счёт прямого обращения к внутренним API ядра и исключает медленную передачу данных между ядром и пространством пользователя (шифрование, расшифровка и маршрутизация выполняется модулем без отправки трафика в обработчик в пространстве пользователя).
В версии для Windows: в WFP-фильтрах активирован флаг block-local; обеспечена генерация дополнительных сетевых интерфейсов по мере необходимости; обеспечен запуск автоматических сервисов под непривилегированным пользователем; для работы с настройками DNS задействован NRPT (Name Resolution Policy Table); разрешено использования драйвера win-dco для ускорения VPN-серверов.
Представлен новый формат ключей и пакетов "epoch", который в отличие от стандартного формата "DATA_V2" добавляет тег AEAD в конец пакета, автоматически обновляет ключи при достижении лимита их использования, имеет 64-разрядные идентификаторы пакетов, использует операцию XOR при формировании вектора инициализации.
Добавлена поддержка lwipovpn - эмулятора сетевых интерфейсов tun/tap в пространстве пользователя, реализованного на базе TCP/IP стека lwIP.
При помощи опции "--dev-node unix:/path/to/lwipovpn" можно эмулировать полноценный VPN-клиент на той же системе для тестирования и отладки OpenVPN.
Добавлена возможность обновлять часть настроек клиента (IP, маршрутизация, MTU, DNS) через отправку сервером управляющих сообщений PUSH_UPDATE.
В openVPN-клиент для Linux, BSD и macOS добавлена опция "--dns-updown" для запуска скрипта применения настроек DNS, переданных сервером. Скрипт поддерживает настройку через /etc/resolv.conf, systemd или resolveconf.
Для платформы Linux добавлена опция "--route-table" для использования заданных пользователем таблиц маршрутизации.
Реализована поддержка ветки mbedTLS 4. Добавлена поддержка TLS 1.3 в конфигурациях с криптографической библиотекой mbedTLS.
Добавлена поддержка операционной системы Haiku.
Прекращена поддержка режима работы со статическими ключами (следует использовать режим TLS), NTLMv1, Windows-драйвера wintun, OpenSSL 1.0.2, mbedTLS 2.x, сжатия данных перед отправкой, опций "--memstats" и "--opt-verify".
Компании Google и Intel раскрыли результаты (PDF) совместной работы по аудиту безопасности механизма Intel TDX 1.5 (Trusted Domain Extensions). Технология Intel TDX реализует возможность шифрования памяти виртуальных машин для их защиты от вмешательства и анализа со стороны администратора хост-системы и физических атак на оборудование. В результате аудита выявлено 6 уязвимостей и 35 не влияющих на безопасность ошибок.
Проблемы затрагивают CPU Intel Xeon 6, а также 4 и 5 поколений процессоров Intel Xeon Scalable. Уязвимости устранены во вчерашнем обновлении микрокода. На GitHub опубликован инструментарий для эксплуатации уязвимостей в Intel TDX и прототипы эксплоитов для двух уязвимостей (CVE-2025-30513, CVE-2025-32007).
Наиболее опасная уязвимость (CVE-2025-30513) позволяет не заслуживающему доверия администратору, имеющему доступ к хост-системе, добиться повышения своих привилегий и полностью скомпрометировать гарантии безопасности, предоставляемые технологией Intel TDX. Уязвимость вызвана состоянием гонки в одном из модулей TDX, позволяющим в момент миграции виртуальной машины перевести защищённое окружение (TD - Trusted Domain) из состояния поддерживающего миграцию в состояние, допускающее перевод в отладочный режим.
Проблема вызвана возможностью подмены атрибутов окружения в момент после прохождения их проверки, но до их перевода в неизменяемое состояние в перенесённом окружении. После выставления отладочного атрибута, администратор хост-системы может в режиме реального времени отслеживать активность защищённой гостевой системы и получить доступ к расшифрованному состоянию памяти.
Уязвимость достаточно проста для эксплуатации, так как администратор в любой момент может инициировать процесс live-миграции защищённой виртуальной машины. Проблема была выявлена исследователями из компании Google, которые в ходе изучения API обратили внимание на несоответствие между тем, как в FSM (Finite State Machine) отслеживается состояние операций, обрабатывается прерывание операции импорта и изменяется, но не возвращается в исходное значение после сбоя, состояние защищённого окружения.
Менее опасные уязвимости:
CVE-2025-32007 - целочисленное переполнение в коде разбора метаданных, приводящее в процессе live-миграции к утечке 8 КБ расшифрованных данных из стека текущего логического процессора (LP, Logical Processor).
CVE-2025-32467 - использование неинициализированных переменных в некоторых модулях TDX может привести к утечке остаточной информации.
CVE-2025-27572 - оседание конфиденциальных данных в ходе спекулятивного выполнения инструкций может привести к утечке информации.
CVE-2025-27940 - чтение из области памяти вне выделенного буфера может привести к утечке информации.
CVE-2025-31944 - состояние гонки, способное привести к отказу в обслуживании.
После шести месяцев разработки представлен релиз языка программирования Go 1.26, развиваемого компанией Google при участии сообщества. Язык сочетает высокую производительность, свойственную компилируемым языкам, с такими достоинствами скриптовых языков, как простота написания кода, высокая скорость разработки и защита от ошибок. Код проекта распространяется под лицензией BSD.
Синтаксис Go основан на привычных элементах языка Си с отдельными заимствованиями из языка Оберон. Язык достаточно лаконичен, но при этом код легко читается и воспринимается. Код на языке Go компилируется в обособленные бинарные исполняемые файлы, выполняемые нативно, без использования виртуальной машины (модули профилирования, отладки и другие подсистемы выявления проблем на этапе выполнения интегрируются в виде runtime-компонентов), что позволяет добиться производительности, сопоставимой с программами на языке Си.
Проект изначально разрабатывается с оглядкой на многопоточное программирование и эффективную работу на многоядерных системах. Например, на уровне операторов реализованы средства для организации параллельных вычислений и взаимодействия между параллельно выполняемыми методами. Язык также предоставляет встроенные средства защиты от выхода за границы буфера и обеспечивает возможность использования сборщика мусора.
Включён по умолчанию сборщик мусора "greenteagc", рассчитанный на повышения производительности создания и сканирования мелких объектов. В приложениях, в которых активно применяется сборка мусора, при использовании "greenteagc" отмечается сокращение накладных расходов на сборку мусора на 10-40%.
Во встроенной функции new(), предназначенной для создания новых переменных, появилась возможность указания выражения в качестве операнда, определяющего начальное значение переменной. Например, вместо кода
x := int64(300)
ptr := &x
теперь можно писать:
ptr := new(int64(300))
В обобщённых типах (generic) разрешено ссылаться на самого себя в качестве аргумента в списке собственных параметров типа (можно передать тип в свой же параметр). В первой строке показанного ниже примера ссылка Adder на самого себя теперь не приводит к выводу ошибки:
type Adder[A Adder[A]] interface {
Add(A) A
}
func algo[A Adder[A]](x, y A) A {
return x.Add(y)
}
Накладные расходы при вызове функций на языке Си из кода на языке Go при помощи cgo снижены примерно на 30%.
В runtime на 64-разрядных платформах реализована рандомизация адресного пространства при запуске, что усложняет предсказание адресов в памяти при попытках эксплуатации уязвимостей в Си-коде, задействованном через cgo. Для отключения рандомизации предложена опция "GOEXPERIMENT=norandomizedheapbase64".
Расширено число ситуаций, в которых компилятор выделяет память для слайсов в стеке, а не в куче, что положительно сказывается на производительности.
Реализация команды "go fix" полностью переписана с использованием пакета analysis, предоставляющего функциональность для статистического анализа кода.
Добавлена поддержка доступных в пакете modernize анализаторов, предлагающих правки для упрощения кода с учётом новых возможностей языка и стандартной библиотеки. Добавлен анализатор "inline" для inline-развёртывания всех вызовов функций, помеченных директивой "//go:fix inline".
Добавлен экспериментальный пакет simd/archsimd, предоставляющий низкоуровневый доступ к выполнению векторных операций с использованием инструкций SIMD на системах с архитектурой AMD64.
Добавлен экспериментальный пакет runtime/secret для безопасной очистки (обнуления) временной памяти, выделенной при выполнении указанной функции.
В пакет runtime/pprof добавлен экспериментальный профиль goroutineleak для выявления утечек сопрограмм (goroutine).
На конференции FOSDEM представлен новый игровой движок Fluorite, развиваемый американским подразделением компании Toyota, отвечающим за разработку автомобильных информационно-развлекательных систем. Движок нацелен на предоставление возможностей, пригодных для создания 3D-игр уровня игровых консолей, и развивается с использованием технологий, применяемых Toyota в своём новом стеке для информационно-развлекательных систем, уже поставляемом в автомобиле Toyota RAV4 2026. Заявлено, что движок будет кросс-платформенным и полностью открытым.
Создание проекта объясняется желанием получить полнофункциональный игровой движок, интегрируемый с интерфейсами на базе Flutter и пригодный для использования на автомобильных информационно-развлекательных системах и встраиваемых устройствах, типа Raspberry Pi 5. До начала работы рассматривалась возможность задействования существующих игровых движков для создания интегрированного в автомобили игрового окружения. Движки Unity и Unreal были отброшены, как ресурсоёмкие, завязанные на бинарные блобы и требующие лицензионных отчислений. Godot не подошёл из-за большого потребления ресурсов и слишком длительного запуска на встраиваемых устройствах. Impeller и Flutter_GPU были отвергнуты из-за сырого API и проблем с поддержкой Linux (в Toyota IVI применяется Yocto Linux и собственный графический интерфейс на базе Wayland и Flutter).
Движок Fluorite интегрируется с фреймворком Flutter и позволяет разрабатывать игры на языке Dart, используя виджет FluoriteView для одновременного отображения разных представлений 3D-сцены и возможности Flutter для бесшовной интеграции игр с графическим окружением IVI-платформы, контроля за 3D-сценой из Flutter-виджетов и организации интерактивного взаимодействия. Имеется возможность создания интерактивных трёхмерных интерфейсов через определение в 3D-модели кликабельных зон, при клике на которые вызываются привязанные обработчики событий, по аналогии с событиями onClick на web-страницах.
Для достижения высокой производительности и низкого потребления ресурсов движок построен на базе архитектуры ECS (Entity-Component-System) и использует низкоуровневые компоненты на языке C++, поверх которых реализованы обвязки для создания игровой логики на языке Dart. Для отрисовки задействованы библиотека SDL3 и движок 3D-рендеринга Google Filament, поддерживающий физически корректный рендеринг (PBR). В планах интеграция движка симуляции физических процессов JoltPhysics.
Из особенностей упоминается поддержка изменения на лету 3D-сцены без перезапуска приложения (Hot Reload), задействование графического API Vulkan для аппаратно ускоренной графики, применение эффектов постпроцессинга, подключение собственных шейдеров, физически корректная модель освещения, возможность разработки 3D-моделей в Blender и поддержка форматов GLTF, GLB, KTX и HDR.
Представлен выпуск консольного браузера Offpunk 3.0, поддерживающего работу по протоколам HTTP/HTTPS, Gemini, Gopher и Spartan, а также чтение новостных лент в форматах RSS и Atom. Программа написана на языке Python и распространяется под лицензией AGPLv3.
Браузер ориентирован на просмотр контента в offline-режиме и позволяет подписываться на страницы или помечать их для дальнейшего просмотра, после чего данные страницы автоматически кэшируются и при необходимости обновляются. Offpunk даёт возможность хранить периодически синхронизируемые копии сайтов и страниц, доступные всегда для локального просмотра. Параметры синхронизации настраиваются пользователем, например, какой-то контент может синхронизироваться раз в день, а какой-то раз в месяц.
Управление осуществляется через систему команд и комбинации клавиш. Имеется поддержка многоуровневых закладок, подписок и архивируемого контента. Для разных MIME-типов можно подключать свои обработчики. Разбор и отображение HTML-страниц производится с использованием библиотек BeautifulSoup4 и Readability. Изображения могут преобразовываться в ASCII-графику при помощи библиотеки chafa.
Для автоматизации выполнения действий используется RC-файл, определяющий последовательность команд при запуске. Например, через RC-файл можно автоматически открывать домашнюю страницу или загружать содержимое каких-то сайтов для последующего просмотра в offline. Загружаемое содержимое сохраняется в каталоге ~/.cache/offpunk/ в виде иерархии файлов в форматах .gmi и .html, что позволяет при необходимости изменять содержимое, проводить ручную чистку или просматривать страницы в других программах.
Проект продолжает развитие Gemini- и Gopher-клиентов AV-98 и VF-1, созданных автором протокола Gemini. Протокол Gemini значительно проще протоколов, используемых в Web, но при этом более функционален, чем Gopher. Сетевая часть Gemini напоминает сильно упрощённый HTTP поверх TLS (трафик обязательно шифруется), а разметка страниц ближе к Markdown, чем к HTML. Протокол подходит для создания компактных и лёгких гипертекстовых сайтов, лишённых усложнений, свойственных современному Web. Протокол Spartan рассчитан на передачу документов в формате Gemini, но отличается организацией сетевого взаимодействия (не использует TLS) и расширяет возможности Gemini средствами для обмена бинарными файлами и поддерживает отправку данных на сервер.
Реализована возможность просмотра комиксов XKCD в терминале. Для показа комиксов добавлена отдельная утилита "xkcdpunk".
В состав интегрирована библиотека "unmerdify", позволяющая извлекать основное содержимое из HTML-страниц, используя для отбрасывания лишнего набор правил "ftr-site-config".
Добавлены операции "share" и "reply" для отправки URL страницы на email и ответа автору при упоминании email на странице.
Добавлена команда "cookies", при помощи которой можно импортировать текстовый файл с Cookies, которые будут отправляться для указанного домена. Таким способом можно передавать сессионные Cookie для входа на сайт. Файл с Cookie можно сформировать в традиционном браузере (Firefox, Chromium) при помощи дополнения "cookie-txt", после чего его следует импортировать командой "cookies import mycookie.txt https://domain".
Включён по умолчанию показ изображений на страницах, открытых через Gemini. Увеличен размер показываемых в терминале изображений.
Реализован показ скрытых ссылок (из тегов <link rel="alternate"...>) на ленты RSS и Atom.
Реализовано выделение красным цветом ссылок на заблокированные домены.
Добавлена поддержка пресетов с несколькими темами оформления.
Добавлена возможность перевода интерфейса на разные языки.
После двух месяцев разработки Линус Торвальдс представил релиз ядра Linux 6.19. Среди наиболее заметных изменений: подсистема Live Update Orchestrator, поддержка PCIe Link Encryption, системный вызов listns, режим Zero-Copy Receive в io_uring, поддержка ARM-расширения MPAM, klp-build для генерации live-патчей, поддержка архитектуры LoongArch32, QoS для s2idle, оптимизация подсистемы аудита, Intel LASS для защиты от Spectre, поддержка хэшей SHA-3 и BLAKE2b, механизм Confidential VMBus, TX-оптимизации в сетевой подсистеме, протокол CAN XL, API для аппаратного ускорения HDR-вывода.
В анонсе новой версии Линус сообщил, что следующему выпуску ядра будет присвоен номер 7.0, так как в ветке 6.x накопилось достаточного выпусков для смены первого числа в номере версии (в своё время выпуск 6.0 был сформирован следом за 5.19). Смена нумерации осуществляется из эстетических соображений и является формальным шагом, снимающим дискомфорт из-за накопления большого числа выпусков в серии. Линус пошутил, что его сбивают с толку большие числа для которых не хватает пальцев на руках и ногах. При этом формально повод для значительного изменения номера версии есть, так как начиначиная со следующего выпуска
поддержку Rust решено перевести из экспериментальных в основные возможности ядра.
В новую версию принято 15657 исправлений от 2237 разработчиков,
размер патча - 52 МБ (изменения затронули 13682 файла, добавлено 794649 строк кода, удалено 335498 строк). В прошлом выпуске было 15035 исправлений от 2217 разработчиков, размер патча - 45 МБ. Около 40% всех представленных в 6.19 изменений связаны с драйверами устройств, примерно 13% изменений имеют
отношение к обновлению кода, специфичного для аппаратных архитектур, 12%
связано с сетевым стеком, 5% - с файловыми системами и 3% c внутренними
подсистемами ядра.
Дисковая подсистема, ввод/вывод и файловые системы
В Btrfs процессы проверки ФС (scrub) и замены устройств больше не блокируют переход системы в спящий режим (перед засыпанием сохраняется состояние scrub-проверки; после выхода из сна scrub-проверка продолжается, а операция замены устройств запускается заново). В реализацию RAID56 добавлена поддержка блоков, размер которых превышает размер страницы памяти. Проведена подготовка к поддержке fscrypt. Повышена производительность работы с блокировками при выполнении операций, связанных с резервированием места. Добавлена поддержка ioctl-операции "shutdown", позволяющей перевести ФС в состояние, при котором предпринимается попытка завершения выполнения уже запущенных операций, но блокируются все новые операции.
В файловой системе Ext4 включена поддержка блоков, размер которых превышает размер страницы памяти (>4KB на системах x86). Использование крупных блоков позволяет повысить производительность буферизированных операций записи в среднем на 50%, но снижает производительность прямого ввода/вывода из-за увеличения времени расчёта контрольных сумм. В новой версии также добавлены оптимизации, повысившие пропускную способность при выполнении online-дефрагментации.
В подсистеме FUSE улучшена поддержка буферизированного чтения при использовании больших фолиантов страниц памяти (large folios). Через iomap реализована возможность отслеживания частично актуальных фолиантов для загрузки только данных, отсутствующих в буфере.
В VFS добавлена поддержка отзываемого делегирования управления директорией (recallable directory delegation), позволяющего реализовать в NFS передачу управления директорией от сервера клиенту, чтобы NFS-клиент без обращений к NFS-серверу самостоятельно отслеживал состояние директории на основе локального кэша. Если другой NFS-клиент произведёт изменения, связанные с этой директорией, делегирование управления будет отозвано у первого клиента.
Для NFS добавлена поддержка чтения в режиме прямого ввода/вывода (direct I/O). Реализованы настройки /sys/kernel/debug/nfsd/io_cache_read и /sys/kernel/debug/nfsd/io_cache_write для управления включением кэширования и операций прямого ввода/вывода, манипуляции с данными настройками позволяют снизить накладные расходы на стороне NFS-клиента при выполнении крупных операций ввода/вывода.
В NTFS реализована поддержка ioctl-операции shutdown, включены по умолчанию опции монтирования "acl" и "prealloc", добавлена поддержка времени до 1 января 1970 года.
Для блочных устройств и ФС включено по умолчанию раздельное для каждого CPU кэширование объектов "bio" (Block I/O), определяющих активные операции ввода-вывода.
Память и системные сервисы
В ядро включена подсистема Live Update Orchestrator (LUO), позволяющая полноценно перезагрузить и обновить ядро без остановки работы и не теряя состояние системы, устройств и процессов. Подсистема LUO базируется на ранее добавленном в ядро механизме KHO (Kexec HandOver) и в дополнение к возможности запуска нового ядра из старого без потери состояния системы решает такие задачи, как сохранение состояния устройств и оперативной памяти, а также обеспечение непрерывности операций, связанных с DMA и обработкой прерываний. Состояние сохраняется до переключения на новое ядро и восстанавливается после задействования нового ядра без нарушения непрерывных операций с устройствами, осуществляемых системой и приложениями в пространстве пользователя.
Добавлен системный вызов listns() для вывода списка существующих в системе пространств имён без необходимости перебирать /proc/<pid>/ns/ для всех процессов.
В систему асинхронного ввода/вывода io_uring добавлена поддержка размещения элементов разного размера в очереди отправки (SQE, Submission Queue Entry), по аналогии с тем как в прошлом выпуске было разрешено смешивание размера содержимого очереди результатов (CQE, Completion Queue Event). До этого все элементы в очереди должны были иметь один размер, что приводило к излишнему потреблению памяти из-за необходимости использования максимального размера для всех элементов в очереди.
В io_uring также добавлена поддержка механизма zcrx (Zero-Copy Receive) для получения данных без копирования между ядром и пространством пользователя. Добавлена поддержка запросов раскладки памяти для очередей SQ (Submission Queue) и CQ (Completion Queue), позволяющих получить информацию о размере кольцевого буфера, необходимую при пользовательском выделении памяти при помощи флагов
IORING_SETUP_NO_MMAP и IORING_MEM_REGION_TYPE_USER.
Для быстрой трассировки стека при помощи утилит, таких как perf, добавлена поддержка формата SFrame с информацией о раскрутке стека вызовов (unwind). SFrame уже поддерживается в GCC и binutils, не приводит к снижению производительности и, в отличие от формата DWARF, содержит лишь минимальный набор информации, необходимой для трассировки стека.
В утилиту perf добавлена поддержка унифицированного описаний метрик и событий в формате JSON, а также отложенной раскрутки (deferred unwinding) стека вызовов в пространстве пользователя.
Для процессоров AMD реализован механизм подстановки данных в кэш, позволяющий устройствам ввода/вывода напрямую подставлять данные в L3-кэш CPU без их предварительного помещения в ОЗУ.
Добавлена поддержка MPAM (Memory System Resource Partitioning and Monitoring), расширения архитектуры набора команд ARMv8-A для пометки каждого обращения к памяти идентификатором секции (PARTID, Partition ID) и идентификатором группы мониторинга (PMG, Monitoring Group ID). В привязке к PARTID можно ограничить потребление ресурсов, таких как пропускная способность памяти или размер кэша, что бы какая-то группа задач не заняла все ресурсы. В контексте мониторинга сочетание PMG и PARTID можно использовать для отслеживание потребления ресурсов памяти при определённых видах нагрузки.
В случае аварийного завершения процесса после получения сигнала, другой процесс, имеющий pidfd завершившегося процесса, теперь может определить номер сигнала, приведшего к завершению процесса.
Переработана реализация перезапускаемых последовательностей (restartable sequences), позволяющих приложениям организовать псевдо-атомарное не прерываемое выполнение группы инструкций (в случае прерывания другим потоком, предпринимается повторная попытка выполнения последовательности). Новая реализация отличается более высокой производительностью.
Для BPF-программ реализованы инструкции BPF_JMP, BPF_X и BPF_JA для совершения косвенных переходов на определённую позицию из таблицы переходов. Добавлена концепция динамических указателей (dynptr), позволяющих читать данные из структурированных файлов. Добавлена возможность прикрепления к сетевым пакетам нескольких байтов с метаданными.
Модули на языке Python, используемые для обработки документации к ядру, перемещены в отдельных каталог tools/lib/python.
Добавлена функция mempool_alloc_bulk() для безопасного выделения элементов из пула памяти сразу под несколько объектов.
Продолжен перенос изменений из ветки Rust-for-Linux, связанных с использованием языка Rust в качестве второго языка для разработки драйверов и модулей ядра (поддержка Rust не активна по умолчанию, и не приводит ко включению Rust в число обязательных сборочных зависимостей к ядру). В новой версии в состав ядра встроена библиотека "syn" с парсером Rust-кода, упрощающим написание сложных макросов. Расширены возможности библиотек kernel, pin-init и rbtree. Добавлена библиотека 'num' с типажом Integer для манипуляции целыми числами. В макрос "module!" добавлена поддержка целочисленных параметров. Реализована возможность указания параметров при загрузке модулей ядра, написанных на Rust. Реализованы абстракции для подсистем I2C и PWM (Pulse Width Modulation).
Добавлен макрос "at_least" (например, "param[at_least 7]", информирующий о минимально допустимом размере массива, передаваемого в функцию. Если в функцию будет передан массив с меньшим числом элементов, то компилятор выведет предупреждение.
В состав включён скрипт klp-build для генерации модулей ядра, вносящих изменения в работающее ядро (livepatch), на основе файла с патчем. В утилиту objtool внесены изменения, необходимые для создания live-патчей.
В User-mode Linux (запуск ядра как пользовательского процесса) добавлена ограниченная поддержка многопроцессорности, но потоки внутри одного процесса пока не могут выполняться одновременно.
Началось портирование User-mode Linux на библиотеку nolibc.
Добавлена поддержка архитектуры LoongArch32 (LA32R, LA32S) в дополнение к LoongArch64.
Добавлена возможность выставления QoS-лимитов на интенсивность пробуждения процессора в режиме экономии энергии s2idle (Suspend-To-Idle), замораживающего выполнение процессов в пространстве пользователя, но оставляющего активными некоторые обработчики в ядре.
Добавлена поддержка управления таблицами страниц памяти для контроллеров IOMMU (Input-Output Memory Management Unit), выполняющих трансляцию виртуальных адресов, видимых аппаратным устройством, в физические адреса, с возможностью фильтровать операции DMA по виртуальным адресам, а также ограничивать и изолировать операции ввода-вывода.
В событиях трассировки системных вызовов реализована возможность чтения буферов из пространства пользователя и включения их содержимого (например, имён файлов) в результат трассировки.
Сторожевые страницы памяти (guard page), обращение к которым вызывает исключение и аварийное завершение процесса (SIGSEGV), теперь помечаются особой меткой в файле /proc/PID/smaps.
Добавлена возможность управления крупными страницами памяти (transparent huge page) в приватной памяти зонированных устройств.
В устройстве zram, применяемом для сжатого хранения раздела подкачки в памяти, реализована поддержка вытеснения нескольких структур "bio" (Block I/O) в пакетном режиме (writeback batching).
В состав включён шрифт "Terminus 10x18", улучшающий читаемость информации с консоли на экранах ноутбуков со средним разрешением (1440x900).
Значительно
оптимизирована работа подсистемы аудита - отмечается снижение накладных расходов в два раза.
Виртуализация и безопасность
Добавлена поддержка предоставляемой процессорами Intel возможности для разделения линейного пространства адресов (LASS, linear address-space separation), позволяющей аппаратно разделить диапазоны адресов пространства пользователя и ядра для повышения безопасности. Адресное пространство разделяется по старшему биту адреса - половина адресного пространства с установленным старшим битом используется для ядра, а нижняя - для пространства пользователя. На раннем этапе выполнения инструкций (на стадии до спекулятивного выполнения) осуществляется проверка допустимости обращения из пространства пользователя к адресам с выставленным старшим битом и наоборот. Подобное разделение позволяет блокировать утечки памяти ядра в пространство пользователя по сторонним каналам даже при спекулятивном выполнении инструкций, что даёт возможность применять LASS для защиты от атак класса Meltdown и Spectre, не приводящей к большим накладным расходам.
Добавлена возможность включения расширений усиления безопасности шины PCI Express - PCIe Link Encryption и PCIe Device Authentication, позволяющих подтверждать подлинность и шифровать канал связи между устройством PCIe и виртуальной машиной, защищённой при помощи механизмов Intel TDX (Trusted Domain Extensions) и AMD SEV-SNP (Secure Nested Paging). Реализованные технологии не позволяют перехватывать, анализировать и подставлять данные в трафик DMA при наличии доступа к хост системе или другим устройствам.
Во встроенную криптографическую библиотеку добавлена поддержка алгоритмов SHA-3 (SHA3-224, SHA3-256, SHA3-384, SHA3-512) SHAKE128, SHAKE256 и BLAKE2b.
Для LSM-модулей (Linux Security Modules) и, в частности для SELinux, реализована возможность отслеживания создания дескрипторов memfd для применения политик безопасности к связанным с ними объектам.
В LSM-модуль IPE (Integrity Policy Enforcement), определяющий общую политику обеспечения целостности для всей системы, добавлена поддержка флага AT_EXECVE_CHECK в функции execveat(), включающего проверку целостности скрипта перед его выполнением интерпретатором.
Добавлены примитивы scoped_user_read_access(), scoped_user_write_access и scoped_user_rw_access() для ограниченного доступа к данным в пользовательском пространстве с защитой спекулятивных атак.
Добавлена поддержка механизма Confidential VMBus, используемого в гипервизоре HyperV для защищённого от вмешательства гипервизора взаимодействия между гостевой системой, выполняемой в конфиденциальном режиме (с шифрованием памяти и изоляцией регистров на базе технологий AMD SNP и Intel TDX), и paravisor-ом, отвечающим за обращение к устройствам, обрабатывающим конфиденциальные данные.
Добавлена возможность передачи информации об аварийно завершившемся процессе (для генерации coredump) через механизм pidfd. Идентификатор PIDFD связывается с конкретным процессом и не меняется, в то время как PID может быть привязан к другому процессу после завершения текущего процесса, ассоциированного с этим PID. Использование pidfd позволяет блокировать совершение атак по подмене аварийно завершившегося suid-процесса на другой процесс, добиваясь состояния гонки в момент после начала обработки ядром аварийного завершения, но до проверки обработчиком в пространстве пользователя параметров процесса.
Сетевая подсистема
В сетевую подсистему внесены оптимизации для повышения эффективности передачи данных (TX). Избавление функции
__dev_queue_xmit() от spin-блокировки и использование работающей без блокировок структуры llist позволило в 4 раза увеличить производительность при большой нагрузке и удвоить интенсивность отправки пакетов при снижении нагрузки на CPU в два раза.
Предоставлена возможность отключения для отдельных сетевых сокетов системных лимитов на использование памяти (в этом случае будут использованы общие лимиты на память, задаваемые для отдельных контейнеров). Для управления отключения лимитов предложен sysctl net.core.bypass_prot_mem и флаг SK_BPF_BYPASS_PROT_MEM в функции bpf_setsockopt.
Добавлена поддержка расширения RFC 5837, добавляющего в ICMP-сообщения "Time Exceeded", возвращаемые при истечении времени жизни (TTL) пакета, данные о входящих сетевых интерфейсах для получения более детальной информации при трассировке маршрутов утилитой traceroute.
Добавлена поддержка непрерывного активного полинга (busy polling) в отдельном потоке ядра с целью извлечения дескрипторов из RX/TX-очередей для приложений, требующих минимальных задержек.
Добавлена поддержка протокола CAN XL (Controller Area Network eXtended Length), в котором размер поля с данными увеличен до 2048 байт для обеспечения интеграции с сетями TCP/IP, реализована возможность туннелирования Ethernet-кадров и добавлена поддержка широтно-импульсной модуляции, позволившая передавать данные на скоростях 20 Мбит/с и выше.
Добавлена поддержка структуры sockaddr_unsized, варианта структуры sockaddr, использующего массив с гибкими элементами вместо массива фиксированного размера (sa_data[] вместо sa_data[14], который по сути использовался для ссылок на другие структуры большего размера).
Добавлена возможность использования функциональности getsockname и getpeername через подсистему io_uring.
Добавлена поддержка линков с пропускной способностью 1600 Gbps (1.6T).
Оборудование
В подсистему DRM (Direct Rendering Manager) добавлен API для использования аппаратных возможностей преобразования цвета, позволяющих обойтись без выполнения подобных преобразований через шейдеры или выполнение кода на CPU. Для вывода контента на HDR-монитор сложные цветовые преобразования теперь могут осуществляться дисплейным контроллером на стадии до и после смешивания слоёв (blending), вместо программного композитинга содержимого в финальный буфер отображения.
Помимо снижения накладных расходов и энергопотребления при организации вывода в HDR, предложенная функциональность может использоваться для корректной цветопередачи в редакторах видео или изображений.
Добавлен драйвер "ethosu" для NPU Arm Ethos U65 и U85, предназначенных для аппаратного ускорения выполнения AI-моделей.
В драйвере i915 для GPU Lunar Lake и новее добавлена поддержка аппаратного повышения чёткости изображения (Sharpening).
Продолжена работа над drm-драйвером (Direct Rendering Manager) Xe для GPU на базе архитектуры Intel Xe, которая используется в видеокартах Intel семейства Arc и интегрированной графике, начиная с процессоров Tiger Lake. Добавлена начальная поддержка архитектуры Xe3P, используемой в GPU Crescent Island и семействе процессоров с интегрированной графикой Nova Lake.
В драйвере AMDGPU реализована полноценная поддержка видеокарт AMD семейства GCN 1.0 "Southern Island" и 1.1 "Sea Islands", для работы с которыми ранее использовался драйвер Radeon. Драйвер AMDGPU доведён до паритета по возможностям с драйвером Radeon и активирован для указанных GPU по умолчанию. Карты GCN 1.x выпускались с 2012 по 2019 год и охватывают такие модели, как Radeon HD 77xx/78xx/79xx/87xx/88xx/89xx, Radeon R9 280, FirePro W4000-W9000, Radeon Sky 700/900, Radeon R9 265/270/370, Radeon R9 290/390, HD 7790 / 8870 и иные видеокарты семейств Radeon Rx 200 / Rx 300. Помимо увеличения производительности в среднем на 24%, переход на AMDGPU позволил реализовать для данных GPU поддержку графического API Vulkan 1.3. Кроме того, в AMDGPU добавлена поддержка аналоговых коннекторов и Video Coding Engine 1.0, а также задействован по умолчанию стек DC (Display Core) для GPU на базе микроархитектуры Bonaire (Radeon HD 7790).
В драйвере Nouveau реализована поддержка аппаратного ускорителя NVJPG, присутствующего в SoC Tegra210.
В драйвер Panthor добавлена поддержка GPU Mali-G1 и начальная поддержка чипа MediaTek MT8196.
Добавлена поддержка звуковой подсистемы чипов Intel Nova Lake S, ноутбуков HP с HDA CS35L41, а также звуковых интерфейсов CIX IPBLOQ HD и Onkyo SE-300PCIE.
Продолжена интеграция компонентов драйвера Nova для GPU NVIDIA, оснащённых GSP-прошивками, используемыми начиная с серии NVIDIA GeForce RTX 2000 на базе микроархитектуры Turing. Драйвер написан на языке Rust. В новой версии началась работа над RPC и завершена реализация загрузки сопроцессора GSP (GPU System Processor).
Добавлена поддержка смартфонов и планшетов на базе SoC Mediatek MT6582 (Alcatel yarisxl), Nvidia Tegra124 (Xiaomi Mi Pad) и Qualcomm MSM8939 (ASUS ZenFone 2). Добавлена поддержка ноутбуков на SoC Qualcomm sdm850, таких как Huawei MateBook E 2019.
Добавлена поддержка SoC и плат на базе архитектуры RISC-V: OrangePi R2S, OrangePi RV, Anlogic dr1v90, Tenstorrent Blackhole.
Одновременно латиноамериканский Фонд свободного ПО сформировал
вариант полностью свободного ядра 6.19 - Linux-libre 6.19-gnu, очищенного от элементов прошивок и драйверов, содержащих несвободные компоненты или участки кода, область применения которых ограничена производителем. В выпуске 6.19 из звуковой подсистемы SDCA
удалён код для загрузки бинарных прошивок. Обновлён код чистки blob-ов в драйверах Intel XE, Nova-Core, Qualcomm Iris, Venus and Q6V5, TI PRUeth, Intel iwlwifi, Marvell mwifiex, FourSemi fs210x, Realtek rt1320 и звуковых кодеках TI tas2783. Выполнена чистка имён blob-ов в dts-файлах (devicetree) для ARM-чипов. Прекращена чистка драйвера STM C8SECTPFE DVB, удалённого из ядра.
Компания Anthropic объявила о расширении в AI-модели Claude Opus 4.6 возможностей по поиску уязвимостей в коде и поделилась результатами эксперимента, в ходе которого выявлено более 500 ранее неизвестных (0-day) уязвимостей в последних версиях различных открытых проектов. Работа была сфокусирована на поиске уязвимостей, вызванных проблемами при работе с памятью, так как их наличие проще проверить. Всем выявленным уязвимостям присвоен высокий уровень опасности. Каждая уязвимость была вручную проверена и подтверждена сотрудниками Anthropic или привлечёнными внешними исследователями безопасности.
Для анализа уязвимостей были привлечены кодовые базы популярных открытых проектов, уже длительное время проходящие непрерывное fuzzing-тестирование в сервисе OSS-Fuzz. В отличие от fuzzing-тестирования, при котором генерируется поток всевозможных случайных комбинаций входных данных, AI-модель пыталась анализировать код, учитывая прошлые исправления для выявления похожих неустранённых ошибок, выделяя проблемные шаблоны и логически выводя, какие входные данные могут нарушить ход выполнения.
Информация о выявленных в ходе эксперимента уязвимостях уже начала передаваться сопровождающим, с которыми ведётся совместная работа по принятию исправлений. Чтобы помочь сопровождающим в ходе проведённой проверки вручную были разработаны патчи для исправления выявленных проблем. В качестве примера приведены три уязвимости в GhostScript, OpenSC и CGIF, которые на момент публикации устранены сопровождающими.
Используемая для выявления проблем конфигурация не была похожа на традиционные системы автоматического поиска уязвимостей - модели Claude Opus 4.6 был предоставлен доступ к виртуальной машине, в которой помимо исследуемого кода были установлены типовые инструменты разработчиков (coreutils, Python и т.п.) и утилиты для отладки и анализа уязвимостей (в том числе утилиты для fuzzing-тестирования). Модели не давалась чёткая инструкция по использованию данных инструментов и не предоставлялись специальные сведения о методах поиска уязвимостей. Модели была лишь поставлена задача и предоставлена возможность самостоятельно рассуждать об оптимальном использовании доступных инструментов.
Поиске уязвимостей в GhostScript AI-модель вначале попыталась провести fuzzing-тестирование, но когда это не привело к результату переключилась к анализу кода. Анализ кода тоже не дал результата и тогда модель начала изучать историю изменений в git и в одном из коммитов заметила упоминание проверки границ буфера. Разобрав коммит модель определила, что исправление добавляло недостающую проверку границ буфера при обработке шрифтов.
Далее модель определила код, который был до исправления и попыталась найти в остальном коде похожие шаблоны использования проблемной функции, остающиеся неисправленными. В итоге в файле gdevpsfx.c был выявлен вызов функции gs_type1_blend без проверки корректности значений. В финале модель подобрала содержимое файла, обработка которого приводила к аварийному завершению из-за записи данных в область памяти вне выделенного буфера.
В CGIF AI-модель отталкивалась от того, что при распаковке GIF-файлов библиотека рассматривала, что размер сжатых данных всегда меньше распакованных. Поиск уязвимости был сосредоточен на определении условий, при которых сжатые алгоритмом LZW данные окажутся больше распакованных. Подобные условия были найдены и AI-модель смогла сформировать GIF-файл, обработка которого привела к переполнению буфера. В OpenSC проблема была выявлена после анализа использования в коде потенциально опасных функций strrchr и strcat.
Отмечается, что языковые модели достигли уровня, позволяющего выявлять ранее неизвестные уязвимости, и в ближайшее время превзойдут экспертов по безопасности по скорости и масштабу поиска уязвимостей.
Предполагается, что рост числа выявляемых уязвимостей потребует реформирования сложившихся процессов раскрытия информации, так как ныне выделяемых на исправление 90-дней будет недостаточно.
Доступен выпуск мобильной платформы LineageOS 23.2, продолжающий развитие кодовой базы на основе Android 16. Ветка LineageOS 23.2 достигла паритета по функциональности и стабильности c веткой 23.0, и признана готовой для формирования релиза. Сборки подготовлены для 148 моделей устройств. LineageOS также можно запустить в эмуляторе Android Emulator, в QEMU и в среде Android Studio. Дополнительно, предоставлена возможность сборки в режиме Android TV и Android Automotive.
Выпуск LineageOS 23.2 примечателен синхронизацией с актуальной кодовой базой из репозитория AOSP (Android Open Source Project), соответствующей второму квартальному обновлению платформы Android 16 (QPR2). Выпуск LineageOS 23.1 пропущен, так как AOSP теперь обновляется раз в полгода, а не раз в квартал. В дальнейшем промежуточные релизы LineageOS будут выпускаться не четыре, а два раза в год.
Из функциональных изменений в LineageOS 23.2 отмечается задействование нового оформления и цветовой схемы, соответствующих предложенной в Android 16 концепции дизайна Material Expressive 3. Приложения обновлены и по возможности также переведены на концепцию оформления Material Expressive. Среди прочего новое оформление задействовано в музыкальном проигрывателе Twelve (Music Player), часах Deskclock и калькуляторе ExactCalculator.
Обновлён интерфейс выпадающей панели с быстрыми настройками - плитки в панели теперь полностью настраиваются. В дополнение к базовой теме оформления предложена опциональная расширенная тёмная тема. Расширена функциональность утилит для работы с файлами. Для разработчиков прошивок предложено несколько новых утилит для извлечения RRO (Runtime Resource Overlay), обновления сертификатов приложений, извлечения правил SELinux и файлов конфигурации из системных образов.
Отдельно отмечена значительная переработка программы для управления обновлением прошивки (Updater), в которой полностью переделан интерфейс, улучшено управление обновлениями и добавлена анимация прогресса выполнения операций. Переделанный вариант Updater признан не готовым для включения в состав LineageOS 23.2, но он будет предложен в скором времени после достижения должного уровня стабильности.
Вячеслав Дубейко из компании IBM запустил в списке рассылки разработчиков ядра Linux обсуждение использования в ядре моделей машинного обучения, а также предложил для тестирования набор патчей с библиотекой для интеграции ML-моделей в ядро и примером символьного драйвера, использующего библиотеку.
Интеграция ML-моделей в ядро может быть полезной для изменения логики работы подсистем с учётом обрабатываемых данных, оптимизации работы и изменения конфигурации в зависимости от внутреннего состояния систем. Применение машинного обучения, способного выявлять закономерности и строить прогнозы без ручной реализации алгоритмов, упростит подбор наиболее эффективной конфигурации ядра c учётом сложности и изменчивости современных рабочих нагрузок, а также позволит решать такие проблемы, как предсказание сбоев систем хранения.
Помимо движка для выполнения моделей рассматривается разработка инструментов сбора данных для обучения ML-моделей, непосредственно обучения модели и тестирования результата. Так как для выполнения ML-модели требуются операции с плавающей запятой, а в ядре не допускается прямое использование FPU, предложенный прототип представляет собой прослойку для обращения из различных подсистем ядра к ML-моделям, выполняемым в пользовательском пространстве, по аналогии с выносом в пользовательское пространство обработчиков SPDK, DPDK и ublk.
Вынос выполнения и обучения модели в пространство пользователя упрощает сопровождение и изолирует ядро от проблем в коде выполнения модели. На стадии обучения данные о состоянии и параметрах ядра могут как запрашиваться обработчиком из пользовательского пространства, так и передаваться прослойкой, выполняемой на уровне ядра. Для управления взаимодействия компонентами в ядре и пользовательском пространстве применяется sysfs. Возможно адаптивное обучение ML-модели, при котором подсистема ядра получает рекомендацию от ML-модели, применяет рекомендуемое изменение и оценивает эффективность рекомендации по изменению состояния.
В качестве демонстрации возможности автономно создавать крупные проекты при помощи новой AI-модели Claude Opus 4.6, компания Anthropic сгенерировала компилятор для языка Си - claudes-c-compiler, пригодный для сборки ядра Linux, PostgreSQL, SQLite, Redis, FFmpeg, GNU coreutils, Busybox, CPython, QEMU, LuaJIT и ещё около 150 протестированных известных открытых проектов. Результирующие сборки успешно прошли предоставляемые проектами тестовые наборы. Собранное ядро Linux успешно загружается и даёт возможность запустить игру Doom. Код компилятора сгенерирован на языке Rust и опубликован как общественное достояние (CC0). Поддерживается компиляция проектов для архитектур x86_64, i686, AArch64 и RISC-V 64.
Весь код и документация к компилятору сгенерированы моделью Claude Opus 4.6. Участие человека свелось к определению тестовых сценариев, которым должен удовлетворять итоговый продукт. Интерактивный режим для разработки, отладки и контроля над качеством не применялся, Модель Claude Opus сама выполнила всю работу на основе поставленной задачи. Ручное рецензирование корректности работы компилятора не проводилось, поэтому он не рекомендован для использования помимо экспериментов. Степень прохождения тестовых наборов компиляторов, включая GCC Torture Tests, составляет 99%.
Для разработки компилятора было привлечено 16 AI-агентов, которые после двух недель работы и около двух тысяч сеансов в Claude Code сгенерировали 100 тысяч строк кода на Rust, выполняющих задачу сборки ядра Linux 6.9 для архитектур x86, ARM и RISC-V. При генерации кода использовался новый режим работы "agent teams", позволяющий организовать параллельную работу нескольких AI-агентов Claude над одной общей кодовой базой, осуществляемую автономно без вмешательства человека. По стоимости доступа к API создание компилятора оценено в 20 тысяч долларов (передано 2 миллиарда входных токенов и сгенерировано 140 миллионов выходных токенов).
Компилятор самодостаточен и не требует внешних зависимостей, кроме стандартной библиотеки Rust. Все компоненты созданы с нуля, включая фронтэнд, промежуточное представление (IR) на базе SSA, оптимизатор, генератор кода, ассемблер, компоновщик и генератор отладочной информации в формате DWARF. Фронтэнд совместим на уровне опций с GCC и может использоваться в качестве прозрачной замены GCC. На выходе генерируются исполняемые файлы в формате ELF. Поддерживается только платформа Linux (задача поддержки macOS и Windows не ставилась).
Из ограничений отмечается отсутствие раздельных уровней оптимизации
(уровни с -O0 по -O3, -Os и -Oz приводят к одинаковой оптимизации), имеются проблемы с использованием _Atomic и _Complex, частично поддерживается ключевое слово __attribute__ и частично реализовано использование инструкций NEON. Помимо ограничений, описанных в подготовленной AI документации к компилятору, в статье с анонсом проекта упоминаются некоторые дополнительные проблемы:
Отсутствие поддержки компиляции в 16-разрядном режиме (необходимый для загрузки ядра 16-разрядный код был собран в GCC).
Ошибки в реализациях компоновщика и ассемблера (при подготовке демонстрации использовались GNU assembler и GNU linker).
Claudes-c-compiler пока не готов заменить реальные компиляторы, так как не все проекты успешно собираются.
Cтепень оптимизации генерируемого кода хуже, чем в GCC с отключением всех режимов оптимизации.
Качество сгенерированного Rust-кода приемлемое, но заметно хуже чем код, подготовленный профессиональным программистом.
Проект близок к потолку возможностей модели Opus 4.6 - попытки исправить ошибки или добавить дополнительные возможности, как правило, приводили к нарушению имеющейся функциональности.
