Предупреждение заранее прежнее: проект находится на стадии пре-альфа, первый релиз только для VPS с KVM, а цифры измеряют код, тесты и определенные эксперименты, а не зрелость в продакшене.

Как это выглядело во времени

С предыдущего текста (31.10. в 23:00) до сегодняшнего дня (1.11. в 20:41) в репозитории 59 новых коммитов, всего 178. Все они появились в течение одного календарного дня, поэтому действует то же предупреждение, что и раньше: проект строится с Claude Code (коммиты несут Co-Authored-By: Claude), план, код, тесты и ADR создаются короткими замкнутыми циклами, а цифры ниже говорят об объеме кода и проверок, а не о том, сколько в них человеческого труда.

Цифры вычислены тем же методом, что и в прошлом тексте: все файлы .rs вне vendor/ и fuzz/, функции #[test], заголовки ## ADR- в docs/DECISIONS.md.

Работа шла параллельно в нескольких ветках, поэтому порядок коммитов не строго совпадает с порядком работы. ADR пронумерованы до 232, но в нумерации есть пропуски (часть была переименована при слиянии веток); мы считаем заголовки, а не наибольший номер. Релизы: v0.2.0 (1.11., 18:45 UTC) и v0.2.1 (1.11., 20:22 UTC), оба помечены как пре-релиз.

H6: SQLite в пользовательском режиме

Что мы планировали. SQLite это 254 268 строк C, которые разбирают базу, WAL и журнал с диска, а диск может быть подделан или изменен. До этого он работал в ядре, с правами ядра. Что мы построили (ADR-210 до ADR-212): SQLite, его части libc и куча перенесены в отдельную программу, dbworker, которая работает на EL0 (aarch64) или в ring 3 (x86_64), в собственном адресном пространстве. Ядро больше не линкует SQLite. Воркер общается с ядром через общее окно памяти и двенадцать системных вызовов, а каждая возвращаемая длина и смещение проверяется перед использованием. Ошибка в воркере (недопустимый доступ, неопределенная инструкция, превышенный временной бюджет в 30 с) завершает вызов, воркер перезапускается, и база открывается из WAL, как при загрузке; после 5 перезапусков за минуту хранилище объявляется неисправным, а не перезапускается бесконечно.

Цена, измеренная на aarch64 под HVF, на той же VM, ядро со встроенным SQLite против ядра с воркером, по шесть чередующихся запусков каждого:

Записи на диск (1 572) и сбросы (319) идентичны, как и должно быть. Не изолировано вот что: ядро по-прежнему доверяет тому, что вернет воркер, после проверки формы. Скомпрометированный воркер может лгать (например, вернуть пустой список отозванных сертификатов и тем самым «снять отзыв» с них), но не может читать память ядра, ключи TLS и ключи тикетов. KPTI нет, поэтому утечки типа Spectre/Meltdown не предотвращены, и мы ничего о них не утверждаем; ключ PAC разделяют EL0 и EL1. На x86_64 цену переключения мы на KVM не измеряли (под TCG число было бы бессмысленным), а фаззинг самого воркера и протокола не закончен. Набор тестов хранилища (79 сценариев, каждый гоняет SQLite в воркере) проходит на aarch64 HVF и x86_64 TCG, на aarch64 TCG 76 (один пропускается, потому что у TCG нет MSI-X).

H7 закрыт, но не так, как мы объявляли. Нижняя граница времени (ADR-050) и SNTP с консенсусом (T1) покрывают объем H7; NTS (RFC 8915) остается вне объема и записан как оставшийся риск, а не как то, что работает. Мы не считаем, что безопасность времени «решена», а считаем, что готова ее доказуемая часть.

Новая сетевая опция. Contabo не выдает DHCP пользовательскому ISO, поэтому VPS до сих пор требовал другой образ, чем лабораторная VM. Теперь network.mode = "auto" (ADR-214) сначала спрашивает DHCP, а если аренды нет в заданный срок (dhcp_timeout_s, по умолчанию 15 s) или он ее теряет, применяет заданный статический адрес. Проверено вручную на QEMU (с DHCP использует аренду, без сети через 5 s переходит на статический адрес); smoke-сценария для этого пока нет.

X11: сравнение с Mosquitto на том же VPS

Тот же тип машины, что и в прошлом тексте (Contabo, 4 vCPU AMD EPYC, 8 GiB), нагрузка с Linux-хоста на расстоянии 15 ms, взаимный TLS 1.3 с одними и теми же сертификатами с обеих сторон, Mosquitto 2.0.21 на Debian 13 без персистентности. Метод и решения в ADR-213, сырые данные в docs/perf-results/. Медиана трех запусков.

Что это значит, а что нет. Рукопожатия это нижние границы для обоих серверов: генератор нагрузки это разделяемая VM с 60 до 70 % украденного процессорного времени, и при 128 потоках он был близок к собственному пределу, а рабочие ядра urMQTT были заняты лишь на 12 до 13 %. Отношение при 128 клиентах (около 2,2 раза) наиболее осмысленно; при 32 и 64 оно в основном измеряет ожидание клиентов. Цифры памяти считают не одно и то же (куча ядра против RSS процесса), поэтому «примерно в 50 раз меньше» это порядок величины, а не точное отношение. Задержка в 14 ms это один круг сети (около 15 ms), то есть «измеримого времени брокера нет»; хвосты (p99 около 100 до 200 ms) у обоих брокеров определяются разделяемыми хостами. Различия ниже примерно 20 % мы не утверждаем.

Что оказалось не в нашу пользу и осталось в таблицах: один TCP-поток через urMQTT нес в 2 до 8 раз меньше, чем через Mosquitto, с колебаниями от нуля до 7,7 тысячи сообщений в секунду между запусками, а 20-миллисекундный watchdog обработчика обрывал живые соединения, когда гипервизор останавливал vCPU (в продакшен-настройке action = "drop", от 6 до 8 соединений за запуск при затоплении QoS 0). Обе проблемы описаны в следующем разделе, потому что их причины были в нашем коде.

Почему один поток был медленным: причины, а не отговорки

Проще всего было бы сказать «разделяемый VPS». Мы этого не сказали, а на том же VPS и тем же методом искали причины. Найдено пять причин, четыре на пути данных и одна в watchdog (ADR-221 до ADR-224):

Остановки настоящие: на этом VPS у ядер 0 до 2 была медиана от 36 до 80 опоздавших тиков за 5 секунд, а худшая остановка в окне имела медиану около 70 ms и доходила до 0,9 s (ядро 3, база и журнал: до 1,55 s), при том что хост не сообщает украденное время (host steal 0 us). Поэтому watchdog нужен был другой источник времени, а не больший бюджет.

