Группа исследователей из Лёвенского католического университета (Бельгия), выявила архитектурную уязвимость (CVE-2023-52424) в стандарте Wi-Fi IEEE 802.11, позволяющую организовать подключение к менее защищённой беспроводной сети, вместо заслуживающей доверия сети, к которой намеревался подключиться пользователь, после чего можно организовать перехват и манипуляции трафиком. Проблема проявляется в беспроводных стеках любых операционных систем и затрагивает методы аутентификации WPA3, WEP, EAP, AMPE и FILS.
Предложенная техника атаки, которой присвоено имя SSID Confusion, позволяет обойти присутствующие в протоколе методы аутентификации точки доступа, защищающие от подмены идентификатора сети SSID и не позволяющие создавать подставные сети с именем сети, к которой подключается клиент. Причиной проблемы является определение в стандарте ситуаций, когда SSID может быть неаутентифицирован. В частности, для обозначения своего присутствия точка доступа отправляет в широковещательном режиме beacon-кадры, включающие сведения о SSID-сети. Для упрощения процесса поиска сети клиенты не аутентифицируют SSID в данных кадрах, так как предполагается, что проверка потребуется после того, как клиент решит подключиться к сети.
Для успешного совершения атаки требуется, чтобы пользователь инициировал подключение к определённой беспроводной сети, а поблизости была другая беспроводная сеть с теми же параметрами подключения, что и в первой сети. Подобное практикуется, например, когда для диапазонов 2.4GHz и 5GHz создаются разные сети, одна из которых слабо защищена и уязвима для типовых атак по перехвату трафика, таких как KRACK или Frag. Проблемная конфигурация также
применяется в некоторых университетских сетях, поддерживающих сервис Eduroam. Атакующий должен находиться в зоне досягаемости сигнала для того, чтобы вклиниться между пользователем и целевой сетью (MitM). Для проведения атаки злоумышленнику не требуется знать учётные данные жертвы.
Атака сводится к созданию атакующим точки доступа (WrongAP на диаграмме), обеспечивающей на другом канале трансляцию обращений к менее защищенной подставной сети (WrongNet), к которой должен подключиться клиент вместо желаемой сети (TrustedNet). Точка доступа может быть создана на обычном ноутбуке и применяется для организации многоканальной MitM-атаки на жертву (MC MitM). Атака осуществляется в три этапа:
Определение сети (Network Discovery). MitM-система перехватывает пакеты, отправляемые в эфир жертвой и заслуживающей доверия точкой доступа (TrustedNet), заменяя в них SSID - в пакетах от точки доступа SSID заменяется на идентификатор менее защищённой сети, а в ответах жертвы на реальный, чтобы симулировать взаимодействие клиента и заслуживающей доверия точки доступа. В итоге устройство жертвы получает ответы и считает, что искомая сеть находится поблизости, несмотря на то, что эти ответы транслируются точкой доступа атакующего.
Захват аутентификации (Authentication hijacking). Атакующий симулирует успешную аутентификацию и вынуждает клиента подключиться к менее защищенной сети, вместо заслуживающей доверия. Как и на прошлой стадии атакующий перехватывает кадры, отправляемые при аутентификации клиентом, заменяет в них SSID и переотправляет точке доступа.
MitM. После согласования канала связи атакующий подменяет SSID c WrongNet на TrustedNet, создавая впечатление, что пользователь работает через заслуживающую доверия сеть, а не через менее защищенную сеть.
Воспользовавшись уязвимостью атакующий может вынудить клиента подключиться к менее защищённой сети, и при этом в интерфейсе будет отображаться SSID сети, к которой изначально намеревался подключиться пользователь, а не той, к которой он подключён фактически. Добившись подключения пользователя через не защищённую сеть атакующий может анализировать и вклиниваться в незашифрованные потоки трафика. При этом при использовании некоторых VPN, таких как WARP, hide.me и Windscribe, VPN не будет задействован при подключении к сетям, помеченным в настройках как заслуживающие доверия.
Атака применима к протоколам беспроводной аутентификации, использующим EAP (Extensible Authentication Protocol), SAE (Simultaneous Authentication of Equals) и 802.1X, а также в опциональном режиме работы протокола WPA3, в которых SSID не используется при формировании ключа PMK (Pairwise Master Key), что делается для исключения изначально известных данных при формировании ключа с целью защиты от различных криптоатак. Протокол FILS (Fast Initial Link Setup) уязвим при использовании PMK, созданного при согласовании соединения на базе EAP. Протоколы WPA1, WPA2 и FT (Fast BSS Transition) не подвержены проблеме, так как требуют корректного SSID при согласовании соединения.
Для защиты от атаки SSID Confusion на стороне точки доступа упоминается включение в стандарт 802.11 требования аутентификации SSID при подключении, что может быть реализовано через добавление SSID в функцию формирования ключа или включение SSID в число дополнительных данных, проверяемых во время согласования соединения. На стороне клиента защита может быть организована через обеспечение защиты beacon-кадров (будет применяться в WiFi 7). Создатели сетей могут предотвратить совершение атаки, отказавшись от использования общих учётных данных в сетях с разными SSID. Пользователи могут защитить себя, используя надёжные VPN при подключении через любые беспроводные сети.
Исследователи из компании ESET опубликовали 43-страничный отчёт с анализом руткита Ebury и связанной с ним активности. Утверждается, что Ebury применяется с 2009 года и с тех пор был установлен на более чем 400 тысяч серверов под управлением Linux и несколько сотен систем на базе FreeBSD, OpenBSD и Solaris. Около 110 тысяч серверов оставались поражены Ebury по состоянию на конец 2023 года. Исследование представляет отдельный интерес с учётом того, что Ebury был задействован при атаке на kernel.org, что открывает некоторые новые подробности компрометации инфраструктуры разработки ядра Linux, выявленной в 2011 году. Ebury также был выявлен на серверах регистратора доменов, криптобиржах, выходных узлах Tor и у нескольких хостинг-провайдеров, имена которых не называются.
Изначально предполагалось, что атаковавшие серверы kernel.org злоумышленники оставались незамеченными 17 дней, но по данным ESET это время рассчитано с момента подстановки руткита Phalanx, а бэкдор Ebury находился на серверах с 2009 года и около двух лет мог использоваться для получения root-доступа к серверам. Вредоносное ПО Ebury и Phalanx установлено в рамках разных атак, не пересекающихся друг с другом и проводимых разными группами злоумышленников. Внедрение бэкдора Ebury затронуло как минимум 4 сервера в инфраструктуре kernel.org, два из которых были поражены приблизительно в течение двух лет, а остальные два - в течение 6 месяцев.
Атакующие получили доступ к хранящимся в /etc/shadow хэшам паролей 551 пользователя, среди которых были все мэйнтейнеры ядра (аккаунты использовались для доступа в Git; после инцидента пароли были заменены, а модель доступа была пересмотрена и переведена на использование цифровых подписей). Для 257 пользователей атакующим удалось определить пароли в открытом виде, предположительно путём подбора паролей по хэшам и через перехват вредоносным компонентом Ebury паролей, используемых в SSH.
Вредоносный компонент Ebury распространялся в виде разделяемой библиотеки, которая после установки перехватывала функции, используемые в OpenSSH, для организации удалённого подключения к системе c правами root. Атака была не целевой и, как и другие поражённые тысячи хостов, серверы kernel.org использовались как часть ботнета для рассылки спама, кражи учётных данных для распространения на других системах, перенаправления web-трафика и совершения другой вредоносной деятельности.
Для проникновения на серверы использовались неисправленные уязвимости в серверном ПО, например, уязвимости в хостинг-панелях, или перехваченные пароли (предполагается, что серверы kernel.org был взломаны в результате компрометации пароля одного из пользователей, имевшего shell-доступ). Для повышения привилегий использовались уязвимости, такие как Dirty COW.
Применяемые в последние годы новые версии Ebury кроме бэкдора включали в себя такие возможности, как модули к Apache httpd для проксирования трафика, перенаправления пользователей и перехвата конфиденциальной информации, модуль ядра для внесения изменений в транзитный HTTP-трафик, инструменты для скрытия собственного трафика от межсетевых экранов, скрипты для проведения AitM-атак (Adversary-in-the-Middle, двунаправленный MiTM) для перехвата учётных данных SSH в сетях хостинг-провайдеров.
Опубликованы корректирующие выпуски распределённой системы управления исходными текстами Git 2.45.1, 2.44.1, 2.43.4, 2.42.2, 2.41.1, 2.40.2 и 2.39.4, в которых устранены пять уязвимостей. Наиболее серьёзная уязвимость (CVE-2024-32002), которой присвоен критический уровень опасности, позволяет добиться выполнения кода злоумышленника при выполнении клонирования командой "git clone" репозитория, подконтрольного атакующему.
Уязвимость проявляется только в файловых системах, не различающих регистр символов и поддерживающих символические ссылки, например, используемых по умолчанию в Windows и macOS. Эксплуатация осуществляется через создание в субмодуле каталога и символической ссылки, отличающихся только регистром символов, что позволяет добиться записи файлов в каталог .git/, вместо рабочего каталога субмодуля. Получив возможность записи в .git/ атакующий может переопределить hook-вызовы через .git/hooks и добиться выполнения произвольного кода во время выполнения операции "git clone".
Другие уязвимости:
CVE-2024-32004 - атакующий в многопользовательской системе может подготовить специально оформленный локальный репозиторий и добиться выполнения кода при его клонировании. В частности, атакующий может создать локальный репозиторий, выглядящий как частичный клон, в котором отсутствует определённый объект. Клонирование этого репозитория приведёт к выполнению кода с правами пользователя, выполняющего операцию клонирования.
CVE-2024-32465 - клонирование из zip-архивов, содержащих полный git-репозиторий, включающий hook-и в каталоге .git/, приведёт к выполнению этих hook-ов.
CVE-2024-32020 - создание локальных клонов репозитория на том же диске в многопользовательской системе позволяет другим пользователям изменить файлы, для которых задействованы жёсткие ссылки.
CVE-2024-32021 - клонирование локального репозитория с символическими ссылками, может использоваться для создания жёстких ссылок на произвольные файлы в каталоге objects/.
Помимо устранения уязвимостей в новых версиях также предложено несколько изменений, нацеленных на повышение защиты от уязвимостей, приводящих к удалённому выполнению кода и манипулирующих символическими ссылками при выполнения клонирования. Например, git теперь выдаёт предупреждение при наличии символических ссылок в каталоге .git/. Пути к субмодулям отныне могут содержать только реальные каталоги. При пересечении символических ссылок и каталогов, обрабатываются каталоги. При выполнении "git clone" добавлена защита от выполнения hook-ов во время клонирования и усилены проверки параметра core.hooksPath.
Организация NetBSD Foundation представила обновлённые правила внесения изменений в дерево исходных текстов проекта. В новых правилах появился пункт, запрещающий включение в состав NetBSD кода, сгенерированного с использованием AI-инструментов на базе больших языковых моделей, таких как ChatGPT, GitHub Copilot и Code Llama, без предварительного письменного утверждения командой Core Team. В качестве причины упомянуты неопределённость в области авторских прав и несоответствия политике лицензирования NetBSD.
Опасения связаны с тем, AI-системы обучаются на большом массиве информации, среди прочего включающем код, защищённый авторским правом и распространяемый под разными лицензиями. При генерации кода AI-системами эти особенности не учитываются и потенциально результат работы AI может рассматриваться как создание производной работы от кода, который использовался при обучении модели и распространяется под определёнными лицензиями.
При обучении модели на коде с лицензией, требующей извещения об авторстве, в генерируемом AI-инструментами коде данное требование формально не выполняется, что может рассматриваться как нарушение большинства открытых лицензий, таких как GPL, MIT и Apache. Также могут возникнуть проблемы с лицензионной совместимостью при вставке в проекты под пермиссивными лицензиями, такими как BSD, кода, сгенерированного с использованием моделей, обученных на коде с копилефт-лицензиями.
Разработчики GNOME OS, экспериментального дистрибутива для разработчиков и тестировщиков GNOME, позволяющего оценить состояние разработки среды рабочего стола, ознакомиться с появляющимися новыми возможностями и протестировать работу своих приложений в находящихся в разработке ветках GNOME, объявили о переходе на использование компонента systemd-sysupdate для организации атомарного обновления системы. Целью изменения является желание адаптировать ночные сборки GNOME OS для проведения ежедневного контроля качества разработки GNOME.
В настоящее время для формирования и обновления начинки корневого раздела GNOME OS задействована система OSTree, при использовании которой системный образ атомарно обновляется из Git-подобного хранилища. Системный раздел монтируется в режиме только для чтения, а обновления доставляются в виде небольших порций, содержащих изменения, относительно прошлого состояния (delta-обновления), что, например, в процессе тестирования GNOME позволяет при необходимости легко откатить систему на одну из предыдущих версий и проверить проявляется ли в ней выявленная ошибка.
Инструментарий systemd-sysupdate поставляется начиная с systemd 251 и предназначен для автоматического определения, загрузки и установки обновлений с использованием атомарного механизма замены разделов, файлов или каталогов. Systemd-sysupdate позволяет использовать два независимых раздела/файла/каталога, на одном из которых находится текущий работающий ресурс, а на другом устанавливается очередное обновление, после чего разделы/файлы/каталоги меняются местами.
Из преимуществ перевода GNOME OS c OSTree на systemd-sysupdate называется возможность задействовать верифицированный процесс загрузки, в котором цепочка доверия распространяется от загрузчика до системных компонентов дистрибутива. Кроме того, использование systemd-sysupdate даст возможность добиться более полной интеграции с systemd и задействовать архитектуру, манипулирующую готовыми системными образами как неделимыми компонентами.
Эксперименты по созданию sysupdate-образов с поддержкой UEFI Secure Boot были проведены ещё осенью прошлого года. По сути сейчас уже доступны два варианта сборок GNOME OS, созданных на базе OSTree и systemd-sysupdate. Остаётся обеспечить интеграцию sysupdate с GNOME и предоставление графического интерфейса для обновления системы.
В настоящее время управление обновлениями на базе sysupdate производится только из командной строки и требует наличия прав root. Для интеграции с GNOME уже разработан сервис D-Bus, которые в сочетании с Polkit, позволяет управлять обновлениями под непривилегированным пользователем. Развиваемый D-Bus-сервис и связанную с ним утилиту updatectl намерены включить в основной состав systemd.
В дальнейшем планируется добавить функциональность управления обновлениями на базе sysupdate в приложение GNOME Software, для которого подготовлен экспериментальный плагин gs-plugin-systemd-sysupdate, реализующий возможность обновления ОС через DBus сервис к sysupdate.
Из ещё нерешённых задач отмечается необходимость добавления в systemd-sysupdate поддержки delta-обновлений (в настоящее время образы загружаются только целиком) и создание инструментов для поддержания параллельно нескольких версий операционной системы на базе стабильной и находящейся в разработке веток GNOME.
Представлен выпуск дистрибутива Endless OS 6.0, нацеленного на создание простой в работе системы, в которой можно быстро подобрать приложения на свой вкус. Приложения распространяются в виде самодостаточных пакетов в формате Flatpak. Размер предлагаемых загрузочных образов составляет от 1.2 до 23 ГБ.
Дистрибутив не использует традиционные пакетные менеджеры, вместо которых предлагается минимальная атомарно обновляемая базовая система, работающая в режиме только для чтения и формируемая при помощи инструментария OSTree (системный образ атомарно обновляется из Git-подобного хранилища). Идентичные с Endless OS идеи пытаются повторить разработчики Fedora в рамках проекта Silverblue по созданию атомарно обновляемого варианта Fedora Workstation, а также создатели Vanilla OS, CarbonOS, tau-OS и Pop!_OS. Инсталлятор и система обновления Endless OS, используются в проекте GNOME OS.
Endless OS относится к числу дистрибутивов, продвигающих инновации среди пользовательских Linux-систем. Рабочее окружение в Endless OS основано на значительно переработанном форке GNOME. При этом разработчики Endless активно участвуют в разработке upstream-проектов и передают им свои наработки. Например, в выпуске GTK+ 3.22 около 9.8% всех изменений было подготовлено разработчиками Endless, а курирующая проект компания Endless Mobile входит в надзорный совет GNOME Foundation, наряду с FSF, Debian, Google, Linux Foundation, Red Hat и SUSE.
В настройки внешнего вида добавлена возможность включения тёмного стиля оформления, более комфортного для глаз при работе в тёмное время суток.
Обновлён и адаптирован для работы с тёмной темой оформления внешний вид всех базовых приложений, среди которых файловый менеджер, конфигуратор и система установки приложений. Новый интерфейс примечателен задействованием плоского дизайна и более контрастного выделения элементов.
Изменения в стилевом оформлении базируются на стандартных технология и также действуют в браузерах (Chrome, Firefox, GNOME Web, Chromium) и большинстве других приложений, загружаемых через App Center.
Переработано приложение для создания скриншотов и записи скринкастов. Упрощён процесс выбора области экрана, окна приложения или всего экрана. Выбранные области запоминаются, что избавляет от необходимости повторного выделения при создании последующих снимков. Для создания скриншота можно использовать кнопку PrintScr или отдельную пиктограмму в меню.
В базовую поставку включено новое приложение Music для управления музыкальной коллекцией и прослушивании музыки (Rhythmbox заменён на
GNOME Music).
В состав включено приложение Decibels для воспроизведения отдельных звуковых файлов, которое может применяться, например, для быстрой оценки полученных по почте голосовых сообщений.
Обновлён просмотрщик изображений (Eye of GNOME заменён на GNOME Image Viewer), в котором модернизирован интерфейс, проведена оптимизация производительности и добавлена поддержка новых форматов, таких как HEIC/HEIF и WebP. Расширено управления при помоги мультитач жестов, например, при масштабировании щипком на тачпаде или сенсорном экране.
Добавлена коллекция приложений, которые могут быть полезны разработчикам игр, например, инструментарий для игрового движка Godot, звуковой редактор Audacity, система 3D-моделирования Blender и руководства к ней, графический редактор GIMP, векторный редактор Inkscape и редактор спрайтов и анимации Pixelorama.
Добавлены образовательные приложения и обучающие игры:
Aqueducts, Dragon's Apprentice, Fablemaker, Frog Squash, The Passage,
Tank Warriors.
Изменено поведение при нехватке памяти в системе. Настройки изменены для более активного закрытия приложений на начальном этапе нехватки памяти, чтобы не доводить систему до подвисаний.
Осуществлён переход на использование мультимедийного сервера Pipewire 1.0.
Системное окружение обновлено до Debian 12.5 (в ветке Endless OS 5 использовался Debian 11). Ядро Linux обновлено до версии 6.5. Компоненты GNOME синхронизированы с версией 43.9.
Джоб Снейдерс (Job Snijders), маститый разработчик OpenBSD, руководитель одного из комитетов в IETF (Internet Engineering Task Force), автор 11 RFC, связанных с маршрутизацией и RPKI, и создатель IRRd (Internet Routing Registry Daemon), опубликовал набор патчей для OpenBSD, добавляющих новый sysctl-параметр "net.inet.tcp.nodelay" для отключения алгоритма Нейгла на уровне всей системы. Параметр избавляет разработчиков приложений от выставления флага TCP_NODELAY для отдельных сокетов.
Алгоритм Нейгла используется для агрегирования мелких сообщений с целью снижения трафика. Алгоритм приостанавливает отправку новых сегментов TCP до получения подтверждения о приёме ранее отправленных данных или до наступления таймаута. Например, без применения агрегирования при отправке 1 байта, дополнительно отправляется 40 байтов с TCP и IP заголовками пакета, а с применением алгоритма Нейгла - сообщения, отправленные до прихода подтверждения от удалённой стороны, накапливаются и отправляются одним пакетом. Из-за наличия оптимизации "delayed ACK", задерживающей отправку ACK-пакетов, сигнал через пакеты с подтверждением на деле не работает, и отправка накопленных сообщений выполняется при наступлении таймаута.
Снейдерс придерживается мнения, что в современных реалиях алгоритм Нейгла, разработанный во времена, когда несколько пользователей конкурировали за полосу пропускания 1200 бод, устарел и в высокоскоростных сетях от него больше вреда чем пользы. Недавно подобную позицию также высказал Марк Брукер (Marc Brooker) из компании Amazon Web Services (AWS). С доводами в пользу отключения алгоритма Нейгла по умолчанию
можно ознакомиться в опубликованной несколько дней назад заметке.
Для отключения алгоритма Нейгла предусмотрена опция TCP_NODELAY, которая может быть выставлена для отдельных сетевых сокетов. Режим TCP_NODELAY давно выставляется во многих приложениях OpenBSD, среди которых openssh, httpd, iscsid, relayd, bgpd и unwind, и, по мнению Снейдерса, настало время для предоставления возможности его включения для всех TCP-сокетов на уровне всей системы. Снейдерс предлагает обсудить вопрос включения TCP_NODELAY по умолчанию и перевода алгоритма Нейгла в разряд отдельной включаемой опции.
Опубликована новая редакция проекта Vortex, развивающего открытый GPGPU на базе архитектуры набора команд RISC-V, рассчитанный на выполнение параллельных вычислений с использованием API OpenCL и модели выполнения SIMT (Single Instruction, Multiple Threads). Проект также может быть использован при проведении исследований в области 3D-графики и при разработке новых архитектур GPU. Схемы, описания аппаратных блоков на языке Verilog, симулятор, драйверы и сопутствующая проектная документация распространяются под лицензией Apache 2.0.
Основу GPGPU составляет типовой ISA RISC-V, расширенный некоторыми дополнительными инструкциями, необходимыми для поддержки функций GPU и управления потоками. При этом изменения в архитектуре набора команд RISC-V сведены к минимуму и по возможности используются уже имеющиеся векторные инструкции. Похожий подход применяется в проекте RV64X, который также развивает открытый GPU на базе технологий RISC-V.
Основные особенности Vortex:
Поддержка 32- и 64-разрядных архитектур набора команд RISC-V RV32IMF и RV64IMAFD.
Настраиваемое число ядер, блоков задач (warps) и потоков.
Настраиваемое число ALU, FPU, LSU и SFU для каждого ядра.
Настраиваемая ширина выдачи конвейера (pipeline issue width).
Опциональная разделяемая память и кэши уровней L1, L2 и L3.
Поддержка спецификации OpenCL 1.2.
Возможность реализации на базе FPGA Altera Arria 10,
Altera Stratix 10, Xilinx Alveo U50, U250, U280 и Xilinx Versal VCK5000.
Расширенные инструкции: "tex" для ускорения обработки текстур, vx_rast для управления растеризацией, vx_rop для обработки фрагментов, глубины и прозрачности, vx_imadd для выполнения операции "умножить и сложить", vx_wspawn, vx_tmc и vx_bar для активации фронтов инструкций и потоков в них (wavefront, набор нитей, параллельно выполняемых SIMD Engine), vx_split и vx_join.
Поддержка промежуточного представления шейдеров SPIR-V реализована через трансляцию в OpenCL.
Для разработки приложений предлагается инструментарий, включающий адаптированные для работы с Vortex варианты PoCL (компилятор и runtime OpenCL), LLVM/Clang, GCC и Binutils.
Поддерживается симуляция работы чипа с использованием Verilator (Verilog-симулятор), RTLSIM (симуляция RTL) и SimX (программная симуляция).
Для графики на технологиях Vortex развивается открытый GPU Skybox, поддерживающий графический API Vulkan. Прототип Skybox, созданный на базе FPGA Altera Stratix 10 и включающий 32 ядра (512 потоков), позволил при частоте 230 MHz добиться производительности заливки в
3.7 гигапикселей в секунду (29.4 гигатранзакции в секунду). Отмечается, что это первый открытый GPU с программной и аппаратной реализацией, поддерживающий Vulkan.
Среди изменений в версии Vortex 2.1:
Добавлен API spawn_taskgroups для запуска ядер, использующих локальную память и поддерживающих выставление барьеров на память.
Предложено новое расширение для создания перемещаемых (relocatable) бинарных ядер.
В API управления памятью добавлены вызовы vx_mem_reserve, vx_mem_access и vx_mem_address.
Добавлен новый runtime API vx_check_occupancy.
В драйвер для GPU добавлена опция для проверки OpenCL-тестов на локальном GPU.
Добавлены тесты OpenCL, использующие локальную память (psum, sgemm2, sgemm3).
Добавлены специально адаптированные для Vortex редакции библиотек libc и librt.
Добавлена поддержка слияния соседних свободных блоков памяти (memory coalescing).
Проведена оптимизация микроархитектуры.
Добавлен новый сборочный скрипт, отделяющий исходные файлы от сборочного каталога.
Компания Google продемонстрировала партнёрам на закрытом мероприятии проект FerroChrome, в рамках которого подготовлена специальная сборка операционной системы Chromium OS, предназначенная для запуска в виртуальной машине на устройствах с платформой Android. При демонстрации интерфейс Chromium OS выводился на большой экран, подключённый к смартфону Pixel 8. Предполагается, что возможность запуска Chromium OS может применяться для создания полнофункционального рабочего окружения, которое можно использовать при подключении смартфона к монитору, клавиатуре и мыши.
Начиная с Android 13 в платформу добавлен Android Virtualization Framework (AVF), реализованный на базе гипервизора KVM и инструментария crosvm, и позволяющий запускать виртуальные машины с другими операционными системами. До сих пор Google использовал AVF для выполнения сборок "microdroid", применяемых для изоляции сторонних системных компонентов. В конце апреля в AVF была документирована возможность запуска операционных систем с графическим интерфейсом пользователя и объявлено о поддержке создания гостевых систем с Chromium OS.
Сборка FerroChrome пока не распространяется публично, но компания Google опубликовала инструкцию по сборке гостевой системы с Chromium OS и её запуску в виртуальной машине AVF. Воспользовавшись данной инструкцией энтузиастам удалось воспроизвести запуск Chromium OS на смартфоне Pixel 7 Pro c подключёнными клавиатурой и мышью.
В контекстное меню добавлена операция "Copy Link Without Site Tracking", позволяющая скопировать URL выбранной ссылки в буфер обмена, предварительно вырезав из него параметры запроса, которые используются для отслеживания переходов между сайтами. Например, при копировании ссылки будут удалены параметры mc_eid и fbclid, применяемые при переходе со страниц Facebook. Всего осуществляется вырезание более 300 параметров, применяемых для отслеживания, среди которых параметры, используемые в крупнейших интернет-магазинах.
Добавлена поддержка кодирования контента при помощи алгоритма сжатия Zstandard (zstd), помимо ранее поддерживаемых алгоритмов gzip, brotli и deflate. При отправке запросов Firefox теперь выставляет в HTTP-заголовке "Accept-encoding" значение "gzip, deflate, br, zstd". Из крупных сайтов, поддерживающих отдачу сжатых данных в формате zstd, отмечается Facebook.
Добавлена экспериментальная возможность автоматизированного машинного перевода фрагментов текста, выделенных на странице (ранее поддерживался только перевод страницы целиком). Функция перевода вызывается через контекстное меню, показываемое при нажатии правой кнопки мыши на выделенном блоке текста. Для активации перевода фрагментов в about:config добавлена настройка browser.translations.select.enable.
Реализован, но пока не включён по умолчанию новый упрощённый и унифицированный диалог для очистки данных пользователя, в котором улучшено разделение данных на категории и добавлены сведения о размере данных, сохранённых за выбранный промежуток времени. Для включения в about:config слудует выставить параметр privacy.sanitize.useOldClearHistoryDialog в значение false.
В панель персонализации страницы, показываемой при открытии новой вкладки, добавлена секция для выбора фоновых изображений. Для включения необходимо активировать настройку browser.newtabpage.activity-stream.newtabWallpapers.enabled на странице about:config.
Добавлена начальная реализация механизма Text Fragments, позволяющего создавать ссылки на определённые отрывки текста на странице, например, при переходе по ссылке "https://opennet.me#:~:text=OpenSSL" браузер прокрутит страницу на позицию со словом OpenSSL и выделит его цветом.
Реализована передача дополнительной телеметрии с агрегированными счётчиками поисковых запросов разных категорий. Категории охватываются 20 обобщённых типов контента, например, спорт, бизнес и путешествия. Утверждается, что собираемая информация необходима для разработки новых возможностей поиска. Данные сохраняются без привязки к отдельным пользователям. Для удаления информации об IP-адресе пользователя применяется технология OHTTP (Oblivious-HTTP), обеспечивающая перенаправление зашифрованных HTTP-сообщений через дополнительные промежуточные узлы, так что конечный сервер получает запрос не от IP пользователя, а от IP транзитного узла.
Временно отключена добавленная в Firefox 125 возможность быстрого перехода по ссылке, сохранённой в буфере обмена (если во время нажатия на адресную строку в буфере обмена находится URL, автоматически данный URL показывался в качестве начальной рекомендации для перехода). В качестве причины отключения упоминаются проблемы с производительностью.
В сборках для macOS на компьютерах Mac с CPU M3 включено аппаратное ускорение декодирования видео в формате AV1.
Добавлен метод URL.parse(), возвращающий объект URL, представляющий ссылку, указанную в параметрах. В отличие от конструктора URL() новый метод в случае проблем с разбором возвращает null, вместо генерации исключения.
Включена поддержка CSS-свойства zoom, позволяющего уменьшать или увеличивать масштаб отдельных элементов. Для определения применённого к элементу уровня масштаба предложено свойство Element.currentCSSZoom, доступное только для чтения.
Добавлена возможность отражения состояния собственных HTML-элементов (custom element) в CSS через псевдо-класс ":state()". Функциональность реализована по аналогии с возможностью штатных HTML-элементов менять своё состояние в зависимости от взаимодействия с пользователем.
Добавлена поддержка API Screen Wake Lock, позволяющего web-приложению, например, мультимедийному проигрывателю, блокировать вызов хранителя экрана после длительной неактивности пользователя.
В API IndexedDB добавлен метод IDBFactory.databases() для перебора имеющихся БД (возвращает массив объектов, содержащих имя и версию доступных БД).
В API Selection добавлена экспериментальная поддержка выделения, пересекающего границы теневого DOM.
Включается через dom.shadowdom.selection_across_boundary.enabled в about:config.
В CSS добавлена экспериментальная функция shape(), позволяющаяформировать фигуры с использованием CSS-свойств clip-path и offset-path. Включается через layout.css.basic-shape-shape.enabled в about:config.
Реализовано CSS-правило "@starting-style" для применения стиля при создании entry-анимации на стадии до открытия элемента на странице (в состоянии "display: none").
В API Fetch Request добавлена поддержка keepalive.
Работа редактора стилей в инструментах web-разработчиков ускорена на 15-20%.
В инструментах для web-разработчиков добавлена настройка "Show split console" для включения/выключения режима, отображающего web-консоль одновременно с другими панелями.
В версии для Android решены проблемы с отображением панели с адресной строкой на устройствах со складными экранами. Для унификации с настольной версией настройки "Add-ons" переименованы в "Extensions".
Кроме новшеств и исправления ошибок в Firefox 126 устранена 21 уязвимость. Две уязвимости помечены как опасные. Первая опасная уязвимость (CVE-2024-4764) приводит к обращению к уже освобождённой области памяти при обработке нескольких WebRTC-потоков со звуком. Вторая опасная уязвимость (CVE-2024-4367) позволяет добиться выполнения JavaScript-кода при обработке во встроенном PDF-просмотрщике специально оформленных шрифтов. Ещё 9 уязвимостей вызваны проблемами работы с памятью, такими как переполнения буферов и обращение к уже освобождённым областям памяти. Потенциально данные проблемы способны привести к выполнению кода злоумышленника при открытии специально оформленных страниц.
Опубликован 63-й выпуск рейтинга 500 самых высокопроизводительных компьютеров мира. В 63 редакции рейтинга кластеры, занимавшие в прошлом рейтинге первые пять мест, сохранили свои позиции:
Первое место занимает кластер Frontier, размещённый в Ок-Риджской национальной лаборатории Министерства энергетики США. Кластер насчитывает 8.7 миллиона процессорных ядер (CPU AMD EPYC 64C 2GHz, ускоритель AMD Instinct MI250X) и обеспечивает производительность 1.206 экзафлопса. В качестве операционной системы применяется HPE Cray OS (редакция SUSE Linux Enterprise Server 15).
Второе место занимает кластер Aurora, развёрнутый в Аргоннской национальной лаборатории Министерства энергетики США. По сравнению с прошлой редакцией рейтига кластер нарастил число процессорных ядер (CPU Xeon CPU Max 9470 52C 2.4GHz, ускоритель Intel Data Center GPU Max) с 4.8 до 9.2 млн. Производительность при этом выросла с 585 петафлопс до 1.012 экзафлопса. В качестве операционной системы в Aurora используется SUSE Linux Enterprise Server 15 SP4.
Третье место в рейтинге занимает кластер Eagle запущенный в этом году компанией Microsoft для облака Azure. Кластер содержит 2 млн процессорных ядер (CPU Xeon Platinum 8480C 48C 2GHz) и демонстрирует пиковую производительность в 561 петафлопс. Программное обеспечение кластера базируется на Ubuntu 22.04.
На четвёртом месте находится кластер Fugaku, размещённый в Институте физико-химических исследований RIKEN (Япония). Кластер построен с использованием процессоров ARM (158976 узлов на базе SoC Fujitsu A64FX, оснащённых 48-ядерным CPU Armv8.2-A SVE 2.2GHz). Fugaku обеспечивает производительность 442 петафлопса и работает под управлением Red Hat Enterprise Linux.
Пятое место занимает кластер LUMI, размещённый в Европейском суперкомпьютерном центре (EuroHPC) в Финляндии и обеспечивающий производительность 379 петафлопс. Кластер построен на той же платформе HPE Cray EX235a, что и лидер рейтинга, но включает 2.2 млн процессорных ядер (AMD EPYC 64C 2GHz, ускоритель AMD Instinct MI250X, сеть Slingshot-11). В качестве операционной системы применяется HPE Cray OS.
Шестое место занял новый кластер Alps, запущенный в Швейцарском национальном суперкомпьютерном центре. Кластер насчитывает 1305600 процессорных ядер NVIDIA Grace 72C 3.1GHz и обеспечивает производительность 270 петафлопсов.
Что касается отечественных суперкомпьютеров, то созданные компанией Яндекс кластеры Червоненкис, Галушкин и Ляпунов опустились с 36, 58 и 64 мест на 42, 69 и 79 места. Данные кластеры созданы для решения задач машинного обучения и обеспечивают производительность 21.5, 16 и 12.8 петафлопса соответственно. Кластеры работают под управлением Ubuntu 16.04 и оснащены процессорами AMD EPYC 7xxx и GPU NVIDIA A100: кластер Chervonenkis насчитывает 199 узлов (193 тысячи ядер AMD EPYC 7702 64C 2GH и 1592 GPU NVIDIA A100 80G), Galushkin - 136 узлов (134 тысячи ядер AMD EPYC 7702 64C 2GH и 1088 GPU NVIDIA A100 80G), Lyapunov - 137 узлов (130 тысяч ядер AMD EPYC 7662 64C 2GHz и 1096 GPU NVIDIA A100 40G).
Развёрнутый Сбербанком кластер Christofari Neo опустился с 67 на 83 место. Christofari Neo работает под управлением NVIDIA DGX OS 5 (редакция Ubuntu) и демонстрирует производительность 11.95 петафлопса. Кластер насчитывает более 98 тысяч вычислительных ядер на базе CPU AMD EPYC 7742 64C 2.25GHz и поставляется с GPU NVIDIA A100 80GB. Второй кластер Сбербанка (Christofari) за полгода сместился с 119 на 142 место в рейтинге.
В рейтинге также остаются ещё два отечественных кластера: Lomonosov 2 - сместился с 370 на 406 место (в 2015 году кластер Lomonosov 2 занимал 31 место, а его предшественник Lomonosov в 2011 году - 13 место) и MTS GROM - сместился с 433 на 472 место. Таким образом, число отечественных кластеров в рейтинге не изменилось и, как шесть месяцев назад, составляет 7 систем (для сравнения в 2020 году в рейтинге было 2 отечественные системы, в 2017 году - 5, а в 2012 году - 12).
Наиболее интересные тенденции:
Распределение по количеству суперкомпьютеров в разных странах:
США: 171 (161 - полгода назад). Суммарная производительность оценивается в 34.2% всей производительности рейтинга (полгода назад - 32.8%);
Китай: 80 (104). В сумме китайские кластеры генерируют 16% от всей производительности (полгода назад - 20.8%);
В рейтинге операционных систем, используемых в суперкомпьютерах, c ноября 2017 года остаётся только Linux;
Распределение по дистрибутивам Linux (в скобках - 6 месяцев назад):
42.4% (44.6%) используют системы на базе Linux, но не детализируют дистрибутив;
16.8% (12.6%) - RHEL;
9.4% (11%) CentOS;
9.2% (9.6%) - Cray Linux;
8.4% (7.8%) - Ubuntu;
4.4% (4.4%) - SUSE;
3% (2%) - Rocky Linux;
1.2% (1%) - Alma Linux;
0.2% (0.2%) - Amazon Linux;
0.2% (0.2%) - Scientific Linux.
Минимальный порог производительности для вхождения в Top500 за 6 месяцев составил 2.13 петафлопса (полгода назад - 2.02 петафлопса). Шесть лет назад лишь 272 кластера показывали производительность более петафлопса, семь лет назад - 138). Для Top100 порог вхождения вырос с 7.89 до 9.46 петафлопса, а для Top10 - с 94.64 до 121.4 петафлопса.
Суммарная производительность всех систем в рейтинге за 6 месяцев возросла с 7 до 8.2 экзафлопсов (четыре года назад было 1.650 экзафлопса, а шесть лет назад - 749 петафлопсов). Система, замыкающая нынешний рейтинг, в прошлом выпуске находилась на 457 месте.
Общее распределение по количеству суперкомпьютеров в разных частях света выглядит следующим образом:
181 суперкомпьютер находится в Северной Америке (171 - полгода назад), 157 в Европе (143), 147 в Азии (169), 9 в Южной Америке (10), 5 в Океании (6) и 1 в Африке (1).
В качестве процессорной основы лидируют CPU Intel - 62.8% (полгода назад было 67.9%), на втором месте AMD 31.4% (28%), на третьем IBM Power - 1.2% (было 1.4%).
17.8% (полгода назад 21.4%) всех используемых процессоров имеют 24 ядра, 22% (21%) - 64 ядра, 9% (10.6%) - 20 ядер, 9.4% (7.4%) - 32 ядра, 5.4% (6.2%) - 16 ядер, 5.6% (6%) - 18 ядер, 5.2% (5.2%) - 28 ядер, 5.8% (5%) - 48 ядер, 4.4% - 56 ядер, 2.2% (3%) - 12 ядер. Суммарное число процессорных ядер во всех кластерах рейтинга за полгода увеличилось с 106.3 млн до 114.6 млн.
196 из 500 систем (полгода назад - 185) дополнительно используют ускорители или сопроцессоры, при этом в 142 (155) системах задействованы чипы NVIDIA, в 14 (25) - AMD, в 1 (2) - Intel Xeon Phi, в 4 - Intel DataCenter GPU, в 1 (1) - Matrix-2000.
Среди производителей кластеров на первом месте закрепилась компания Lenovo - 32.6% (полгода назад 33.8%), на втором месте компания Hewlett-Packard Enterprise - 22.4% (20.6%), на третьем месте компания EVIDEN - 9.8% (9.6%), далее следуют Dell EMC 6.8% (6.4%), Inspur - 4.4% (6.8%), NVIDIA 4.4% (3.6%), NEC 2.8% (2.4%), Fujitsu 2.8% (2.4%), MEGWARE 1.4% (1.4%), Microsoft Azure - 1.4% (1.2%), Penguin Computing - 1.4% (1.2%), Sugon 1% (1.8%), IBM 1% (1.2%), Huawei 0.4% (0.4%), Intel 0.4%.
InfiniBand применяется для связи узлов в 47.8% (полгода назад 43.8%) кластеров, Ethernet используется в 39% (41.8%) кластеров, Omnipath - 6.4% (6.6%). Если рассматривать суммарную производительность, то системы на базе InfiniBand охватывают 39.2% (41.4%) всей производительности Top500, а Ethernet - 48.5% (44%).
В ближайшее время ожидается публикация нового выпуска альтернативного рейтинга кластерных систем Graph 500, ориентированного на оценку производительности суперкомпьютерных платформ, связанных с симулированием физических процессов и задач по обработке больших массивов данных, свойственных для таких систем. Рейтинги Green500, HPCG (High-Performance Conjugate Gradient) и HPL-AI объединены с Top500 и отражаются в основном рейтинге Top500.
Энди Ритгер (Andy Ritger), возглавляющий разработку драйверов для Unix-подобных ОС в компании NVIDIA, ответил на вопросы, заданные в связи с переводом проприетарных драйверов NVIDIA на использование по умолчанию открытых модулей ядра Linux на системах с GPU на базе микроархитектур, начиная с Turing.
На вопрос о достижении паритета в функциональности открытых и проприетарных драйверов представитель NVIDIA ответил, что в выпуске драйверов 560 открытые модули ядра будут примерно соответствовать по функциональности проприетарным модулям. Из ограничений отмечается невозможность использования механизма динамического управления энергопотреблением RTD3 (Run Time D3) с открытыми модулями ядра на старых поколениях GPU, предшествующих Ampere (в проприетарных модулях дополнительно поддерживаются GPU на микроархитектуре Turing).
Возможности открытых и проприетарных модулей, связанные с инициализацией GPU и управлением энергопотреблением, будут достаточно близки в драйверах NVIDIA 560, и со временем работа по достижению полного паритета в этом направлению будет продолжаться. В выпуске 560 в открытых модулях также будут решены некоторые давние проблемы, например, связанные с использованием VRR (Variable Refresh Rate) на ноутбуках.
NVIDIA не планирует добиваться включения открытых модулей в основной состав ядра Linux.
На вопрос о поддержке открытых драйверов Nouveau и NVK представитель NVIDIA ответил, что для рабочего применения компания рекомендует использовать проприетарные драйверы и отдельно поставляемые открытые модули ядра. Компания ранее предпринимала попытки предоставления разработчикам nouveau и nvk документации на чипы и аппаратные интерфейсы NVIDIA и передавала отдельные патчи, но предоставленная помощь достаточно скромна, чтобы называть её поддержкой.
На вопрос о возможности поддержки в открытом драйвере Nouveau закрытых компонентов NVIDIA, работающих в пространстве пользователя, таких как CUDA, AI, RT/PT, DLSS и Optix, указано, что пока такой возможности нет и данные компоненты не могут работать при использовании модуля ядра nouveau. Будет ли это возможно в будущем пока не ясно.
Отмечено, что с nouveau также пока невозможно использовать возможности, связанные с настройкой и мониторингом (nvapi/nvidia-smi). При этом осуществлённая в прошлом смена лицензии на определения API nvapi позволила проектам wine и proton подготовить собственные реализации некоторых элементов nvapi, используемых в играх.
На вопрос об участии сотрудников NVIDIA в разработке nouveau, указано, что подобное участие пока незначительно, но некоторые работники уже вносят свой вклад в разработку Nouveau и участвуют в обсуждениях.
NVIDIA не собирается предоставлять открытые модули ядра для старых GPU, предшествующих поколению Turing. Пользователям Volta и более старых GPU следует продолжать использовать проприетарные модули.
На вопрос о планах компании по открытию компонентов стека драйверов для GPU, работающего в пространстве пользователя, отвечавший на вопрос сотрудник NVIDIA заявил, что не слышал о подобных планах.
Решение по использованию открытых модулей по умолчанию объясняется желанием упростить тестирование и снизить издержки, возникающие из-за необходимости повторного тестирования открытых и закрытых модулей.
Мэйнтейнер, обеспечивающий сборку для Debian пакетов с менеджерами паролей KeePassXC, перешёл на поставку максимально урезанной версии программы, в которой оставлена только базовая функциональность, необходимая для безопасного хранения паролей на локальной системе. Расширенные функции, среди которых возможность сетевого взаимодействия, код для управления через IPC, компоненты для интеграции с web-браузерами, функции авто-ввода паролей и код для поддержки ключей Yubikey, удалены из стандартного пакета keepassxc, что объясняется избавлением от излишней функциональности, которая увеличивает поверхность атаки и потенциально может негативно влиять на безопасность и конфиденциальность.
Для пользователей, которым необходима полная версия KeePassXC, предложен отдельный пакет keepassxc-full, включающий все предлагаемые в исходной версии расширенные возможности. Урезанный пакет размещён в репозиториях Debian sid (unstable) и testing вместо старого полного пакета с тем же именем, что вызваловозмущение некоторых пользователей, которые после обновления столкнулись с отсутствием привычной функциональности и восприняли изменение как сбой. Недовольные изменением предлагают мэйнтейнеру KeePassXC в Debian вернуть исходный вариант пакета, а урезанную версию разместить под именем keepassxc-minimal.
С критикой принятого решения также выступил разработчик KeePassXC, который отметил, что пользователи связывают пропадание функциональности с основным проектом и обращаются с жалобами к разработчикам KeePassXC, а не к мейнтейнеру пакета в Debian. Изменение может негативно сказаться на репутации KeePassXC и привести к лишней нагрузке на участников проекта. Кроме того, поднят вопрос о том, насколько правомерно распространять пакет с сохранением названия проекта, но с кардинальным отличием функциональности от базовой сборки, предоставляемой основными разработчиками.
В обсуждении сторонники изменения указывают на то, что каждый включённый плагин потенциально приводит к дополнительному риску наличия уязвимостей или внедрения бэкдора. Кроме того, отмечается, что урезанный пакет размещён только в репозиториях unstable и testing, предназначенных для тестирования, а не в стабильных релизах дистрибутива.
Разработчики KeePassXC пояснили, что применение термина плагины к удалённым дополнительным возможностям некорректно, так как это встроенная функциональность, которая по умолчанию отключена, но может быть активирована в настройках пользователем. Упоминание избавления от внешних библиотек так же отмечаются как беспочвенное, так как код для поддержки Yubikey больше не завязан на внешней библиотеке libyubikey и все необходимые для его работы компоненты поставляются в основной кодовой базе KeePassXC.
После двух месяцев разработки Линус Торвальдс представил релиз ядра 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). Добавлены оптимизации для ускорения операций журналирования. Примерно на 6% повышена пропускная способность за счёт сокращения конкуренции блокировок. Исключено выполнение полного повторного сканирования квот, излишнего в некоторых ситуациях.
В exFAT значительно повышена производительность при монтировании с опцией "dirsync", при которой выполнение всех операций обновления каталогов осуществляется только в синхронном режиме.
В F2FS улучшена поддержка зонированных блочных устройств и добавлена возможность использования флагов SEEK_DATA и SEEK_HOLE для сжатых файлов.
В Bcachefs добавлена btree-структура с информацией о дочерних элементах подразделов, которая в будущем будет задействована в API для обхода подразделов. Улучшена проверка структуры каталогов. Улучшен процесс журналирования и повышена производительность при высокой нагрузке на запись. Увеличена эффективность операций Discard.
В файловой системе 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-флудом.
В системе управления памятью реализованаподдержка паралелльной инициализации больших страниц памяти (HugeTLB), которая позволила заметно ускорить процесс загрузки на системах с очень большим объёмом ОЗУ. Например, на системе с 12 ТБ ОЗУ инициализация HugeTLB размером 1GB сократилась с 77 до 18 секунд.
Продолжен перенос изменений из ветки 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(), обеспечивающего установку барьеров на память для работающих в системе потоков. Добавлены реализации алгоритмов AES-ECB, AES-CBC, AES-CTR, AES-XTS, ChaCha20, GHASH, SHA-256, SHA-384, SHA-512, SM3 и SM4, ускоренные при помощи векторных инструкций RISC-V.
В драйвер amd-pstate, применяемый для управления энергопотреблением на системах с процессорами AMD, добавлена возможность использования информации о приоритетных ядрах CPU (Preferred Core), на которых допускается выставление более высокой частоты, для их первоочередного выбора в планировщике для выполнения приоритетных задач.
Максимальный размер шрифтов, которые допускается использовать в консоли fbcon увеличен до 64x128, что позволяет сформировать комфортное отображение текста на экранах 4k.
Добавлена настройка USB_DEFAULT_AUTHORIZATION_MODE, позволяющая изменить применяемый по умолчанию режим авторизации, используемый при подключении USB-устройств и определяющий будет ли система сразу использовать подключённое устройство: 0 - требуется активация из пространства пользователя, 1 (по умолчанию) - все устройства можно использовать сразу и 2 - активация не требуется для внутренних устройств.
Подняты требования к версии 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 для сокетов MPTCP добавлена поддержка индентификаторов сети ("network ID"), дающих возможность использовать на одном хосте несколько непересекающихся сетей MPTCP.
В 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 (по умолчанию FreeSync для видео на уровне драйвера теперь отключён, так как KDE и GNOME реализовали собственные методы адаптивной синхронизации частоты кадров).
В драйвере Nouveau код управления экраном переведён на использование функции kmemdup().
Продолженаработа над drm-драйвером (Direct Rendering Manager)
Xe для GPU на базе архитектуры Intel Xe, которая используется в видеокартах Intel семейства Arc и интегрированной графике, начиная с процессоров Tiger Lake.
Добавлен DRM-драйвер для чипов Mediatek MT8188 VDOSYS1.
Связанные с видеоподсистемами настройки ядра перенесены в секцию CONFIG_VIDEO.
В драйвер xpad добавлена поддержка геймпадов Snakebyte и ASUS ROG RAIKIRI. В подсистему HID (Human Interface Device) добавлена поддержка
клавиатур, мышей и геймпадов от компании Samsung, использующих Bluetooth.
Rockchip - Pine64 PineTab2, QNAP TS433 NAS, игровые консоли Powkiddy RGB10MAX3, Anbernic RG-ARC S и RG-ARC D, платы Toybrick TB-RK3588X и Theobroma Systems RK3588-Q7.
Allwinner - Sipeed Longan Pi 3H (Allwinner H618), Remix Mini PC (Allwinner H64).
Qualcomm - Samsung Galaxy Tab 4 10.1 LTE (SM8550, Snapdragon 8 Gen 2), Samsung Galaxy Core Prime, Samsung Galaxy Grand Prime (MSM8916).
Amlogic - Freebox Pop Player (IPTV).
Mediatek - Banana Pi BPI-R4, Xiaomi AX3000T, Radxa NIO 12L, Acelink EW-7886CAX, пять моделей Chromebook.
NVIDIA - два Android-смартфона на чипе Tegra30.
Renesas - плата White Hawk.
Добавлена поддержка SoC Mobileye на базе процессоров MIPS.
Проведён рефакторинг кода звуковой подсистемы ALSA. Добавлена поддержка звуковых систем Microchip SAM9x7, NXP i.MX95, Rockchip RK3308 и 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, приводившие к зависанию во время инициализации. Внесены изменения, связанные с обработкой блобов, поставляемых в виде шестнадцатеричных дампов.
Компания NVIDIA объявила, что в грядущем выпуске проприетарных драйверов NVIDIA 560 на системах с GPU на базе Turing (GeForce GTX 1600 и RTX 2000) и более новых микроархитектур по умолчанию будут задействованы открытые модули ядра Linux. Код модулей был открыт в 2022 году под лицензиями MIT и GPLv2, и обновляется синхронно с каждым новым выпуском проприетарных драйверов. При этом, несмотря на наличие открытых модулей при установке проприетарных драйверов NVIDIA до сих пор продолжали использоваться проприетарные варианты модулей, основанные на общей кодовой базе с открытыми, но отличающиеся и развивающиеся отдельно.
Открытые и проприетарные модули не могли использоваться одновременно и не могли быть вместе установлены в файловую систему. Открытые модули могут использоваться только с GPU, оснащёнными отдельным микроконтроллером GSP (GPU System Processor), применяемым в таких микроархитектурах, как Turing, Ampere и Ada. В проприетарных модулях, помимо новых GPU, продолжает сохраняться и поддержка старых GPU, не оснащённых GSP, например, GPU на базе микроархитектур Maxwell, Pascal и Volta.
Начиная с выпуска NVIDIA 560 ситуация изменится - для обычных GPU начиная с Turing, а при виртуализации GPU, начиная с Ada, по умолчанию начнут устанавливаться открытые варианты модулей ядра nvidia.ko, nvidia-modeset.ko, nvidia-uvm.ko, nvidia-drm.ko и nvidia-peermem.ko, в ситуациях когда их применение возможно. При желании установить в систему проприетарные модули ядра потребуется указание опции "--kernel-module-type=proprietary" при запуске run-архива с драйверами NVIDIA. В будущем компания NVIDIA планирует прекратить реализацию поддержки новых GPU в проприетарных модулях и сосредоточиться только на развитии открытых.
