В осеннем релизе Ubuntu 26.10 планируется сразу два заметных шага: переход на новый сервер точного времени ntpd-rs и серьёзное сокращение поддерживаемых технологий в разделе /boot, включая отказ от Btrfs, XFS, ZFS, LVM и LUKS.
Руководитель инженерного направления Canonical и технический лидер Ubuntu Джон Сигер объявил, что в состав Ubuntu 26.10 будет добавлен NTP-сервер ntpd-rs, написанный на Rust и уже используемый в инфраструктуре удостоверяющего центра Let's Encrypt. Это станет третьим крупным системным компонентом на Rust в Ubuntu после Rust Coreutils и sudo-rs. Все они входят в более широкую инициативу по замене ключевых элементов пользовательского пространства программами, изначально спроектированными с прицелом на безопасность, надёжность и формальную корректность.
Параллельно обсуждаются и другие возможные замены классических библиотек и утилит: рассматривается переход с zlib на zlib-rs и использование криптопакета Sequoia вместо GnuPG в составе APT. Если эти планы будут реализованы, Ubuntu ещё теснее свяжет свою базовую инфраструктуру с экосистемой Rust.
ntpd-rs предполагается использовать по умолчанию как универсальный сервер и клиент синхронизации времени, который в перспективе должен вытеснить ныне применяемые chrony, linuxptp и, возможно, gpsd. На первом этапе в Ubuntu 26.10 пакет появится в репозиториях как экспериментальная опция: его можно будет установить и протестировать вместо стандартных решений. В следующем релизе, Ubuntu 27.04, ntpd-rs планируют сделать базовым компонентом системы синхронизации времени с поддержкой протоколов NTP, NTS и PTP.
Разработкой ntpd-rs занимается организация Trifecta Tech Foundation - та же команда, которая стоит за sudo-rs, уже интегрированным в Ubuntu. Canonical намерена финансировать дальнейшее развитие ntpd-rs, в том числе расширение функциональности и усиление механизмов защиты. Один из ключевых пунктов дорожной карты - интеграция наработок проекта Statime, реализующего Precision Time Protocol (PTP) на языке Rust. Объединение этих технологий в одном пакете позволит не только заменить chrony, но и взять на себя роль linuxptp, предложив единый инструмент для работы с современными протоколами точной синхронизации времени.
До включения ntpd-rs по умолчанию разработчики планируют реализовать ряд дополнительных возможностей. Среди них: поддержка протоколов gPTP и CSPTP, работа через IP-сокет gpsd, многопоточный режим для NTP-серверов, полноценная работа в конфигурациях multi-homed (несколько сетевых интерфейсов), создание профилей изоляции на базе AppArmor и seccomp. Также запланированы инструменты для тестирования и измерения производительности, улучшения в подсистеме логирования и конфигурации, а также развитие утилиты командной строки ntp-cli.
Инвестиции Canonical в Rust не ограничиваются совместными проектами с Trifecta Tech Foundation. Компания вошла в число "золотых" участников Rust Foundation - организации, занимающейся развитием языка Rust и поддержкой связанной с ним экосистемы. Canonical стала единственным участником этого уровня; над ней находятся шесть платиновых спонсоров, обеспечивающих основную часть финансирования развития Rust: Google, Microsoft, Amazon, ARM, Meta и Huawei. Ежегодный взнос "золотого" участника составляет 150 тысяч долларов, "платинового" - 325 тысяч.
На уровне загрузочной инфраструктуры Canonical планирует ещё один заметный пересмотр: сокращение функциональности GRUB в целях уменьшения поверхности атаки. Об этом сообщил сопровождающий проект APT в Canonical Джулиан Андрес Клоде. В Ubuntu 26.10 предложено убрать из подписанных и используемых в режиме безопасной загрузки сборок GRUB поддержку некоторых форматов и файловых систем.
В частности, планируется отключить в заверенных бинарях GRUB поддержку отображения изображений в форматах JPEG и PNG, обработку таблиц разделов Apple (part_apple), а также работу с файловыми системами btrfs, hfsplus, xfs и zfs при использовании их для раздела /boot. Кроме того, будет убрана поддержка размещения /boot на разделах LVM, на md-raid-массивах (за исключением raid1) и на зашифрованных разделах LUKS.
Ключевой аргумент Canonical - практика и опыт реального использования. В штатном инсталляторе Ubuntu для раздела /boot всегда создаётся файловая система ext4. Другие конфигурации, вроде Btrfs или XFS в /boot, официально не тестируются и фактически воспринимаются разработчиками как потенциальный источник уязвимостей, особенно в условиях периодически выявляемых проблем безопасности в самом GRUB. Сокращая число модулей и парсеров, включённых в подписанную сборку загрузчика, Canonical пытается минимизировать возможности обхода режима проверенной загрузки.
Отдельно подчёркивается позиция по поводу шифрования /boot. Поддержка LUKS для этого раздела рассматривается как малоэффективная мера, дающая лишь иллюзию защиты за счёт сокрытия данных. В модели безопасности акцент смещён на гарантии целостности содержимого /boot, а не на его секретность. Эту задачу Canonical предлагает решать за счёт механизмов, связанных с TPM и полным шифрованием диска (TPM FDE), а не через шифрование самого загрузочного раздела. При этом на остальных разделах системы, за пределами /boot, использование LUKS, LVM и MD-RAID по-прежнему будет доступно и поддерживаемо.
Важно, что заявленные ограничения касаются в первую очередь конфигураций с UEFI Secure Boot и подписью загрузчика. Если система не использует безопасную загрузку, более гибкие варианты разметки и файловых систем для загрузочного раздела по-прежнему возможны, хотя и лягут полностью на ответственность администратора.
Что это значит для администраторов и опытных пользователей
Для большинства типичных установок Ubuntu заметных изменений не произойдёт: инсталлятор как и раньше создаёт /boot на ext4, без сложных схем с LVM или отдельными RAID-массивами. Ограничения коснутся прежде всего продвинутых конфигураций, где /boot использовался на нестандартных файловых системах либо размещался внутри LVM, на многодисковых массивах или в зашифрованном виде.
Если у вас сейчас /boot расположен на Btrfs, XFS, ZFS, внутри LVM или на LUKS, и вы при этом применяете UEFI Secure Boot, в перспективе обновления до Ubuntu 26.10-27.04 могут потребовать миграции на более простую схему: отдельный нешифрованный ext4-раздел для /boot, а уже ниже по стеку - шифрование и LVM/RAID для остальных данных. Такой подход упрощает доверенную цепочку загрузки: /boot становится минимальным, предсказуемым и протестированным элементом, поверх которого и строится остальная архитектура безопасности.
Как быть тем, кто использует /boot для нестандартных сценариев
Некоторые пользователи традиционно держат в /boot дополнительные образы - например, "живую" систему для аварийной загрузки без необходимости искать флешку. Жёсткие ограничения на файловые системы и шифрование могут показаться шагом назад для такой аудитории.
Однако в предлагаемой модели /boot должен оставаться максимально простым и прозрачным, чтобы его содержимое было легко проверяемо и контролируемо через Secure Boot и TPM. Это означает, что сложные сценарии (например, хранение объёмных ISO-образов или дополнительных систем) логичнее перенести на другие разделы или отдельные носители. Для аварийного восстановления можно использовать:
- отдельный раздел или диск с Live-системой, загружаемой напрямую через UEFI;
- внешние носители (SSD, USB), настроенные как постоянные "спасательные" среды;
- сетевую загрузку (PXE), если инфраструктура это позволяет.
При этом ничто не мешает по-прежнему держать в /boot дополнительные ядра и initrd, если они соответствуют ожидаемой схеме и не нарушают модель безопасности. Ограничения больше касаются того, на каких технологиях основан сам раздел /boot, а не набора загружаемых конфигураций внутрь него.
Почему Canonical делает ставку на упрощение /boot
С точки зрения безопасности /boot - критическая точка входа. Любая дополнительная функциональность загрузчика - это новые парсеры, обработчики форматов, поддержка нестандартных файловых систем и схем разметки. Каждый такой модуль в GRUB - потенциальная поверхность атаки. Когда загрузчик подписан и участвует в цепочке доверия UEFI Secure Boot, любая уязвимость в нём может быть использована для обхода защиты всей системы.
Убирая поддержку редко используемых комбинаций (Btrfs/XFS/ZFS в /boot, LVM/md-raid/LUKS под /boot, экзотические таблицы разделов и графические форматы), Canonical жертвует гибкостью ради уменьшения возможных векторов атак. На практике это приводит к унификации: все официально поддерживаемые установки будут иметь одни и те же, хорошо протестированные параметры загрузочного раздела. Это облегчает как аудит, так и реагирование на потенциальные проблемы.
Баланс между "гибкостью Linux" и формальной безопасностью
Решения Canonical нередко вызывают критику со стороны части сообщества, считающей, что "классический Linux" должен оставаться максимально гибким и допускающим любые эксперименты. Переход к более жёстко определённым конфигурациям и акцент на Secure Boot, TPM и формально проверяемые компоненты на Rust воспринимается некоторыми как "сжатие" экосистемы.
Однако нужно разделять базовую поставку дистрибутива и возможности ядра и пользовательского пространства в целом. Убираются не сами технологии - LVM, LUKS, RAID, Btrfs, XFS или ZFS никуда не исчезают из Linux. Ограничивается лишь их роль в самом нижнем, доверенном слое загрузки, где требуется максимальная предсказуемость. Во всех остальных местах системы эти технологии продолжают использоваться и будут развиваться.
Вариативность никуда не девается: всегда можно отключить Secure Boot, использовать альтернативные загрузчики или собирать собственные, неподписанные сборки GRUB с нужным комплектом модулей. Но по умолчанию Canonical будет продвигать более строгую, формализованную модель безопасности, в которой минимальный /boot на ext4 и проверяемая цепочка загрузки - неотъемлемая часть дизайна.
Роль Rust в эволюции инфраструктуры Ubuntu
Параллельное расширение применения Rust в критических компонентах Ubuntu и ужесточение политики вокруг загрузчика - звенья одной цепи. Разработчики стремятся к уменьшению класса уязвимостей за счёт более безопасных языков и к снижению сложности доверенной части системы, в которую входят загрузчик, ранняя инициализация и базовые службы.
ntpd-rs, sudo-rs, будущие zlib-rs и Sequoia для APT - это попытка постепенно вытеснить части кода на C/C++, где ошибки управления памятью и сложное состояние часто приводят к уязвимостям. Упрощённый /boot и "подрезанный" GRUB - другая сторона той же стратегии: чем меньше функциональности внутри доверенной базы, тем легче её анализировать и тем меньше вероятность, что ошибка в малоиспользуемом модуле приведёт к катастрофическим последствиям.
Что ждать пользователям в ближайшие релизы
В Ubuntu 26.10 ntpd-rs появится в репозитории как альтернативный пакет для желающих протестировать новое решение для синхронизации времени. В то же время начнут действовать ограничения на использование некоторых файловых систем и технологий в /boot для режимов с UEFI Secure Boot. В Ubuntu 27.04 ntpd-rs должен стать стандартной службой времени, а новая модель /boot окончательно закрепится как норма для типичных установок.
Для рядового пользователя это выразится, прежде всего, в более строгих, но понятных вариантах разметки диска в инсталляторе, а также в потенциально более надёжной и устойчивой к атакам цепочке загрузки. Продвинутым администраторам и любителям сложных конфигураций придётся внимательнее планировать архитектуру системы: держать /boot простым и доверенным, а все эксперименты - на уровне остальных разделов, загрузчиков и сценариев, где требования Secure Boot не столь жёсткие.
В целом, Ubuntu движется в сторону более "инженерного" подхода: меньше разношёрстных вариантов в базовой поставке, больше формализованных гарантий безопасности и надёжности, больше опоры на современные инструменты разработки вроде Rust. Это может казаться ограничением свободы конфигурирования, но одновременно делает систему предсказуемее и устойчивее - особенно там, где Ubuntu используется как платформа для рабочих станций, серверов и индустриальных решений, а не как поле для бесконечных экспериментов с загрузчиком и /boot.