Watchdog: 148 оборванных соединений в 30 нагруженных запусках до, 0 в 24 запусках после; на локальной установке, которая задерживает и теряет кадры, при потере 0,1 % один поток в 64 B с 14,3k сообщений/с (ядро X11) теперь имеет 41,0k, а при 0,5 % с 5,0k до 17,7k.

Чего это не говорит. urMQTT по-прежнему не быстрее Mosquitto на одном потоке: при 64 B он публикует около 80 % его скорости, а доставляет около 40 %, потому что отбрасывает QoS 0, когда поток подписчика медленнее потока издателя (Mosquitto без границы ставит в очередь). При 1 KiB в 16-парном затоплении Mosquitto впереди примерно на 15 %, что в пределах шума. Генератор снова был разделяемой VM с 58 до 77 % украденного времени. Второй раунд (блокировка кучи вне пути данных, SACK на стороне отправки и другое) находится в неинтегрированной ветке perf-single-flow-wip; его цифры еще не утверждения, и здесь мы их не приводим.

Обещание, которого мы не давали, но выполнили: конфигурация это данные

До сих пор каждая конфигурация была новой сборкой: ключи и ограничения были вшиты в образ. C1 переворачивает это (ADR-215 до ADR-219): ядро собирается один раз, а конфигурация это данные.

• Блоб urmqtt-cfg (C1a): версионированная, каноническая запись (поля по возрастающим меткам, отпечаток SHA-256, необязательная отдельная подпись Ed25519), 70 полей со значениями по умолчанию и границами, декодер, который отвергает все неправильное.
• Ядро читает его как модуль Limine (C1b), раньше всего остального, на aarch64 и x86_64. Существует одно выпускаемое ядро для каждого ENV, кроме dev (ELF aarch64 для release, prod и bench имеют один и тот же SHA-256; проверено только на aarch64). Выпускаемое ядро отвергает конфигурацию для разработки, а без конфигурации пишет «refusing to serve» и ничего не обслуживает.
• Установленный диск несет конфигурацию, и обновление ее сохраняет (C1c).
• urmqtt-config и шаблон ISO (C1d): pack, show, verify, а pack --iso заменяет оба экземпляра места для конфигурации и 24 дайджеста модулей в готовом ISO. Результат байт в байт совпадает с ISO, который собирает mkiso.sh --config. Шаблон релиза v0.2.0 имеет 63 111 168 байт.
• Заявление о доверии (ADR-219): сконфигурированный образ при загрузке выводит отпечаток конфигурации (config: fingerprint ...), а подпись необязательна и по умолчанию выключена. У измененного ISO нет официального дайджеста; отпечаток это способ увидеть, что в нем находится.

Сборщик на aldo.tech

То, что делает urmqtt-config pack --iso, делает и веб-страница, тем же кодом: библиотека инструмента, скомпилированная в WebAssembly (1,06 MB, без импортов и без блока unsafe). Страница находится по адресу aldo.tech/ru/produkty/urmqtt-builder/ и существует на всех 15 языках сайта (например, hr).

• Ничто не покидает браузер. Сертификаты, закрытые ключи и готовый ISO остаются на компьютере; страница скачивает только файлы релиза с этого сайта, без отслеживания и без сторонних скриптов. В живом тесте ни один запрос не нес ключевой материал.
• Зеркало релизов (ADR-227): каждый час (таймер systemd, низкий приоритет) копирует релизы с GitHub, каждый проверяет перед публикацией, а страница в браузере проверяет подпись SHA256SUMS ключом, встроенным в страницу, и только потом записывает конфигурацию в шаблон. Неудачная проверка блокирует скачивание.
• Просто по умолчанию, расширенно по необходимости (ADR-232): первый экран это три шага (где будет работать, ваши сертификаты, имя образа). Одно поле для перетаскивания файлов раскладывает сертификат, ключ и CA по содержимому. Расширенный вид открывает каждое из 70 полей, поиск, импорт и экспорт TOML; оба вида редактируют одно и то же состояние. Шаблон (63 MB) скачивается, пока пользователь заполняет форму. В живой пробе, с пробным зеркалом и пробным ключом, сборка ISO в браузере заняла от 5 до 18 s.

Эмулятор, необязательно. Рядом с «Скачать ISO» стоит «Попробовать в эмуляторе»: QEMU, скомпилированный в WebAssembly, запускает только что собранный образ во вкладке браузера. Ничего из него не скачивается до клика (около 3 MB в первый раз). Эмулятор работает только с BIOS, без сети (чтобы трафик пользователя не прошел через какого-либо посредника и не нарушил «ничто не покидает браузер»), требует около 1,5 GB памяти и компьютерный браузер (протестирован Chrome; Firefox и Safari нет). В нем urMQTT доходит до URMQTT READY примерно за 8 s (с пропущенным обратным отсчетом) и выводит тот же отпечаток конфигурации, что и страница, что доказывает, что поднята именно эта конфигурация. Загрузка примерно в 2 раза медленнее исходного QEMU на том же Mac (0,82 s против 1,9 s), а криптография примерно в 58 раз медленнее, потому что аппаратные инструкции эмулируются. Поэтому из эмулятора мы не делаем никаких утверждений о скорости, и страница говорит об этом до запуска. При сборке пришлось исправить четыре байта в .wasm из-за ошибки в трансляции инструкции POPCNT в исходном эмуляторе (мы о ней еще не сообщили); сам эмулятор распространяется под GPL, с предложением исходного кода.

Обычный MQTT, только для сетей, которым вы доверяете

Обычный MQTT (TCP 1883, без TLS) очень распространен в IoT: он по умолчанию в Mosquitto, в большинстве прошивок для Arduino и ESP, в Tasmota, Zigbee2MQTT и Home Assistant, а используется он и внутри сегментированных промышленных сетей, за VPN и в частных LAN, в том числе на устройствах без часов (сертификатам нужна дата), без достаточного объема flash или процессора для TLS. Через недоверенную сеть он неприемлем: кто находится на пути, читает и изменяет трафик. Поэтому P1 (ADR-229 до ADR-231) это явный, ограниченный выбор, по умолчанию выключенный, а порт TLS остается; TLS этим не отключается, обычный порт появляется рядом с ним.

• Список разрешенных сетей обязателен (allow_from, CIDR) и проверяется при SYN: вне списка нет ни SYN-ACK, ни состояния. Весь интернет (0.0.0.0/0) требует отдельной явной опции.
• Три способа входа: пароль (по умолчанию, когда включено; PBKDF2-HMAC-SHA-256, соль, 10 000 итераций, сравнение за постоянное время, блокировка по адресу), анонимно (одна настроенная идентичность со своим ACL) и по адресу (ip). Сборщик хэширует пароль в браузере и хранит в памяти только дайджест.
• Меньше прав, чем при mTLS: обычный клиент никогда не получает служебных, операторских и управляющих прав, у него нет $SYS и консоли, у него свои сессии ($plain/<идентичность>/<id клиента>, только чистые), собственные ограничения, и реестр допустимых по-прежнему его обязывает.
• Что теряется, записано в SECURITY.md: конфиденциальность, целостность, аутентичность брокера и повтор записанного входа. Это нельзя исправить конфигурацией; так бывает, когда нет TLS.

Измерено на ноутбуке (Apple silicon, HVF, пользовательская сеть QEMU), 16 пар, 64 B, три запуска по 10 s: при 8 000 сообщений в секунду TLS и обычный путь доставляют все сообщения с одинаковой задержкой (p50 0,17 ms против 0,13 до 0,18 ms), новых соединений в секунду: TLS около 2 600 до 2 750, анонимный обычный около 4 900 до 7 800, а вход по паролю это дорогая часть: один PBKDF2 стоит около 2,5 ms, поэтому число новых входов ограничено примерно 200 на ядро данных в секунду (измерено 308 до 342 на двух ядрах). Затопление на этой машине не является стабильным инструментом (от 20k до 440k доставленных в секунду между запусками), и из него мы не делаем вывода. Сравнение обычного пути с Mosquitto на VPS еще не сделано. Тесты: smoke-группа plaintext 7 из 7 на aarch64 HVF и на x86_64 TCG, новая цель фаззинга plain_input (2,3 миллиона запусков без находок).

Ошибки, которые нашла работа вживую

Две вещи поймали не тесты, а первое включение на настоящем сайте:

• Страница искала файлы релиза на один каталог выше, поэтому каждая проверка подписи отвечала 404 (исправление 13af301). Тест использовал пробное зеркало по другому пути.
• Клавиатура эмулятора никогда не доходила до гостя: причиной был не плохой перевод клавиш, а то, что диалог вообще не слушал клавиши (исправление в ADR-232, с входом для загрузки без клавиш).

Уроки

• Ищите причину, не обвиняйте окружение. Большинство слабостей одного потока и все оборванные соединения были нашими; гипервизор настоящий, но его нужно было измерять, а не предполагать.
• Сравнение с другим продуктом должно включать и потери. Таблица, в которой только наши победы, не была бы сравнением.
• У измерительного инструмента есть границы. Разделяемый генератор с 60 до 70 % украденного времени меняет то, что означают цифры; поэтому мы пишем «нижняя граница» и не утверждаем различий ниже 20 %.
• Изоляция это не доказательство. SQLite в EL0 уменьшает то, что может натворить ошибка в нем, но не то, о чем он может лгать.
• Настоящая установка находит то, чего тесты не ищут: неправильно составленный путь и клавиши, которые никто не слушает.

Что еще не доказано

• Ключ подписи релиза пока пробный; v0.2.0 и v0.2.1 это пре-релизы, а образы к ним для разработки с пробными сертификатами (кроме шаблона, который без конфигурации).
• 13 переводов страницы сборщика (и этого текста) написал ИИ, и проверили их тесты и выборочные проверки, а не носители языка.
• Сравнение с Mosquitto это одна сессия, один путь и один разделяемый генератор, на разделяемом VPS; различия ниже 20 % не являются утверждениями.
• Обычный путь не измерен на VPS и не против Mosquitto.
• Lighthouse на новом простом виде не подтвержден (старый вид: доступность 95 или выше).
• Bare metal, цена воркера на x86_64 на KVM, Firefox и Safari для эмулятора: не измерено.

Что дальше

• D1: публичный демо-брокер. Эмулятор из браузера мы не можем сделать публичным: он живет во вкладке одного посетителя, в 20 до 100 раз медленнее KVM, у него нет входящей сети, и он исчезает при закрытии вкладки; перенаправление интернета в чужой браузер было бы к тому же злоупотреблением. Возможен настоящий демо-брокер: urMQTT на VPS за именем на aldo.tech, с опубликованным пробным CA, строгим ACL и небольшими ограничениями. Пока это только идея, не разработка, и ей нужно явное согласие на публичное размещение.
• Второй раунд для одного потока (ветка perf-single-flow-wip): только когда он будет измерен на VPS и слит.
• Обычный путь против Mosquitto на VPS, вход и отзыв учетных записей для обычного MQTT через подписанный управляющий канал.
• После релиза: bare metal (X12 до X16), IOMMU и Secure Boot, шифрование диска.

Код находится на github.com/zeljan-alduk/urMQTT, а docs/PROGRESS.md по-прежнему единственный источник истины о том, что действительно работает, docs/PERFORMANCE.md о том, что измерено. Пре-альфа, как и раньше; сообщения об ошибках и о безопасности по инструкциям в SECURITY.md приветствуются.

Одно замечание заранее: проект по-прежнему находится на стадии пре-альфа. Цифры в тексте измеряют код и тесты, а не зрелость в продакшене, а первый релиз намеренно ограничен VPS с KVM. Bare metal остается на потом.

Как это выглядело во времени

Первый коммит появился 28 октября 2026 года в 23:48 (M0). К 23:00 31 октября в репозитории уже 119 коммитов, распределенных по календарным дням как 3, 39, 38 и 39. Сразу скажем, как это возможно: проект строится с Claude Code, а коммиты несут трейлеры Co-Authored-By: Claude. Четыре календарных дня истории не означают, что один человек за четыре дня написал 90 000 строк; они означают, что план, реализация, тесты и ADR пишутся короткими замкнутыми циклами, и каждый шаг заканчивается тем же ритуалом проверки, что и раньше. Цифры ниже говорят об объеме кода и тестов, а не о том, сколько всего этого было проделано в реальной работе.

На графике три кривые, которые растут почти вместе, и это намеренно: тесты и записанные решения идут вровень с кодом, а не отстают от него. Наклон круче всего 29 октября, когда создается весь путь от ядра до брокера. Дальше строки добавляются медленнее, но тесты растут быстрее кода (27 тестов на 1,6 тысячи строк в начале, 739 на 89,8 тысячи сегодня).

Строки это все файлы .rs вне vendor/ и fuzz/, тесты это функции #[test]. Что добавлялось и когда, по датам из истории git:

Обещание 1: один ISO для нескольких платформ

Что мы планировали. Один файл, который загружается на aarch64 UEFI, x86_64 UEFI и x86_64 BIOS. Что мы построили. Порт на x86_64 (X0 до X10) и универсальный ISO с загрузчиком Limine, один гибридный ISO, с которого загружаются все эти комбинации; смоук-тесты поднимают его на четырех виртуальных машинах. В меню три пункта: urMQTT (живой режим, работает из RAM, на диск ничего не пишет), установка на диск машины, на которой он запущен (установка записывает GPT и данные, а затем выключает машину) и Диагностика (определение оборудования и измерения).

Первой настоящей целью стал VPS, а не физический компьютер: решено, что первый релиз поддерживает только VPS (KVM), а bare metal идет после него. Мы тестировали на VPS у Contabo с процессором AMD EPYC (семейство 23, Zen 1), 4 vCPU и 8 GiB RAM, с сетью virtio-net и диском virtio-scsi. Первая попытка нас удивила: ISO, подключенный как виртуальный CD, загрузил пункт по умолчанию, продакшен-образ отказался работать с носителя только для чтения и перезагрузился, и мы получили бесконечный цикл меню, ядро, сброс без единой читаемой строки. Сегодня фатальная ошибка в продакшен-образе оставляет сообщение на консоли на 60 секунд перед перезагрузкой, а с оптического носителя выводит, что загрузка произошла с носителя только для чтения, и останавливается. Живой режим в RAM (O3) позже обошел эту проблему для обычного случая.

Пункт диагностики родился из этого опыта: машину, которую мы не видим, нужно уметь спросить, что у нее есть. Он выводит CPU, RAM, сеть, диски и PCI-устройства, измеряет пропускную способность памяти, диск и криптографию, а те же измерения выводит в виде JSON на последовательный порт. Запись на диск разрешена только в нераспределенном пространстве и только после ввода WIPE; на снимке ниже это пропущено.

Что остается открытым. Настоящее железо. После первого релиза идет bare metal (загрузка с USB, NVMe и AHCI, сетевая карта реального компьютера) вместе с IOMMU и Secure Boot, потому что без IOMMU вредоносное или неисправное устройство может писать по всей памяти. В этой версии мы ничего об этом не утверждаем.

Рукопожатие: от 1,2 мс до 0,24 мс

Первое измерение диагностики на VPS дало неприятную цифру: mTLS-рукопожатие, только криптография на стороне сервера, занимало 1,2 мс. На aarch64 мы уже использовали аппаратные инструкции AES и SHA, но для открытого ключа на x86_64 ничего подобного не было: RustCrypto переносим и работает за постоянное время, а значит, и медленно. Три изменения это исправили.

• Для P-256 мы взяли ассемблер nistz256 из OpenSSL и ring (ADR-130), с таблицами с фиксированным основанием для подписи и проверки подписи CA (ADR-110, ADR-111).
• X25519 переписан на четыре 64-битные ветви с инструкциями MULX/ADX (ADR-131).
• После этого мы профилировали и остальное (ADR-132, ADR-200).

Цифры отличаются от запуска к запуску примерно на 10%, поэтому мы записали диапазон вместо одного значения. В сумме это примерно в пять раз меньше процессорного времени на рукопожатие.

Что мы узнали о memcpy. Когда криптография стала быстрой, профиль показал неожиданное: функции mem* (memcpy, memmove, memset) занимали 7% рукопожатия, от 13 до 39% пути TLS-записи (39% для 64 B, 13% для 4 KiB) и от 17 до 34% разбора PUBLISH. Мы заменили их ассемблером SSE2 для x86_64 (ADR-200) с дифференциальными тестами против эталонной реализации для всех размеров, выравниваний и перекрытий. На один вызов это 55-75 циклов против 7-12 для 1-64 байт.

Как читать график: чем меньше запись, тем большая часть времени уходит на копирование, а значит, тем больше выигрыш. Для маленьких сообщений, которых большинство в MQTT-трафике, это и есть то, что имеет значение.

Что это не означает. На нативном x86_64 мы измеряли OpenSSL 3.5.5 (ADR-130) только как эталон для ассемблера, а не как сравнение продуктов. Сравнение Linux плюс Mosquitto на том же VPS (задача X11) мы еще не сделали. Поэтому мы не утверждаем, что urMQTT быстрее Linux: это не измерено. Цифры выше сравнивают urMQTT с самим собой.

Перегрузка стала вторым результатом. На VPS, с одного Mac (RTT 35 мс), 128 клиентов дали 618 рукопожатий в секунду, 256 клиентов 393, а 512 клиентов 67, с тысячами отклоненных соединений. Это не было плато, это был обвал. Причины мы нашли в коде (две подтверждены в QEMU/HVF, на VPS воспроизвести их не удалось), и их было несколько сразу: отклоненное соединение возвращало клиента через следующий сегмент, несущий действительную SYN-куки, отказ через RST говорил клиенту немедленно пробовать снова, а прием был O(очередь). Исправление (ADR-080 до ADR-082) отбрасывает SYN, который не был бы принят, запоминает отклоненные потоки, держит прием в O(1) и считает рукопожатия по ядрам. Возможно (гипотеза, не проверена), часть причины была и на стороне клиента: инструмент нагрузки закрывал соединение первым, и один Mac с 16 384 эфемерными портами и TIME_WAIT в 30 секунд был ограничен примерно 550 соединениями в секунду. Поэтому настоящий потолок сервера мы еще не измерили.

Обещание 2: сырой диск, но аккуратный

Что мы планировали. Сохранить собственную раскладку без файловой системы и добавить все то, что файловая система обычно дает: выравнивание, рост, discard, резервные копии и проверки. Почему не файловая система. Мы это обсуждали, и решение подтверждено: urMQTT пишет одну базу, один журнал телеметрии и собственные метаданные, ему не нужны каталоги, права доступа и имена файлов, а каждый дополнительный слой был бы еще одним кодом в доверенной части и еще одним способом, которым запись тихо исчезнет. Диск это GPT с разделом ESP и одним разделом данных urMQTT, внутри которого собственная раскладка.

Что мы построили (S2 до S6).

• Раскладка v2 (S2). Топология диска, выравнивание на 1 MiB или оптимальный размер ввода-вывода, целые физические блоки, A/B-пара суперблоков с поколением (ADR-140). Раскладку v1 ядро отклоняет с понятным сообщением, а мигрирует ее офлайн-инструмент urmqtt-disk migrate (ADR-141): по умолчанию пробный прогон, сначала копирование, потом переключение, с откатом и внедрением ошибок на каждой записи.
• Рост (S3). При загрузке диск может вырасти (никогда не уменьшается), а на virtio-blk и во время работы, через прерывание об изменении конфигурации (ADR-142, ADR-143).
• Discard и write-zeroes (S4). Тонко выделенные диски возвращают место хосту. В тесте qcow2-файл на хосте уменьшился с 62 до 16 MiB после истечения сегментов телеметрии, а восстановление никогда не доверяет содержимому, которое было отброшено.
• Резервная копия базы на диске (S5). A/B-копия с помощью онлайн-API резервного копирования SQLite шагами по 16 страниц: самый длинный шаг 4,6 мс против 445 мс при копировании одним вызовом. Коммиты во время копирования имели максимум 2,4 мс против 2,2 мс без нее. Если quick_check при загрузке не проходит, база восстанавливается из копии.
• Очистка и ограниченная загрузка (S6). Scrubber читает диск с ограниченным бюджетом ввода-вывода и сообщает о поврежденных записях, а загрузка читает только самый новый сегмент каждого раздела, так что время загрузки не растет вместе с размером региона телеметрии. Так мы закрыли проблему, которую рассчитали заранее: на большом диске полное восстановление заняло бы от минут до десятков минут.

Вся группа смоук-тестов хранения проходит на обеих архитектурах: 79 успешных, 0 неуспешных, на aarch64 под HVF и на x86_64 под TCG. Мы также измерили, что S4 не замедлил базу: 53,3 тысячи вставок в секунду пакетами до и после, без измеримой разницы.

Что удивило. Сколько в «простой» раскладке уходит на крайние случаи: virtio-scsi и virtio-blk сообщают топологию по-разному, а неполная запись посреди миграции всегда должна оставлять хотя бы одну действительную версию. Поэтому каждая запись на пути миграции и роста прошла внедрение ошибок.

Что остается открытым. У страниц SQLite нет контрольной суммы, поэтому изменившийся бит внутри значения в строке база не обнаружит; записи телеметрии и содержимое копий имеют CRC и обнаруживаются. Шифрование диска (S7) не готово.

Обещание 3: доказуемо безопасно, насколько получится

Усиление (H4). Аллокатор стирает освобожденную память и проверяет ее при повторном использовании, обнаруживает двойное освобождение, связывает указатели свободного списка через XOR и обнуляет ключи при освобождении (ADR-170). Защита стека (-Zstack-protector=strong, 1315 функций, а SQLite с -fstack-protector-strong, ADR-171). Отчеты об ошибках в продакшене не содержат регистров и адресов (ADR-172). KASLR на обеих архитектурах: ядро является PIE, и Limine сдвигает его примерно на 19 бит, а куча, стеки и окно MMIO размещаются случайно (ADR-173). На aarch64 MTE помечает кучу (ADR-174), но только под TCG: в HVF и на x86 его нет. kCFI мы оценили и не приняли, потому что компилятор на закрепленном nightly падает с внутренней ошибкой; IOMMU отложен вместе с bare metal (ADR-175, ADR-176).

Цена измерена, а не предположена. На пути рукопожатия (dp-bench, aarch64 HVF, полные рукопожатия TLS 1.3 + mTLS + CONNECT):

В целом цена на пути рукопожатия составляет примерно 5% для частей, измеренных чисто, а с PIE и метками выходит около 7% на одном и около 11% на четырех ядрах, но это измерение шумное. Мы считаем ее приемлемой, но не повторяли ее на x86_64 VPS.

Стоит сравнить с цифрой из первого текста (862 рукопожатия в секунду на одном ядре). Тот же инструмент сегодня, с драйвером аппаратного шифрования на aarch64 (X0b) и рядом ускорений, пришедших с тех пор, дает 1941 до усиления. Вклад каждого изменения мы не выделяли, поэтому о причине ничего не утверждаем.

Как проверено, и что нет. H5 добавил Miri на подмножество хост-крейтов, доказательства Kani, санитайзеры, модельный фаззер для ACL и отчеты о покрытии. Kani доказал record_len в TLS, parse в TCP и две арифметики колеса таймеров. Не доказано (истекло время): оба MQTT-декодера, оба разбора конфигурации и поведение колеса таймеров; CI-задача для Kani поэтому пока не блокирует. Miri не умеет выполнять ассемблер. Цепочка поставок (H9): CycloneDX SBOM с 215 компонентами, cargo-vet проходит с 39 полностью проверенными и 140 исключениями, а cargo-deny настроен так, чтобы рассматривать советы об уязвимостях как падение CI (эти CI-задачи пока проверены только локально, не на GitHub, а негативный тест не запускался), плюс VULNERABILITY-HANDLING.md. Честное положение дел: из 67 версий сторонних крейтов, линкуемых в ядро, 53 это исключения, а не аудиты. Vet доказывает, что набор зависимостей нельзя изменить без видимой разницы, а не то, что TCB проверен. Собственный аудит ни одного крейта мы не писали.

SNTP (T1) в этом смысле маленькая история о безопасности: он опционален, только к частным IPv4-серверам, с максимальным скачком и при условии, что источники согласны (медиана, большинство в пределах одной секунды). Часы, которые кто угодно на пути может сдвинуть, это не часы, которым мы можем доверять при проверке срока действия сертификата.

На Mac: aarch64 нативно и x86_64 эмуляцией

Мы разрабатываем на Mac, а у него два способа запускать один и тот же код, и они очень разные.

Правило простое: цифры под TCG это эмуляция, и мы не приводим их как производительность. Производительность x86 мы измеряем только на настоящем VPS. Поэтому криптографические цифры выше взяты с VPS у Contabo, а не с Mac.

Уроки

• Измеряйте на настоящей машине, прежде чем оптимизировать. Первый подход состоял в оптимизации того, что мы считали медленным; только диагностика на VPS показала 1,2 мс и где именно уходит время.
• Перегрузка это отдельная характеристика. Система, которая быстра под нагрузкой, может обвалиться выше нее; отказ должен быть дешевле принятия.
• Профиль удивляет. Самый большой отдельный выигрыш для маленьких сообщений оказался не в криптографии, а в копировании памяти.
• Диск без файловой системы требует больше работы, а не меньше. То, что файловая система обычно дает (выравнивание, рост, discard, копии, проверки), мы должны написать и проверить сами, каждый шаг с внедрением ошибок.
• Честность в цифрах. Измерения памяти на общем VPS колеблются до 10 раз между запусками и ничего не говорят о коде, поэтому мы их не приводим. Криптографические цифры стабильны примерно до 10%.
• Скорость разработки это не зрелость. Тесты и ADR растут вместе с кодом, но четыре дня это не настоящая эксплуатация.

Что дальше

• H6: SQLite, изолированный на уровне EL0, чтобы ошибка в базе не открывала ядро.
• H7: остальная безопасность времени (NTS и обработка скачков); SNTP это лишь первый шаг.
• X11: сравнение с Linux и Mosquitto на том же VPS, только тогда имеет смысл говорить об относительной скорости.
• Релиз: первая публичная версия для VPS (KVM), с подписанными артефактами и инструкциями.
• После релиза: bare metal (X12 до X16), IOMMU и Secure Boot, а также шифрование диска.

Код находится на github.com/zeljan-alduk/urMQTT, а docs/PROGRESS.md по-прежнему единственный источник истины о том, что действительно работает. Пре-альфа, как и раньше; сообщения об ошибках и о безопасности по инструкции в SECURITY.md приветствуются.

Так появился urMQTT: unikernel, который является MQTT-брокером. Ядро, TCP/IP, TLS 1.3, MQTT и встроенная база данных в одном бинарном файле на Rust, запускаемом с одного ISO. Нет процессов, нет системных вызовов, нет оболочки. Первая платформа, на которой он собирается и тестируется, это aarch64, а тот же код движется к x86_64, через UEFI и классический BIOS, и к настоящему железу: цель в том, чтобы один ISO загружался на всем этом. Проект с открытым исходным кодом под лицензией MIT или Apache 2.0, и в этом тексте мы хотим записать, до чего мы дошли, как он устроен изнутри и чему мы попутно научились.

Что именно означает «unikernel»

Обычный брокер — это программа, работающая в операционной системе. У urMQTT под собой нет операционной системы: он сам загружается через UEFI firmware и загрузчик Limine, настраивает собственные таблицы страниц, программирует контроллер прерываний и таймер, находит virtio-устройства через PCIe, получает адрес по DHCP и слушает на одном порту. Всё, что обычно делали бы ядро, драйверы, сетевой стек и приложение, здесь собрано в один ELF, работающий на уровне EL1.

Сравнение с типовой установкой говорит само за себя:

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

Где мы сейчас

Проект находится на стадии пре-альфа, но закрыто семнадцать этапов разработки, от M0 до M17. Сегодня urMQTT обслуживает MQTT 3.1.1 поверх TLS 1.3 с обязательными клиентскими сертификатами, а состояние хранит в SQLite на сыром диске. Коротко, что уже работает:

• Ядро: собственные векторы исключений с декодированными отчетами, собственные таблицы страниц с принудительным W^X, защитные страницы, PAC и BTI там, где они есть у процессора, GICv3 и GICv2, универсальный таймер, SMP до 64 ядер.
• Обнаружение оборудования из DTB или ACPI в единое описание платформы, с идентичным результатом из обоих источников.
• Драйверы: PCIe ECAM, MSI-X, virtio-net, virtio-blk, virtio-scsi и virtio-rng, а также CSPRNG, инициализируемый аппаратной энтропией.
• Сеть: собственные DHCPv4, ARP, ICMP и строгий IPv4, затем собственный TCP только для серверной стороны: SYN-куки, иерархическое колесо таймеров, NewReno, объединение ACK, без состояния TIME_WAIT.
• TLS: только TLS 1.3, обязательный mTLS, идентификатор устройства из CN или SAN URI; рукопожатие выполняет rustls, а после него работает собственный слой записей с AES-128-GCM и ChaCha20-Poly1305. Возобновление сессии по PSK-билетам, список отзыва, контроль допуска уже при рукопожатии.
• MQTT: кодек без копирования, проверенный фаззингом и тестами с настоящими клиентами mosquitto; QoS 0 и 1, подстановочные символы, сохраненные сообщения, завещание (LWT), постоянные сессии, ACL с ограничением на devices/{id}/#, ограничения скорости по устройству.
• Хранение: SQLite внутри ядра через VFS поверх сырого диска, в режиме WAL, с проверкой целостности при загрузке; реестр устройств, отзывы, сохраненные сообщения, постоянные сессии с очередями сообщений для устройств, находящихся офлайн; на каждое ядро отдельный журнал телеметрии с CRC на запись и восстановлением после сбоя.
• Эксплуатация и надзор: сторожевой таймер для обработчиков, проверка работоспособности, ограниченное логирование, syslog и statsd по UDP, допуск, переживающий шторма переподключений.
• Поставка: побитово идентичные повторные сборки, проверяемые в CI, ISO и сырой образ диска GPT, подписи minisign, инструкции для KVM, Proxmox и Hetzner.

Каждый шаг отмечен этапом, который его принес, а файл docs/PROGRESS.md в репозитории — единственный источник истины о том, что действительно работает.

Архитектура в трех картинках

Весь дизайн описан в docs/ARCHITECTURE.md, а причины каждого важного решения записаны как ADR в docs/DECISIONS.md. Здесь приведен обзор.

Слои

Сверху вниз: брокер (сессии, дерево тем, QoS, сохраненные сообщения, завещания, ACL, ограничения), кодек MQTT, TLS, TCP, сетевой слой, затем драйверы. Рядом с этим основным путем стоит хранилище (SQLite и журнал телеметрии), а под всем этим управление памятью, обнаружение платформы и конфигурация, преобразованная на этапе сборки в константы, вместе со встроенным сертификатом CA, серверным сертификатом и ключом. Гипервизор с virtio-устройствами — единственное, что находится вне образа.

Поток на ядро, без общего состояния

Каждое ядро данных крутит собственный цикл со своим стеком TCP, состояниями TLS, частью брокера (сессии и дерево тем), кэшем кучи и разделом телеметрии. Ядра не разделяют никакого изменяемого состояния, только ограниченные кольца без блокировок, по одному для каждой упорядоченной пары ядер. Старшее ядро запускает SQLite и больше ничего.

У сетевой карты сегодня одна пара очередей, которой владеет ядро 0. Оно направляет каждый поток MQTT по хешу Тёплица его четверки на одно из рабочих ядер и отправляет то, что возвращают рабочие ядра. Сессия живет на своем домашнем ядре, определяемом хешем идентификатора клиента, поэтому перехват, завещания и устойчивость никогда не пересекают границы ядер. Соединение, попавшее на другое ядро, сохраняет там свои TCP и TLS, а обычный MQTT пересылает домашнему ядру с управлением потоком на основе кредитов. Каждое маршрутизируемое сообщение также рассылается остальным частям брокера, каждая из которых держит реплику сохраненных сообщений.

Эту модель держат вместе три правила. Обработка до конца: принятый пакет полностью обрабатывается на одном ядре, от TCP через расшифровку TLS на месте, разбор MQTT и маршрутизацию до зашифрованного ответа, без очередей задач и без копирования в буферы приложения. Адаптивный опрос: под нагрузкой очереди приема опрашиваются активно, а в покое ядро возвращается к прерываниям и WFI; обработчики прерываний лишь подтверждают прерывание и отмечают работу. Сторожевой таймер: тик в 10 мс на ядро ловит обработчики, превысившие свой бюджет.

Жизнь одного PUBLISH

Устройство отправляет запись TLS. Сетевая карта передает ее циклу ядра дескриптором, без копирования. Цикл проверяет TCP, расшифровывает TLS на месте и разбирает MQTT из заимствованного буфера, затем в памяти проверяет ACL, ограничение скорости и путь по дереву тем. Если другое ядро интересуется этой темой, оно получает сообщение для маршрутизации со ссылкой на содержимое и идентификатором темы; база получает запись телеметрии или обновление сохраненного сообщения, пакетом. Ответ PUBACK шифруется прямо в исходящий буфер и объединяется с TCP ACK, так что к устройству уходит один сегмент. Другому ядру сообщение стоит одного шифрования на подписчика в момент отправки.

Сколько стоит одно соединение

Цель — не более 512 байт на неактивное TLS-соединение, со стремлением к 256. Пока соединение простаивает, для него в буфере ничего не держится: принятые данные обрабатываются прямо из сетевого кадра, а буферы для отправки, записей и MQTT существуют только пока что-то не завершено или не подтверждено. Ядро измеряет это само: точные счетчики кучи в запрошенных байтах и в блоках, которые они занимают, записываются каждые десять секунд как куча сверх базового уровня на одно открытое соединение.

Измерено под HVF с четырьмя виртуальными ядрами, из них три рабочих, при этом каждое устройство держит соединение mTLS и одну подписку с QoS 1, включая округление аллокатора:

Пул сетевых кадров фиксирован и составляет около 2 МиБ, то есть примерно 200 Б на соединение при десяти тысячах соединений и около 2 Б при миллионе. Больше измерить мы не смогли: пользовательская сеть QEMU на macOS перестала принимать соединения на 10 197, примерно на границе в 10 240 дескрипторов процесса QEMU. Показатель снижается по мере распределения фиксированных частей на большее число соединений, поэтому он не растет вместе с их числом.

Модель безопасности

Безопасность — первый приоритет, и она выигрывает все конфликты с остальными целями. В модели несколько слоев:

• Один порт. TCP 8883, только TLS 1.3, обязательные клиентские сертификаты, подписанные CA, встроенным в образ. Идентификатор клиента MQTT должен совпадать с идентификатором устройства из сертификата.
• Нет входа. Нет оболочки, консольного ввода, SSH, API администрирования, динамического кода, SQL, доступного по сети, и файловой системы.
• Безопасность памяти. Rust, с forbid(unsafe_code) в протокольных пакетах; у каждого блока unsafe есть комментарий // SAFETY:, который проверяет линтер, а на внешний ввод нет паники: clippy в пакетах на пути данных запрещает unwrap, expect, индексирование и panic!.
• Смягчение эксплуатации. W^X обеспечивается кодированием дескрипторов и битом SCTLR_EL1.WXN и проверяется при каждой загрузке. Таблицы страниц после загрузки доступны только для чтения, без записываемого алиаса. Нижняя половина адресного пространства исключена. У каждого стека есть защитные страницы, а исключения выполняются на отдельном стеке. PAC и BTI включаются, когда процессор их поддерживает, и это проверяют дымовые тесты.
• Устойчивость к злоупотреблениям. SYN-куки; допуск отклоняет новые соединения, до какой-либо криптографии, когда куча мала, когда база отстает, когда слишком много рукопожатий выполняется на ядро или на исходный адрес, или когда скорость рукопожатий слишком высока. Ограничения скорости по устройству, ограниченные очереди, окно TCP, привязанное к противодавлению брокера, ограниченное логирование, сторожевой таймер и проверка работоспособности.
• Неизменяемость. Конфигурация, CA и серверный ключ встроены в образ. Изменение чего-либо означает новый образ.

Модель угроз записана в docs/SECURITY.md.

Хранение без файловой системы

Данные живут на отдельном диске, virtio-blk или virtio-scsi, на котором нет файловой системы. Раскладка минимальна и собственная:

LBA 0      [ суперблок: магическое число · версия раскладки · uuid · таблица регионов · CRC-32C ]
LBA 8, 16  [ таблица размеров файлов, слоты A/B (побеждает последний валидный) ]
LBA 64     [ основная база SQLite ½ ][ SQLite WAL ⅛ ][ журнал 1 MiB ][ журнал телеметрии: 8 разделов … ]
последние 4 KiB [ область для самопроверки блочного устройства при загрузке ]

SQLite (вендорная версия 3.54.1, с проверкой хеша при сборке) компилируется в ядро с помощью clang, без стандартной библиотеки, и использует фиксированную кучу memsys5. Его VFS отображает три фиксированных файла на регионы диска. Он работает в режиме WAL с locking_mode=EXCLUSIVE, поэтому ему не нужен индекс в разделяемой памяти, и с synchronous=FULL; если quick_check при загрузке находит ошибку, система безопасно останавливается. В базе находятся реестр устройств, отзывы, сохраненные сообщения и постоянные сессии с очередями сообщений QoS 1 для устройств, которые не подключены.

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

Телеметрия идет другим путем. Каждый принятый PUBLISH по темам из storage.telemetry_topics попадает в раздел журнала телеметрии своего ядра: кольцо сегментов с CRC на запись, посоленное порядковым номером сегмента, чтобы старые проходы кольца никогда не появлялись снова. Ядра передают записи базе собственным кольцом, без копирования, а она сбрасывает их на диск каждые 5 мс или каждые 256 KiB. При загрузке восстановление сохраняет каждую сброшенную запись, отсекает незавершенный хвост и продолжает в новом сегменте. Хранение ограничено по размеру, через кольцо, и по возрасту, через retention_days. Мы проверили это на миллионе записей и с kill -9 посреди записи.

Цифры

Инструмент нагрузки в tools/loadgen делает три вещи: шторм рукопожатий TLS 1.3 с mTLS и CONNECT, долгоживущие соединения с PINGREQ, публикующие телеметрию каждую секунду, и шторма переподключений. make bench на Apple M4 Pro под HVF дает:

Показатель в госте, где клиент и сервер находятся внутри одной виртуальной машины и каждое рабочее ядро работает само по себе, показывает, что плоскость данных масштабируется линейно. Сетевой показатель ограничен однопоточной пользовательской сетью QEMU, а не гостем; это тоже записано как ADR-032.

Шторма переподключений мы тестируем так: все устройства подключаются одновременно, повторяют отклоненные попытки с задержкой, а затем все падают без DISCONNECT. Параметр heap_limit_mb= в режиме разработки заставляет допуск считать кучу меньше, чем она есть, так что шторм, превышающий кучу, можно проверить на небольшом числе сокетов. В одном таком раунде из 3 000 устройств подключилось 1 368 за 36 секунд, а 5 619 попыток были аккуратно отклонены, при ограничении в 8 MiB; память после шторма вернулась.

Как мы работаем

Проектом руководит письменная спецификация, PROMPT.md, с планом этапов, и каждый этап заканчивается одним и тем же ритуалом: make check и make smoke зеленые, один коммит с меткой M<n>, запись в docs/PROGRESS.md и ADR для каждого неочевидного решения. Правила короткие, и мы не идем на уступки: нет паники на внешний ввод, unsafe только в аппаратных пакетах и пакетах FFI и всегда с комментарием, нет аллокаций на горячем пути, комментарий к каждому порядку атомарных операций, каждое ограничение приходит из конфигурации, а намеренные временные части падают громко.

CI делает больше, чем мы успели бы вручную: fmt, clippy для хоста и для aarch64-unknown-none, typos, actionlint и shellcheck; тесты на Linux и macOS на arm64; сборку ядра для конфигурации разработки и продакшена с размером ELF в сводке; загрузку под QEMU со всеми сценариями дымового теста и сохранением последовательных журналов; cargo-deny для advisory, лицензий и источников; минуту фаззинга на каждую из одиннадцати целей, а ночью десять минут на цель с кэшированным корпусом. Кроме того, CodeQL, OpenSSF Scorecard, Dependabot и публикация с происхождением SLSA. Каждое чужое действие закреплено на полном commit SHA.

Воспроизводимость мы понимаем буквально: make repro собирает HEAD дважды в свежих рабочих деревьях и сравнивает ELF, ISO и сырой образ байт за байтом. Релизы подписаны minisign, а артефакты можно проверить с помощью gh attestation verify. Продакшен-образ содержит закрытый ключ сервера, поэтому сам ISO является секретом; образы к релизам на GitHub — для разработки, с временными ключами, и служат только для пробы.

Чему мы научились

Несколько уроков, изменивших план:

• Собственный TCP всё же окупился. Прототип работал на smoltcp и хорошо нам послужил до M13. Но серверу, который держит сотни тысяч соединений, не нужен клиентский TCP, ему нужны SYN-куки, колесо таймеров и состояние в 96 байт. В M14 мы заменили smoltcp собственным стеком только для серверной стороны, с тестами имитации потерь и фаззингом сегментов.
• Измеряйте память изнутри. Оценки на соединение были бесполезны, пока ядро само не начало считать кучу в блоках аллокатора, а не в запрошенных байтах. Только тогда мы увидели, куда на самом деле уходят 512 байт, и спустились до 494.
• Инструмент тестирования — часть продукта. Самым большим ограничением было не ядро, а пользовательская сеть QEMU и число эфемерных портов на компьютере разработчика. Для ста тысяч соединений и больше нужен vmnet-shared на macOS или Linux с KVM, интерфейсом tap и несколькими клиентскими адресами.
• SQLite без операционной системы возможен, но только при строгих условиях: фиксированная куча, эксклюзивная блокировка без разделяемой памяти, VFS, который ничего не знает о файлах, и допуск, не позволяющий базе отстать.
• Шторма переподключений — нормальное состояние, а не исключение. Когда мобильная сеть падает и возвращается, тысячи устройств стучатся одновременно. Поэтому допуск отклоняет соединение до какой-либо криптографии, а каждое отклоненное соединение стоит почти ничего.

Что дальше

Работа после M17 запланирована по трем направлениям, а порядок между ними записан в docs/PLAN.md. Ничего из этого пока не построено.

• Один ISO для нескольких платформ. Один и тот же файл urmqtt-<env>-<версия>.iso и один сырой образ GPT, которые загружаются на aarch64 UEFI, x86_64 UEFI и x86_64 BIOS, в виртуальных машинах и на настоящем оборудовании, начиная с одного ПК на Intel. По-прежнему устройство со всем внутри, воспроизводимое и подписанное.
• Сырой диск, без файловой системы. Спецификация формата на уровне байтов, хост-инструмент urmqtt-disk, разделяющий парсеры с ядром, выравнивание регионов на 1 MiB, рост диска вместе с данными, discard для тонко выделяемых дисков, снимки базы A/B, проверка битов и, по выбору, шифрование AES-256-XTS с аппаратным AES.
• Доказуемо безопасный. Отзыв и список разрешенных устройств во время работы через подписанный канал управления, без нового образа; дифференциальное и конформационное тестирование собственных TLS и TCP; KASLR, защита стека, kCFI, MTE и усиленный аллокатор; SQLite, изолированный на уровне EL0; Secure Boot; SBOM и cargo-vet; и в конце пакет для внешнего аудита.

Платформы, предлагающие только не-virtio устройства, такие как AWS ENA или Azure MANA, пока не поддерживаются. Raspberry Pi 4 и 5 в роли хоста KVM, Hetzner CAX и Oracle Ampere A1 задокументированы и поддержаны в коде, но еще не опробованы на реальном сервисе.

Попробуйте

Репозиторий находится по адресу github.com/zeljan-alduk/urMQTT. С Rust с закрепленной цепочкой инструментов nightly и QEMU команд make certs, make run и одного клиента mosquitto достаточно для первого PUBLISH через mTLS на вашем компьютере. Предупреждение из начала действует и в конце: это пре-альфа, и всё, что работает, описано в docs/PROGRESS.md. Сообщения об ошибках, вопросы по дизайну и сообщения о безопасности по инструкциям в SECURITY.md приветствуются. О каждом следующем этапе мы сообщим здесь.

В этом блоге мы записываем то, чему научились по пути. Не маркетинговые тексты, а конкретные заметки: что пошло не так, как мы это решили и что сегодня сделали бы иначе.

О чём мы будем писать

• Оплата проезда в общественном транспорте. Бесконтактные карты, SAM-модули, работа без сети и всё, что терминал должен выдерживать в машине, которую трясёт двенадцать часов в день.
• Мобильные приложения в поле. Android и Flutter на устройствах, которые не являются обычными телефонами: со считывателями карт, принтерами и батареями, которых должно хватать на целую смену.
• Бэкенд и мониторинг парка. Как узнать, что у устройства в машине проблема, раньше, чем о ней сообщит водитель.
• Железо. От прототипа на столе до платы, которая идёт в серийное производство, и все ошибки между ними.
• Локальные ИИ-модели. Где модели на собственном железе оправданы, а где облако и API просто лучший выбор.

Как мы будем писать

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

Если вас интересует какая-то тема или вы работаете над похожей задачей, напишите нам на info@aldo.tech.