Zastrzeżenie na wstępie pozostaje to samo: projekt jest w fazie pre-alfa, pierwsze wydanie jest tylko dla VPS-ów z KVM, a liczby mierzą kod, testy i określone eksperymenty, a nie dojrzałość produkcyjną.

Jak to wyglądało w czasie

Od poprzedniego tekstu (31.10. o 23:00) do dziś (1.11. o 20:41) w repozytorium przybyło 59 commitów, łącznie jest ich 178. Wszystkie powstały w jednym dniu kalendarzowym, więc obowiązuje to samo ostrzeżenie co wcześniej: projekt powstaje z Claude Code (commity mają Co-Authored-By: Claude), plan, kod, testy i ADR-y powstają w krótkich, zamkniętych pętlach, a liczby poniżej mówią o ilości kodu i weryfikacji, a nie o tym, ile w nich pracy człowieka.

Liczby wyliczono tą samą metodą co w poprzednim tekście: wszystkie pliki .rs poza vendor/ i fuzz/, funkcje #[test], nagłówki ## ADR- w docs/DECISIONS.md.

Pracowano równolegle na wielu gałęziach, więc kolejność commitów nie jest ściśle kolejnością pracy. ADR-y są numerowane do 232, ale numeracja ma luki (część została przemianowana przy scalaniu gałęzi); liczymy nagłówki, a nie największy numer. Wydania: v0.2.0 (1.11., 18:45 UTC) i v0.2.1 (1.11., 20:22 UTC), oba oznaczone jako pre-release.

H6: SQLite w trybie użytkownika

Co planowaliśmy. SQLite to 254 268 linii C, które parsują bazę, WAL i dziennik z dysku, a dysk może być spreparowany lub zmieniony. Dotąd działał w jądrze, z uprawnieniami jądra. Co zbudowaliśmy (ADR-210 do ADR-212): SQLite, jego części libc i sterta zostały przeniesione do osobnego programu, dbworker, który działa na EL0 (aarch64), czyli ring 3 (x86_64), we własnej przestrzeni adresowej. Jądro już nie linkuje SQLite. Worker rozmawia z jądrem przez wspólne okno pamięci i dwanaście wywołań systemowych, a każda zwrócona długość i każde przesunięcie jest sprawdzane przed użyciem. Błąd w workerze (niedozwolony dostęp, niezdefiniowana instrukcja, przekroczony budżet czasu 30 s) kończy wywołanie, worker jest uruchamiany ponownie, a baza otwiera się z WAL tak jak przy starcie; po 5 restartach w ciągu minuty magazyn jest uznawany za uszkodzony, a nie restartowany w nieskończoność.

Koszt, zmierzony na aarch64 pod HVF, ta sama VM, jądro z wbudowanym SQLite wobec jądra z workerem, po sześć naprzemiennych uruchomień każdego:

Zapisy na dysk (1 572) i flushe (319) są identyczne, jak być powinno. To nie jest odizolowane: jądro nadal ufa temu, co zwróci worker, po sprawdzeniu kształtu. Skompromitowany worker może kłamać (na przykład zwrócić pustą listę unieważnionych certyfikatów, a tym samym je „odwołać z unieważnienia"), ale nie może czytać pamięci jądra, kluczy TLS ani kluczy ticketów. Nie ma KPTI, więc wycieki typu Spectre/Meltdown nie są zablokowane i niczego o nich nie twierdzimy; klucz PAC dzielą EL0 i EL1. Na x86_64 kosztu przełączania nie zmierzyliśmy na KVM (pod TCG liczba byłaby bez sensu), a samo fuzzowanie workera i protokołu nie jest skończone. Zestaw testów magazynu (79 scenariuszy, każdy obraca SQLite w workerze) przechodzi na aarch64 HVF i x86_64 TCG, a na aarch64 TCG 76 (jeden jest pomijany, bo TCG nie ma MSI-X).

H7 jest zamknięty, ale nie tak, jak zapowiadaliśmy. Dolna granica czasu (ADR-050) i SNTP z konsensusem (T1) pokrywają zakres H7; NTS (RFC 8915) pozostaje poza zakresem i jest zapisany jako ryzyko szczątkowe, a nie jako coś, co działa. Nie uważamy, że bezpieczeństwo czasu jest „rozwiązane", tylko że jego dowodliwa część jest gotowa.

Nowa opcja sieciowa. Contabo nie daje DHCP dla własnego ISO, więc VPS dotąd wymagał innego obrazu niż laboratoryjna VM. Teraz network.mode = "auto" (ADR-214) najpierw pyta DHCP, a jeśli dzierżawy nie ma w zadanym czasie (dhcp_timeout_s, domyślnie 15 s) lub ją straci, stosuje podany adres statyczny. Wypróbowane ręcznie na QEMU (z DHCP używa dzierżawy, bez sieci po 5 s wraca do adresu statycznego); smoke scenariusza na to jeszcze nie ma.

X11: porównanie z Mosquitto na tym samym VPS-ie

Ten sam rodzaj maszyny co w poprzednim tekście (Contabo, 4 vCPU AMD EPYC, 8 GiB), obciążenie z hosta Linux oddalonego o 15 ms, wzajemny TLS 1.3 z tymi samymi certyfikatami po obu stronach, Mosquitto 2.0.21 na Debianie 13 bez trwałości. Metoda i decyzje są w ADR-213, surowe dane w docs/perf-results/. Mediana z trzech uruchomień.

Co to znaczy, a czego nie. Uzgodnienia są dolnymi granicami dla obu serwerów: generator obciążenia to współdzielona VM z 60 do 70 % skradzionego czasu procesora, a przy 128 wątkach był blisko własnego limitu, podczas gdy rdzenie robocze urMQTT były zajęte tylko w 12 do 13 %. Stosunek przy 128 klientach (około 2,2 razy) jest najbardziej sensowny; przy 32 i 64 w większości mierzy oczekiwanie klientów. Liczby pamięci nie liczą tego samego (sterta jądra wobec RSS procesu), więc „około 50 razy mniej" to rząd wielkości, a nie dokładny stosunek. Opóźnienie 14 ms to jeden obieg sieci (około 15 ms), a więc „brak mierzalnego czasu brokera"; ogony (p99 około 100 do 200 ms) są u obu brokerów zdominowane przez współdzielone hosty. Różnic poniżej około 20 % nie twierdzimy.

Co nie wypadło na naszą korzyść i zostało w tabelach: pojedynczy strumień TCP przez urMQTT niósł 2 do 8 razy mniej niż przez Mosquitto, ze zmianami od zera do 7,7 tysiąca wiadomości na sekundę między uruchomieniami, a 20-milisekundowy watchdog handlera przerywał żywe połączenia, gdy hipernadzorca zatrzymał vCPU (w konfiguracji produkcyjnej action = "drop", 6 do 8 połączeń na uruchomienie przy zalewaniu QoS 0). Obie sprawy są opisane w następnej sekcji, bo miały przyczyny w naszym kodzie.

Dlaczego pojedynczy strumień był wolny: przyczyny, a nie wymówki

Najłatwiej byłoby powiedzieć „współdzielony VPS". Nie powiedzieliśmy tego, tylko na tym samym VPS-ie i tą samą metodą szukaliśmy przyczyn. Znaleziono pięć, cztery w ścieżce danych i jedną w watchdogu (ADR-221 do ADR-224):

Zatrzymania są prawdziwe: na tym VPS-ie rdzenie 0 do 2 miały medianę 36 do 80 spóźnionych taktów na 5 sekund, a najgorsze zatrzymanie w oknie miało medianę około 70 ms i do 0,9 s (rdzeń 3, baza i dziennik: do 1,55 s), podczas gdy host nie zgłasza skradzionego czasu (host steal 0 us). Dlatego watchdog potrzebował drugiego zegara, a nie większego budżetu.

Watchdog: 148 przerwanych połączeń w 30 obciążonych uruchomieniach przed, 0 w 24 uruchomieniach po; na lokalnym urządzeniu, które opóźnia i gubi ramki, przy stracie 0,1 % pojedynczy strumień 64 B z 14,3k wiadomości/s (jądro z X11) ma teraz 41,0k, a przy 0,5 % z 5,0k na 17,7k.

Czego to nie mówi. urMQTT nadal nie jest szybszy od Mosquitto na pojedynczym strumieniu: przy 64 B publikuje około 80 % jego szybkości, a dostarcza około 40 %, bo odrzuca QoS 0, gdy strumień subskrybenta jest wolniejszy od strumienia wydawcy (Mosquitto bez limitu kolejkuje). Przy 1 KiB w 16-parowym zalewaniu Mosquitto jest z przodu o około 15 %, co mieści się w szumie. Generator znów był współdzieloną VM z 58 do 77 % skradzionego czasu. Druga runda (blokowanie sterty poza ścieżką danych, SACK po stronie wysyłania i inne) jest na niezintegrowanej gałęzi perf-single-flow-wip; jej liczby nie są jeszcze twierdzeniami i tu ich nie podajemy.

Obietnica, której nie składaliśmy, a którą spełniliśmy: konfiguracja jest danymi

Dotąd każda konfiguracja była nowym buildem: klucze i limity były wbudowane w obraz. C1 to odwraca (ADR-215 do ADR-219): jądro buduje się raz, a konfiguracja jest danymi.

• Blob urmqtt-cfg (C1a): wersjonowany, kanoniczny zapis (pola w rosnącej kolejności znaczników, odcisk SHA-256, opcjonalny oddzielny podpis Ed25519), 70 pól z wartościami domyślnymi i granicami, dekoder odrzucający wszystko, co niepoprawne.
• Jądro czyta go jako moduł Limine (C1b), przed czymkolwiek innym, na aarch64 i x86_64. Istnieje jedno wydawane jądro dla każdego ENV oprócz dev (ELF-y aarch64 dla release, prod i bench mają ten sam SHA-256; sprawdzone tylko na aarch64). Wydawane jądro odrzuca konfigurację deweloperską, a bez konfiguracji pisze „refusing to serve" i niczego nie obsługuje.
• Zainstalowany dysk niesie konfigurację i aktualizacja ją zachowuje (C1c).
• urmqtt-config i szablon ISO (C1d): pack, show, verify, a pack --iso zastępuje obie kopie miejsca na konfigurację i 24 skróty modułów w gotowym ISO. Wynik jest bajt w bajt taki sam jak ISO budowane przez mkiso.sh --config. Szablon wydania v0.2.0 ma 63 111 168 bajtów.
• Oświadczenie o zaufaniu (ADR-219): skonfigurowany obraz przy starcie wypisuje odcisk konfiguracji (config: fingerprint ...), a podpis jest opcjonalny i domyślnie wyłączony. Zmienione ISO nie ma oficjalnego skrótu; odcisk to sposób, by zobaczyć, co jest w środku.

Konstruktor na aldo.tech

To samo, co robi urmqtt-config pack --iso, robi strona internetowa, tym samym kodem: biblioteka narzędzi skompilowana do WebAssembly (1,06 MB, bez importów i bez bloku unsafe). Strona jest pod adresem aldo.tech/pl/produkty/urmqtt-builder/ i istnieje we wszystkich 15 językach serwisu (na przykład hr).

• Nic nie opuszcza przeglądarki. Certyfikaty, klucze prywatne i gotowe ISO zostają na komputerze; strona pobiera tylko pliki wydań z tego serwisu, nie ma śledzenia ani skryptów osób trzecich. W teście na żywo żadne żądanie nie niosło materiału kluczowego.
• Lustro wydań (ADR-227): co godzinę (timer systemd, niski priorytet) kopiuje wydania z GitHuba, każde sprawdza przed publikacją, a strona w przeglądarce weryfikuje podpis SHA256SUMS kluczem wbudowanym w stronę, i dopiero potem wpisuje konfigurację do szablonu. Nieudana weryfikacja blokuje pobranie.
• Prosto domyślnie, zaawansowanie w razie potrzeby (ADR-232): pierwszy ekran to trzy kroki (gdzie działa, twoje certyfikaty, nazwa obrazu). Jedno pole do przeciągania plików sortuje certyfikat, klucz i CA według zawartości. Widok zaawansowany otwiera każde z 70 pól, wyszukiwanie, import i eksport TOML; oba widoki edytują ten sam stan. Szablon (63 MB) pobiera się, gdy użytkownik wypełnia formularz. W próbie na żywo, z próbnym lustrem i próbnym kluczem, zbudowanie ISO w przeglądarce trwało 5 do 18 s.

Emulator, opcjonalnie. Obok „Pobierz ISO" stoi „Wypróbuj w emulatorze": QEMU skompilowane do WebAssembly uruchamia właśnie zbudowany obraz w karcie przeglądarki. Nic z niego nie jest pobierane przed kliknięciem (około 3 MB za pierwszym razem). Emulator jest tylko BIOS, bez sieci (żeby ruch użytkownika nie przechodził przez jakiegoś pośrednika i nie naruszał „nic nie opuszcza przeglądarki"), wymaga około 1,5 GB pamięci i przeglądarki na komputerze (testowany Chrome; Firefox i Safari nie). urMQTT dochodzi w nim do URMQTT READY w około 8 s (z pominiętym odliczaniem) i wypisuje ten sam odcisk konfiguracji co strona, co jest dowodem, że uruchomiono właśnie tę konfigurację. Start jest około 2 razy wolniejszy niż w natywnym QEMU na tym samym Macu (0,82 s wobec 1,9 s), a kryptografia około 58 razy wolniejsza, bo instrukcje sprzętowe są emulowane. Dlatego z emulatora nie wyciągamy żadnych twierdzeń o szybkości, a strona mówi to przed uruchomieniem. Przy budowaniu trzeba było załatać cztery bajty w .wasm z powodu błędu w tłumaczeniu instrukcji POPCNT w źródłowym emulatorze (jeszcze go nie zgłosiliśmy); sam emulator jest na GPL, z ofertą kodu źródłowego.

Zwykły MQTT, tylko dla sieci, którym ufasz

Zwykły MQTT (TCP 1883, bez TLS) jest w IoT bardzo częsty: jest domyślny w Mosquitto, w większości firmware'u dla Arduino i ESP, w Tasmocie, Zigbee2MQTT i Home Assistant, a używa się go też wewnątrz segmentowanych sieci przemysłowych, za VPN-em i w prywatnych sieciach LAN, a także na urządzeniach bez zegara (certyfikaty wymagają daty), bez dość flasha lub procesora na TLS. Przez niezaufaną sieć jest niedopuszczalny: kto jest po drodze, czyta i zmienia ruch. Dlatego P1 (ADR-229 do ADR-231) to wyraźny, ograniczony wybór, domyślnie wyłączony, a port TLS zostaje; TLS nie jest tym wyłączany, zwykły port pojawia się obok niego.

• Lista dozwolonych sieci jest obowiązkowa (allow_from, CIDR-y) i sprawdzana przy SYN: poza listą nie ma SYN-ACK ani stanu. Cały internet (0.0.0.0/0) wymaga osobnej, wyraźnej opcji.
• Trzy tryby logowania: hasło (domyślne, gdy włączone; PBKDF2-HMAC-SHA-256, sól, 10 000 iteracji, porównanie w stałym czasie, blokada według adresu), anonimowo (jedna skonfigurowana tożsamość z własnym ACL) i według adresu (ip). Konstruktor haszuje hasło w przeglądarce i w pamięci trzyma tylko skrót.
• Mniej uprawnień niż mTLS: zwykły klient nigdy nie ma uprawnień serwisowych, operatorskich ani zarządzania, nie ma $SYS ani konsoli, ma własne sesje ($plain/<tożsamość>/<id klienta>, tylko czyste), a własne limity i rejestr dozwolonych nadal go obowiązują.
• Co się traci, jest w SECURITY.md: poufność, integralność, uwierzytelnienie brokera i powtórzenie nagranego logowania. Konfiguracją nie da się tego naprawić; tak jest, gdy nie ma TLS.

Zmierzone na laptopie (Apple silicon, HVF, sieć użytkownika QEMU), 16 par, 64 B, trzy uruchomienia po 10 s: przy 8 000 wiadomości na sekundę ścieżka TLS i zwykła dostarczają wszystkie wiadomości z tym samym opóźnieniem (p50 0,17 ms wobec 0,13 do 0,18 ms), nowe połączenia na sekundę: TLS około 2 600 do 2 750, anonimowy zwykły około 4 900 do 7 800, a logowanie hasłem jest drogą częścią: jeden PBKDF2 kosztuje około 2,5 ms, więc liczba nowych logowań jest ograniczona do około 200 na rdzeń danych na sekundę (zmierzono 308 do 342 na dwóch rdzeniach). Zalewanie na tej maszynie nie jest stabilnym instrumentem (20k do 440k dostarczonych na sekundę między uruchomieniami) i nie wyciągamy z niego wniosku. Porównania zwykłej ścieżki z Mosquitto na VPS-ie jeszcze nie zrobiono. Testy: grupa smoke plaintext 7 z 7 na aarch64 HVF i na x86_64 TCG, nowy cel fuzz plain_input (2,3 miliona uruchomień bez znalezisk).

Błędy znalezione przez pracę na żywo

Dwóch rzeczy nie wyłapały testy, ale pierwsze włączenie na prawdziwej stronie:

• Strona szukała plików wydań o jeden katalog za wysoko, więc każda weryfikacja podpisu odpowiadała 404 (poprawka 13af301). Test używał próbnego lustra pod inną ścieżką.
• Klawiatura emulatora nigdy nie dotarła do gościa: przyczyną nie było złe tłumaczenie klawiszy, tylko to, że okno dialogowe w ogóle nie nasłuchiwało klawiszy (poprawka w ADR-232, wraz z wpisem startowym bez klawiszy).

Lekcje

• Szukaj przyczyny, nie obwiniaj otoczenia. Większość słabości pojedynczego strumienia i wszystkie przerwane połączenia były nasze; hipernadzorca jest prawdziwy, ale trzeba go było mierzyć, a nie zakładać.
• Porównanie z innym produktem musi obejmować także straty. Tabela, w której są tylko nasze wygrane, nie byłaby porównaniem.
• Instrument pomiarowy ma granice. Współdzielony generator ze 60 do 70 % skradzionego czasu zmienia to, co liczby znaczą; dlatego piszemy „dolna granica" i nie twierdzimy różnic poniżej 20 %.
• Izolacja nie jest dowodem. SQLite w EL0 zmniejsza to, co może zrobić błąd w nim, a nie to, co może skłamać.
• Prawdziwa instalacja znajduje to, o co testy nie pytają: źle złożoną ścieżkę i klawisze, których nikt nie nasłuchuje.

Co nadal nie jest udowodnione

• Klucz podpisu wydań jest na razie kluczem próbnym; v0.2.0 i v0.2.1 to pre-release, a obrazy przy nich są deweloperskie z próbnymi certyfikatami (poza szablonem, który jest bez konfiguracji).
• 13 tłumaczeń strony konstruktora (i tego tekstu) napisała AI i sprawdziły je testy i próbki, a nie rodzimi użytkownicy języka.
• Porównanie z Mosquitto to jedna sesja, jedna ścieżka i jeden współdzielony generator, na współdzielonym VPS-ie; różnice poniżej 20 % nie są twierdzeniami.
• Zwykła ścieżka nie była mierzona na VPS-ie ani wobec Mosquitto.
• Lighthouse na nowym prostym widoku nie jest potwierdzony (stary widok: dostępność 95 lub więcej).
• Bare metal, koszt workera na x86_64 na KVM, Firefox i Safari dla emulatora: nie mierzono.

Co dalej

• D1: publiczny broker demo. Emulatora z przeglądarki nie możemy uczynić publicznym: żyje w karcie jednego odwiedzającego, jest 20 do 100 razy wolniejszy od KVM, nie ma sieci przychodzącej i znika po zamknięciu karty; przekierowanie internetu do cudzej przeglądarki byłoby też nadużyciem. Możliwy jest prawdziwy broker demo: urMQTT na VPS-ie pod nazwą na aldo.tech, z opublikowanym próbnym CA, ścisłym ACL i małymi limitami. To na razie tylko pomysł, a nie budowa, i wymaga wyraźnej zgody na publiczne wystawienie.
• Druga runda dla pojedynczego strumienia (gałąź perf-single-flow-wip): dopiero gdy zostanie zmierzona na VPS-ie i scalona.
• Zwykła ścieżka wobec Mosquitto na VPS-ie, logowanie i unieważnianie kont dla zwykłego MQTT przez podpisany kanał zarządzania.
• Po wydaniu: bare metal (X12 do X16), IOMMU i Secure Boot, szyfrowanie dysku.

Kod jest na github.com/zeljan-alduk/urMQTT, a docs/PROGRESS.md nadal jest jedynym źródłem prawdy o tym, co naprawdę działa, docs/PERFORMANCE.md o tym, co zmierzono. Pre-alfa, tak jak wcześniej; zgłoszenia błędów i zgłoszenia dotyczące bezpieczeństwa według wskazówek w SECURITY.md są mile widziane.

Jedna uwaga na wstępie: projekt nadal jest w fazie pre-alfa. Liczby w tekście mierzą kod i testy, a nie dojrzałość produkcyjną, a pierwsze wydanie jest celowo ograniczone do VPS-ów z KVM. Bare metal zostaje na później.

Jak to wyglądało w czasie

Pierwszy commit powstał 28 października 2026 o 23:48 (M0). Do 31 października, godz. 23:00, w repozytorium jest 119 commitów, rozłożonych jako 3, 39, 38 i 39 na kolejne dni kalendarzowe. Od razu powiedzmy, jak to możliwe: projekt powstaje z Claude Code, a commity mają trailery Co-Authored-By: Claude. Cztery dni kalendarzowe historii nie znaczą, że jedna osoba napisała w cztery dni 90 000 linii; znaczą, że plan, implementacja, testy i ADR-y powstają w krótkich, zamkniętych pętlach, a każdy krok kończy się tym samym rytuałem weryfikacji co wcześniej. Liczby poniżej mówią o ilości kodu i testów, a nie o tym, ile z tego zostało sprawdzone w prawdziwej pracy.

Wykres pokazuje trzy krzywe, które rosną niemal razem, i to jest zamierzone: testy i zapisane decyzje nadążają za kodem, a nie zostają w tyle. Nachylenie jest największe 29 października, kiedy powstaje cała droga od jądra do brokera. Później linii przybywa wolniej, ale testy rosną szybciej niż kod (27 testów na 1,6 tys. linii na początku, 739 na 89,8 tys. dziś).

Linie to wszystkie pliki .rs poza vendor/ i fuzz/, a testy to funkcje #[test]. Co dodał każdy etap, według dat z historii gita:

Obietnica 1: jedno ISO dla wielu platform

Co planowaliśmy. Jeden plik, który startuje na aarch64 UEFI, x86_64 UEFI i x86_64 BIOS. Co zbudowaliśmy. Port na x86_64 (X0 do X10) i uniwersalne ISO z bootloaderem Limine, jeden hybrydowy obraz, z którego startują wszystkie te kombinacje; smoke testy uruchamiają go na czterech maszynach wirtualnych. Menu ma trzy pozycje: urMQTT (tryb live, działa z RAM-u, nic nie zapisuje na dysku), instalacja na dysku maszyny, na której jest uruchomione (instalacja zapisuje GPT i dane, po czym wyłącza maszynę) oraz Diagnostyka (wykrywanie sprzętu i pomiary).

Pierwszym prawdziwym celem był VPS, a nie fizyczny komputer: decyzja brzmi, że pierwsze wydanie obsługuje tylko VPS (KVM), a bare metal przychodzi po nim. Testowaliśmy na VPS-ie Contabo z procesorem AMD EPYC (rodzina 23, Zen 1), 4 vCPU i 8 GiB RAM, z siecią virtio-net i dyskiem virtio-scsi. Pierwsza próba nas zaskoczyła: ISO podłączone jako wirtualny CD uruchamiało domyślną pozycję, obraz produkcyjny odmówił pracy z nośnika tylko do odczytu i się zresetował, więc dostaliśmy nieskończoną pętlę menu, jądro, reset, bez niczego czytelnego. Dziś błąd krytyczny w obrazie produkcyjnym zostawia komunikat na konsoli na 60 sekund przed resetem, a z nośnika optycznego wypisuje, że uruchomiono z nośnika tylko do odczytu, i się zatrzymuje. Tryb live w RAM-ie (O3) obszedł później ten problem w typowym przypadku.

Pozycja diagnostyczna wzięła się z tego doświadczenia: maszynę, której nie widzimy, musimy móc zapytać, co ma. Wypisuje CPU, RAM, sieć, dyski i urządzenia PCI, mierzy przepustowość pamięci, dysk i kryptografię, a te same pomiary wypisuje jako JSON na port szeregowy. Zapis na dysk jest dozwolony tylko w nieprzydzielonym obszarze i dopiero po wpisaniu WIPE; na zrzucie poniżej to pominięto.

Co jest otwarte. Prawdziwy sprzęt. Po pierwszym wydaniu przyjdzie bare metal (start z USB, NVMe i AHCI, karta sieciowa prawdziwego komputera), razem z IOMMU i Secure Boot, bo bez IOMMU złośliwe lub wadliwe urządzenie może zapisywać w całej pamięci. W tej wersji niczego na ten temat nie twierdzimy.

Uzgadnianie: od 1,2 ms do 0,24 ms

Pierwszy pomiar diagnostyki na VPS-ie dał niewygodną liczbę: uzgadnianie mTLS, wyłącznie kryptografia po stronie serwera, trwało 1,2 ms. Na aarch64 używaliśmy już sprzętowych instrukcji AES i SHA, ale x86_64 nie miał nic podobnego dla kluczy publicznych: RustCrypto jest przenośne i constant-time, a przez to także wolne. Zmieniły to trzy kroki.

• Dla P-256 przejęliśmy asembler nistz256 z OpenSSL i ring (ADR-130), z tablicami o stałej bazie do podpisywania i weryfikacji podpisu CA (ADR-110, ADR-111).
• X25519 został przepisany na cztery 64-bitowe kończyny z instrukcjami MULX/ADX (ADR-131).
• Następnie sprofilowaliśmy resztę (ADR-132, ADR-200).

Liczby różnią się między uruchomieniami o około 10%, więc zapisaliśmy zakres zamiast jednej wartości. W sumie to mniej więcej pięć razy mniej czasu CPU na uzgadnianie.

Czego nauczył nas memcpy. Gdy kryptografia spadła, profil pokazał coś, czego się nie spodziewaliśmy: funkcje mem* (memcpy, memmove, memset) zajmowały 7% uzgadniania, 13 do 39% ścieżki rekordu TLS (39% dla 64 B, 13% dla 4 KiB) i 17 do 34% rozdzielania PUBLISH. Zastąpiliśmy je asemblerem SSE2 dla x86_64 (ADR-200), z testami różnicowymi względem implementacji referencyjnej dla wszystkich rozmiarów, wyrównań i nakładania się. Na wywołanie to 55 do 75 cykli wobec 7 do 12 dla 1 do 64 bajtów.

Jak czytać wykres: im mniejszy rekord, tym większa część czasu idzie na kopiowanie, więc tym większy zysk. Dla małych wiadomości, które stanowią większość ruchu MQTT, to właśnie ma znaczenie.

Czego to nie oznacza. Na natywnym x86_64 mierzyliśmy OpenSSL 3.5.5 (ADR-130) wyłącznie jako punkt odniesienia dla asemblera, a nie jako porównanie produktów. Porównania Linux plus Mosquitto na tym samym VPS-ie (zadanie X11) jeszcze nie zrobiliśmy. Dlatego nie twierdzimy, że urMQTT jest szybszy od Linuksa: nie zostało to zmierzone. Powyższe liczby porównują urMQTT z nim samym.

Przeciążenie było drugim wynikiem. Na VPS-ie, z jednego Maca (RTT 35 ms), 128 klientów dało 618 uzgodnień na sekundę, 256 klientów 393, a 512 klientów 67, przy tysiącach odrzuconych połączeń. To nie było plateau, tylko załamanie. Przyczyny znaleźliśmy w kodzie (dwie potwierdzono w QEMU/HVF, na VPS-ie nie dało się ich odtworzyć), kilka naraz: odrzucone połączenie wracało do klienta przez kolejny segment niosący ważne ciasteczko SYN, odrzucenie przez RST mówiło klientowi, żeby od razu spróbował ponownie, a odbiór był O(kolejka). Poprawka (ADR-080 do ADR-082) porzuca SYN, który i tak nie zostałby przyjęty, zapamiętuje odrzucone przepływy, utrzymuje odbiór w O(1) i liczy uzgodnienia na rdzeń. Możliwe (hipoteza, niesprawdzona), że część przyczyny leżała też po stronie klienta: narzędzie do obciążenia zamykało połączenia pierwsze, więc jeden Mac z 16 384 portami efemerycznymi i TIME_WAIT wynoszącym 30 sekund jest ograniczony do około 550 połączeń na sekundę. Dlatego prawdziwego limitu serwera jeszcze nie zmierzyliśmy.

Obietnica 2: surowy dysk, ale ostrożnie

Co planowaliśmy. Zachować własny układ bez systemu plików i dodać wszystko, co system plików zwykle daje: wyrównanie, rozrost, discard, kopie zapasowe i kontrole. Dlaczego nie system plików. Rozmawialiśmy o tym i decyzja została potwierdzona: urMQTT zapisuje jedną bazę, jeden dziennik telemetrii i własne metadane, nie potrzebuje katalogów, uprawnień ani nazw plików, a każda dodatkowa warstwa to kolejny kod w zaufanej części i kolejny sposób, by zapis po cichu zniknął. Dysk to GPT z partycją ESP i jedną partycją danych urMQTT, na której jest własny układ.

Co zbudowaliśmy (S2 do S6).

• Układ v2 (S2). Topologia dysku, wyrównanie do 1 MiB lub optymalnego rozmiaru I/O, całe bloki fizyczne, para superbloków A/B z generacją (ADR-140). Układ v1 jądro odrzuca z czytelnym komunikatem, a migruje go narzędzie offline urmqtt-disk migrate (ADR-141): domyślnie jest to przebieg próbny, kopiuje się, a dopiero potem przełącza, z wycofaniem i wstrzykiwaniem błędów przy każdym zapisie.
• Rozrost (S3). Przy starcie dysk może urosnąć (nigdy się nie zmniejsza), a na virtio-blk także w trakcie pracy, przez przerwanie zmiany konfiguracji (ADR-142, ADR-143).
• Discard i write-zeroes (S4). Dyski z cienkim przydziałem oddają miejsce hostowi. W teście plik qcow2 na hoście spadł z 62 do 16 MiB po wygaśnięciu segmentów telemetrii, a odzyskiwanie nigdy nie ufa zawartości, która została odrzucona.
• Kopia zapasowa bazy na dysku (S5). Kopia A/B za pomocą API online backup SQLite w krokach po 16 stron: najdłuższy krok 4,6 ms wobec 445 ms przy kopiowaniu jednym wywołaniem. Commity w trakcie kopii miały maksimum 2,4 ms wobec 2,2 ms bez niej. Jeśli quick_check przy starcie się nie powiedzie, baza jest przywracana z kopii.
• Scrubbing i ograniczony start (S6). Scrubber czyta dysk w ramach ograniczonego budżetu I/O i zgłasza uszkodzone rekordy, a start czyta tylko najnowszy segment każdej partycji, więc czas startu nie rośnie wraz z rozmiarem regionu telemetrii. Zamknęliśmy w ten sposób problem, który policzyliśmy z góry: na dużym dysku pełne odzyskiwanie trwałoby od minut do dziesiątek minut.

Cała grupa smoke testów przechowywania przechodzi na obu architekturach: 79 udanych, 0 nieudanych, na aarch64 pod HVF i na x86_64 pod TCG. Zmierzyliśmy też, że S4 nie spowolnił bazy: 53,3 tys. wstawień na sekundę w paczkach przed i po, bez mierzalnej różnicy.

Co zaskoczyło. Ile z „prostego" układu to przypadki brzegowe: virtio-scsi i virtio-blk zgłaszają topologię na różne sposoby, a niepełny zapis w środku migracji musi zawsze zostawić co najmniej jedną ważną wersję. Dlatego każdy zapis na ścieżce migracji i rozrostu przeszedł wstrzykiwanie błędów.

Co jest otwarte. Strony SQLite nie mają sumy kontrolnej, więc zmiana bitu wewnątrz wartości w wierszu nie zostanie przez bazę wykryta; rekordy telemetrii i zawartość kopii mają CRC i są wykrywane. Szyfrowanie dysku (S7) nie jest gotowe.

Obietnica 3: bezpieczeństwo, które da się udowodnić, na ile się uda

Utwardzanie (H4). Alokator zeruje zwolnioną pamięć i sprawdza ją przy ponownym użyciu, wykrywa podwójne zwolnienie, wiąże wskaźniki listy wolnych przez XOR i zeruje klucze przy zwolnieniu (ADR-170). Ochrona stosu (-Zstack-protector=strong, 1315 funkcji, a SQLite z -fstack-protector-strong, ADR-171). Raporty błędów w produkcji nie zawierają rejestrów ani adresów (ADR-172). KASLR na obu architekturach: jądro jest PIE, a Limine przesuwa je o około 19 bitów, losowo ustawiane są sterta, stosy i okno MMIO (ADR-173). Na aarch64 MTE oznacza stertę (ADR-174), ale tylko pod TCG: HVF i x86 go nie mają. kCFI oceniliśmy i nie przyjęliśmy, bo kompilator na przypiętym nightly wywala się z błędem wewnętrznym; IOMMU odłożono razem z bare metalem (ADR-175, ADR-176).

Koszt jest zmierzony, a nie założony. Na ścieżce uzgadniania (dp-bench, aarch64 HVF, pełne uzgadnianie TLS 1.3 + mTLS + CONNECT):

W sumie koszt na ścieżce uzgadniania to więc około 5% dla części mierzonych czysto, a z PIE i oznaczaniem wychodzi około 7% na jednym i około 11% na czterech rdzeniach, ale ten pomiar jest zaszumiony. Uważamy go za akceptowalny, lecz nie powtórzyliśmy go na VPS-ie x86_64.

Warto porównać z liczbą z pierwszego tekstu (862 uzgodnienia na sekundę na jednym rdzeniu). To samo narzędzie dziś, ze sterownikiem sprzętowego szyfrowania na aarch64 (X0b) i serią przyspieszeń, które przyszły od tamtej pory, daje 1941 przed utwardzaniem. Nie wyodrębniliśmy wkładu każdej zmiany, więc o przyczynie nic nie twierdzimy.

Jak to sprawdzono, a czego nie. H5 dodał Miri na podzbiorze crate'ów hosta, dowody Kani, sanitizery, model-fuzzer dla ACL i raporty pokrycia. Kani udowodnił record_len w TLS, parse w TCP i dwie arytmetyki koła timerów. Nie udowodniono (przekroczony czas): obu dekoderów MQTT, obu parsowań konfiguracji i zachowania koła timerów; zadanie CI dla Kani dlatego jeszcze nie blokuje. Miri nie potrafi wykonywać asemblera. Łańcuch dostaw (H9): SBOM CycloneDX z 215 komponentami, cargo-vet przechodzi z 39 w pełni zrecenzowanymi i 140 wyjątkami, a cargo-deny jest skonfigurowany tak, by traktować zalecenia o podatnościach jako błąd CI (te zadania CI były dotąd sprawdzone tylko lokalnie, nie na GitHubie, a test negatywny nie został uruchomiony), wraz z VULNERABILITY-HANDLING.md. Szczery stan: ze 67 wersji crate'ów zewnętrznych linkowanych do jądra 53 to wyjątki, a nie recenzje. Vet dowodzi, że zbioru zależności nie da się zmienić bez widocznej różnicy, a nie że TCB został przejrzany. Własnej recenzji żadnego crate'a nie napisaliśmy.

SNTP (T1) jest pod tym względem małą opowieścią o bezpieczeństwie: jest opcjonalny, tylko wobec prywatnych serwerów IPv4, z maksymalnym skokiem i warunkiem zgodności źródeł (mediana, większość w ciągu jednej sekundy). Zegar, który ktokolwiek po drodze może przesunąć, nie jest zegarem, któremu wolno ufać przy ważności certyfikatów.

Na Macu: aarch64 natywnie i x86_64 przez emulację

Rozwijamy na Macu, a ten ma dwa sposoby uruchamiania tego samego kodu i bardzo się one różnią.

Zasada jest prosta: liczby pod TCG to emulacja i nie cytujemy ich jako wydajności. Wydajność x86 mierzymy tylko na prawdziwym VPS-ie. Dlatego liczby kryptograficzne powyżej pochodzą z VPS-a Contabo, a nie z Maca.

Lekcje

• Mierz na prawdziwej maszynie, zanim zaczniesz optymalizować. Pierwsze podejście polegało na optymalizowaniu tego, co uważaliśmy za wolne; dopiero diagnostyka na VPS-ie pokazała 1,2 ms i gdzie dokładnie ucieka czas.
• Przeciążenie to osobna cecha. System szybki pod obciążeniem może się załamać powyżej niego; odrzucenie musi być tańsze niż przyjęcie.
• Profil zaskakuje. Największy pojedynczy zysk dla małych wiadomości nie był w kryptografii, tylko w kopiowaniu pamięci.
• Dysk bez systemu plików wymaga więcej pracy, nie mniej. To, co system plików zwykle daje (wyrównanie, rozrost, discard, kopie, kontrole), musimy napisać i sprawdzić sami, każdy krok ze wstrzykiwaniem błędów.
• Uczciwość w liczbach. Pomiary pamięci na współdzielonym VPS-ie wahają się nawet do 10 razy między uruchomieniami i nic nie mówią o kodzie, więc ich nie podajemy. Liczby kryptograficzne są stabilne do około 10%.
• Tempo rozwoju to nie dojrzałość. Testy i ADR-y rosną razem z kodem, ale cztery dni to nie jest prawdziwa eksploatacja.

Co dalej

• H6: SQLite wyizolowany na poziomie EL0, tak aby błąd w bazie nie otwierał jądra.
• H7: reszta bezpieczeństwa czasu (NTS i obsługa skoków); SNTP to dopiero pierwszy krok.
• X11: porównanie z Linuksem i Mosquitto na tym samym VPS-ie, dopiero wtedy ma sens mówić o względnej szybkości.
• Wydanie: pierwsza publiczna wersja dla VPS (KVM), z podpisanymi artefaktami i instrukcjami.
• Po wydaniu: bare metal (X12 do X16), IOMMU i Secure Boot oraz szyfrowanie dysku.

Kod jest na github.com/zeljan-alduk/urMQTT, a docs/PROGRESS.md nadal jest jedynym źródłem prawdy o tym, co naprawdę działa. Pre-alfa, jak poprzednio; zgłoszenia błędów i zgłoszenia dotyczące bezpieczeństwa zgodnie z instrukcją w SECURITY.md są mile widziane.

Tak powstał urMQTT: unikernel, który jest brokerem MQTT. Jądro, TCP/IP, TLS 1.3, MQTT i wbudowana baza danych w jednym programie binarnym napisanym w Rust, uruchamianym z jednego obrazu ISO. Bez procesów, bez wywołań systemowych, bez powłoki. Pierwszą platformą, na której powstaje i jest testowany, jest aarch64, a ten sam kod zmierza w stronę x86_64, przez UEFI i klasyczny BIOS, oraz prawdziwego sprzętu: celem jest jeden ISO, który uruchamia się na tym wszystkim. Projekt jest open source na licencji MIT lub Apache 2.0, a w tym tekście chcemy zapisać, gdzie jesteśmy, jak jest zbudowany od środka i czego przy okazji się nauczyliśmy.

Co dokładnie oznacza „unikernel"

Typowy broker to program działający na systemie operacyjnym. urMQTT nie ma pod sobą żadnego systemu operacyjnego: sam startuje przez firmware UEFI i bootloader Limine, ustawia własne tablice stron, programuje kontroler przerwań i timer, odnajduje urządzenia virtio przez PCIe, uzyskuje adres przez DHCP i nasłuchuje na jednym porcie. Wszystko, co normalnie robiłyby jądro, sterowniki, stos sieciowy i aplikacja, jest tutaj jednym plikiem ELF działającym na poziomie EL1.

Porównanie z typową instalacją mówi samo za siebie:

Priorytety są następujące, w tej kolejności: bezpieczeństwo, skalowalność, wydajność wielordzeniowa, mały ślad i niezmienna instalacja. Gdy dwa cele wchodzą w konflikt, wygrywa ten, który jest wyżej na liście.

Gdzie jesteśmy teraz

Projekt jest w fazie pre-alfa, ale zamknęliśmy siedemnaście kamieni milowych, od M0 do M17. Dziś urMQTT obsługuje MQTT 3.1.1 przez TLS 1.3 z obowiązkowymi certyfikatami klienta, a stan przechowuje w SQLite na surowym dysku. W skrócie, co już działa:

• Jądro: własne wektory wyjątków z zdekodowanymi raportami, własne tablice stron z egzekwowanym W^X, strony ochronne, PAC i BTI tam, gdzie procesor je ma, GICv3 i GICv2, timer ogólnego przeznaczenia, SMP do 64 rdzeni.
• Wykrywanie sprzętu z DTB lub ACPI do jednego opisu platformy, z identycznym wynikiem z obu źródeł.
• Sterowniki: PCIe ECAM, MSI-X, virtio-net, virtio-blk, virtio-scsi i virtio-rng oraz CSPRNG zasilany sprzętową entropią.
• Sieć: własne DHCPv4, ARP, ICMP i rygorystyczne IPv4, a do tego własny TCP wyłącznie po stronie serwera: ciasteczka SYN, hierarchiczne koło timerów, NewReno, łączenie ACK, bez stanu TIME_WAIT.
• TLS: wyłącznie TLS 1.3, obowiązkowe mTLS, tożsamość urządzenia z CN lub SAN URI; uzgadnianie obsługuje rustls, a po nim działa własna warstwa rekordów z AES-128-GCM i ChaCha20-Poly1305. Wznawianie sesji biletami PSK, lista unieważnień, kontrola przyjęć już na etapie uzgadniania.
• MQTT: kodek bez kopiowania, fuzzowany i testowany z prawdziwymi klientami mosquitto; QoS 0 i 1, symbole wieloznaczne, wiadomości zatrzymane, testament (LWT), trwałe sesje, ACL ograniczone do devices/{id}/#, limity szybkości na urządzenie.
• Przechowywanie: SQLite wewnątrz jądra przez VFS nad surowym dyskiem, w trybie WAL, ze sprawdzeniem integralności przy starcie; rejestr urządzeń, unieważnienia, wiadomości zatrzymane, trwałe sesje z kolejkami wiadomości dla urządzeń offline; osobny dziennik telemetrii na każdy rdzeń z CRC na zapis i odzyskiwaniem po awarii.
• Eksploatacja i nadzór: timer nadzorczy dla procedur obsługi, kontrola stanu, ograniczone logowanie, syslog i statsd przez UDP, kontrola przyjęć, która przetrwa burze ponownych połączeń.
• Dostawa: bitowo identyczne ponowne kompilacje weryfikowane w CI, ISO i surowy obraz dysku GPT, podpisy minisign, instrukcje dla KVM, Proxmox i Hetzner.

Każdy krok jest oznaczony kamieniem milowym, który go wprowadził, a plik docs/PROGRESS.md w repozytorium jest jedynym źródłem prawdy o tym, co naprawdę działa.

Architektura w trzech obrazach

Cały projekt jest opisany w docs/ARCHITECTURE.md, a powody każdej ważniejszej decyzji zapisane są jako ADR w docs/DECISIONS.md. Poniżej przegląd.

Warstwy

Od góry do dołu: broker (sesje, drzewo tematów, QoS, wiadomości zatrzymane, testamenty, ACL, limity), kodek MQTT, TLS, TCP, warstwa sieciowa, a następnie sterowniki. Obok tej głównej ścieżki znajduje się przechowywanie (SQLite i dziennik telemetrii), a pod spodem zarządzanie pamięcią, wykrywanie platformy i konfiguracja zamieniona w czasie kompilacji na stałe, razem z wbudowanym certyfikatem CA, certyfikatem serwera i kluczem. Jedyne, co leży poza obrazem, to hipernadzorca z urządzeniami virtio.

Wątek na rdzeń, bez współdzielonego stanu

Każdy rdzeń danych prowadzi własną pętlę z własnym stosem TCP, stanami TLS, fragmentem brokera (sesje i drzewo tematów), pamięcią podręczną sterty i partycją telemetrii. Rdzenie nie współdzielą żadnego zmiennego stanu, a jedynie ograniczone pierścienie bez blokad, po jednym dla każdej uporządkowanej pary rdzeni. Najwyższy rdzeń uruchamia SQLite i nic więcej.

Karta sieciowa ma dziś jedną parę kolejek, którą obsługuje rdzeń 0. Kieruje on każdy strumień MQTT, według skrótu Toeplitz jego czwórki, na jeden z rdzeni roboczych i wysyła to, co rdzenie robocze zwrócą. Sesja żyje na swoim rdzeniu macierzystym, wyznaczonym skrótem identyfikatora klienta, więc przejmowanie, testamenty i trwałość nigdy nie przekraczają granic rdzeni. Połączenie, które trafi na inny rdzeń, zachowuje tam swój TCP i TLS, a zwykły MQTT przekazuje rdzeniowi macierzystemu z kontrolą przepływu opartą na kredytach. Każda skierowana wiadomość jest też rozsyłana do pozostałych fragmentów brokera, z których każdy utrzymuje replikę wiadomości zatrzymanych.

Ten model spinają trzy zasady. Obsługa do końca: odebrany pakiet jest przetwarzany w całości na jednym rdzeniu, od TCP przez deszyfrowanie TLS w miejscu, parsowanie MQTT i routing aż do zaszyfrowanej odpowiedzi, bez kolejek zadań i bez kopiowania do buforów aplikacji. Adaptacyjne odpytywanie: pod obciążeniem kolejki odbiorcze są aktywnie odpytywane, a w bezczynności rdzeń wraca do przerwań i WFI; procedury obsługi przerwań jedynie potwierdzają przerwanie i oznaczają pracę. Timer nadzorczy: takt 10 ms na rdzeń wyłapuje procedury obsługi, które przekraczają swój budżet.

Życie jednego PUBLISH

Urządzenie wysyła rekord TLS. Karta sieciowa przekazuje go pętli rdzenia deskryptorem, bez kopiowania. Pętla sprawdza TCP, deszyfruje TLS w miejscu i parsuje MQTT z pożyczonego bufora, po czym w pamięci sprawdza ACL, limit szybkości i ścieżkę przez drzewo tematów. Jeśli temat interesuje inny rdzeń, ten otrzymuje komunikat routingu z odwołaniem do ładunku i identyfikatorem tematu; baza dostaje wpis telemetrii lub aktualizację wiadomości zatrzymanej, w paczce. Odpowiedź PUBACK jest szyfrowana bezpośrednio do wychodzącego bufora i łączona z TCP ACK, więc do urządzenia wychodzi jeden segment. Inny rdzeń kosztuje wiadomość jedno szyfrowanie na subskrybenta w chwili wysyłki.

Ile kosztuje jedno połączenie

Celem jest najwyżej 512 bajtów na bezczynne połączenie TLS, z dążeniem do 256. Gdy połączenie spoczywa, nic dla niego nie jest trzymane w buforze: odebrane dane przetwarzane są bezpośrednio z ramki sieciowej, a bufory wysyłania, rekordów i MQTT istnieją tylko wtedy, gdy coś jest niedokończone lub niepotwierdzone. Jądro samo to mierzy: dokładne liczniki sterty w żądanych bajtach i w blokach, które faktycznie zajmuje, zapisywane co dziesięć sekund jako sterta ponad poziom bazowy na otwarte połączenie.

Zmierzone pod HVF z czterema rdzeniami wirtualnymi, z czego trzy robocze, przy czym każde urządzenie utrzymuje połączenie mTLS i jedną subskrypcję z QoS 1, wraz z zaokrągleniami alokatora:

Pula ramek sieciowych ma stały rozmiar około 2 MiB, co daje mniej więcej 200 B na połączenie przy dziesięciu tysiącach połączeń i około 2 B przy milionie. Więcej nie udało nam się zmierzyć: sieć użytkownika QEMU na macOS przestała przyjmować połączenia na 10 197, mniej więcej przy granicy 10 240 deskryptorów procesu QEMU. Wartość maleje, gdy stałe części rozkładają się na więcej połączeń, więc nie rośnie wraz z ich liczbą.

Model bezpieczeństwa

Bezpieczeństwo jest pierwszym priorytetem i wygrywa wszystkie konflikty z pozostałymi celami. Model ma kilka warstw:

• Jeden port. TCP 8883, wyłącznie TLS 1.3, obowiązkowe certyfikaty klienta podpisane przez CA wbudowane w obraz. Identyfikator klienta MQTT musi być równy identyfikatorowi urządzenia z certyfikatu.
• Brak wejść. Brak powłoki, wejścia z konsoli, SSH, API administracyjnego, kodu dynamicznego, SQL dostępnego z sieci i systemu plików.
• Bezpieczeństwo pamięci. Rust, z forbid(unsafe_code) w pakietach protokołów; każdy blok unsafe ma komentarz // SAFETY: weryfikowany przez lint, a na dane zewnętrzne nie ma paniki: clippy w pakietach na ścieżce danych zakazuje unwrap, expect, indeksowania i panic!.
• Łagodzenie skutków exploitów. W^X jest egzekwowane przez kodowanie deskryptorów i bit SCTLR_EL1.WXN oraz audytowane przy każdym starcie. Tablice stron po uruchomieniu są tylko do odczytu, bez zapisywalnego aliasu. Dolna połowa przestrzeni adresowej jest wyłączona. Każdy stos ma strony ochronne, a wyjątki działają na osobnym stosie. PAC i BTI włączają się, gdy procesor je obsługuje, co weryfikują testy dymne.
• Odporność na nadużycia. Ciasteczka SYN; kontrola przyjęć odrzuca nowe połączenia, przed jakąkolwiek kryptografią, gdy sterta jest niska, gdy baza zalega, gdy zbyt wiele uzgodnień trwa na rdzeń lub na adres źródłowy albo gdy tempo uzgodnień jest zbyt wysokie. Limity szybkości na urządzenie, ograniczone kolejki, okno TCP powiązane z przeciwciśnieniem brokera, ograniczone logowanie, timer nadzorczy i kontrola stanu.
• Niezmienność. Konfiguracja, CA i klucz serwera są wbudowane w obraz. Zmiana czegokolwiek oznacza nowy obraz.

Model zagrożeń jest zapisany w docs/SECURITY.md.

Przechowywanie bez systemu plików

Dane żyją na osobnym dysku, virtio-blk lub virtio-scsi, na którym nie ma systemu plików. Układ jest minimalny i własny:

LBA 0      [ superblok: magia · wersja układu · uuid · tablica regionów · CRC-32C ]
LBA 8, 16  [ tablica rozmiarów plików, sloty A/B (wygrywa najnowszy poprawny) ]
LBA 64     [ główna baza SQLite ½ ][ SQLite WAL ⅛ ][ dziennik 1 MiB ][ dziennik telemetrii: 8 partycji … ]
ostatnie 4 KiB [ przestrzeń do autotestu urządzenia blokowego przy starcie ]

SQLite (dołączona wersja 3.54.1, ze sprawdzeniem skrótu podczas kompilacji) jest kompilowany do jądra za pomocą clang, bez biblioteki standardowej, i używa stałej sterty memsys5. Jego VFS odwzorowuje trzy stałe pliki na regiony dysku. Działa w trybie WAL z locking_mode=EXCLUSIVE, więc nie potrzebuje indeksu w pamięci współdzielonej, oraz z synchronous=FULL; jeśli quick_check przy starcie znajdzie błąd, system zatrzymuje się w bezpieczny sposób. W bazie znajdują się rejestr urządzeń, unieważnienia, wiadomości zatrzymane i trwałe sesje z kolejkami wiadomości QoS 1 dla urządzeń, które nie są połączone.

Rdzeń bazy, ten o najwyższym numerze, uruchamia SQLite i nic więcej. Płaszczyzna danych wysyła mu zmiany stanu przez pierścień SPSC bez blokad; on zbiera je w jedną transakcję co 5 ms lub co 512 operacji i zwraca potwierdzenia drugim pierścieniem. Pusty dysk jest formatowany przy pierwszym starcie; wszystkiego innego nigdy się nie nadpisuje formatowaniem.

Telemetria idzie inną drogą. Każdy przyjęty PUBLISH na tematach z storage.telemetry_topics trafia do partycji dziennika telemetrii swojego rdzenia: pierścienia segmentów z CRC na zapis, osolonego numerem sekwencyjnym segmentu, tak aby stare przebiegi pierścienia nigdy nie pojawiły się ponownie. Rdzenie przekazują zapisy bazie własnym pierścieniem, bez kopiowania, a ona zrzuca je co 5 ms lub co 256 KiB. Przy starcie odzyskiwanie zachowuje każdy zrzucony zapis, odcina niedokończony ogon i kontynuuje w nowym segmencie. Retencja działa według rozmiaru, przez pierścień, i według wieku, przez retention_days. Sprawdziliśmy to z milionem zapisów i z kill -9 w trakcie zapisu.

Liczby

Narzędzie do generowania obciążenia w tools/loadgen robi trzy rzeczy: burzę uzgodnień TLS 1.3 z mTLS i CONNECT, długotrwałe połączenia z PINGREQ, które co sekundę publikują telemetrię, oraz burze ponownych połączeń. make bench na Apple M4 Pro pod HVF daje:

Wartość w gościu, gdzie klient i serwer są wewnątrz tej samej maszyny wirtualnej, a każdy rdzeń roboczy pracuje sam dla siebie, pokazuje, że płaszczyzna danych skaluje się liniowo. Wartość sieciowa jest ograniczona jednowątkową siecią użytkownika QEMU, a nie gościem; zapisaliśmy to jako ADR-032.

Burze ponownych połączeń testujemy tak, że wszystkie urządzenia łączą się naraz, ponawiają odrzucone próby z opóźnieniem, a potem wszystkie padają bez DISCONNECT. Parametr heap_limit_mb= w trybie deweloperskim sprawia, że kontrola przyjęć uważa stertę za mniejszą, niż jest, więc burzę większą niż sterta można wypróbować przy niewielu gniazdach. W jednej takiej rundzie z 3 000 urządzeń połączyło się 1 368 w 36 sekund, a 5 619 prób zostało należycie odrzuconych, przy limicie 8 MiB; pamięć po burzy wróciła do poprzedniego stanu.

Jak pracujemy

Projekt prowadzi pisana specyfikacja, PROMPT.md, z planem kamieni milowych, a każdy kamień milowy kończy się tym samym rytuałem: make check i make smoke na zielono, jeden commit z oznaczeniem M<n>, wpis w docs/PROGRESS.md i ADR dla każdej decyzji, która nie jest oczywista. Zasady są krótkie i nie negocjujemy ich: brak paniki na dane zewnętrzne, unsafe tylko w pakietach sprzętowych i FFI oraz zawsze z komentarzem, brak alokacji na gorącej ścieżce, komentarz przy każdym porządku operacji atomowych, każde ograniczenie pochodzi z konfiguracji, a celowo tymczasowe fragmenty zawodzą głośno.

CI robi więcej, niż bylibyśmy w stanie ręcznie: fmt, clippy dla hosta i dla aarch64-unknown-none, typos, actionlint i shellcheck; testy na Linuksie i macOS na arm64; kompilację jądra dla konfiguracji deweloperskiej i produkcyjnej z rozmiarem ELF w podsumowaniu; start pod QEMU ze wszystkimi scenariuszami testu dymnego i zapisem dzienników szeregowych; cargo-deny dla zaleceń, licencji i źródeł; minutę fuzzingu na każdy z jedenastu celów, a nocą dziesięć minut na cel z korpusem w pamięci podręcznej. Do tego CodeQL, OpenSSF Scorecard, Dependabot i wydanie z pochodzeniem SLSA. Każda cudza akcja jest przypięta do pełnego SHA commita.

Powtarzalność rozumiemy dosłownie: make repro buduje HEAD dwukrotnie w świeżych drzewach roboczych i porównuje ELF, ISO i surowy obraz bajt po bajcie. Wydania są podpisane minisign, a artefakty można zweryfikować przez gh attestation verify. Obraz produkcyjny zawiera klucz prywatny serwera, więc sam ISO jest tajemnicą; obrazy dołączone do wydań na GitHubie są deweloperskie, z kluczami tymczasowymi, i służą wyłącznie do wypróbowania.

Czego się nauczyliśmy

Kilka lekcji, które zmieniły plan:

• Własny TCP jednak się opłacił. Prototyp działał na smoltcp i dobrze nam służył do M13. Ale serwer utrzymujący setki tysięcy połączeń nie potrzebuje klienckiego TCP, potrzebuje ciasteczek SYN, koła timerów i stanu o rozmiarze 96 bajtów. W M14 zastąpiliśmy smoltcp własnym stosem wyłącznie po stronie serwera, z testami symulowanych strat i fuzzingiem segmentów.
• Mierzcie pamięć od środka. Szacunki na połączenie były bezużyteczne, dopóki jądro samo nie zaczęło liczyć sterty w blokach alokatora, a nie w żądanych bajtach. Dopiero wtedy zobaczyliśmy, gdzie naprawdę idzie 512 bajtów, i zeszliśmy do 494.
• Narzędzie do testowania jest częścią produktu. Największym ograniczeniem nie było jądro, lecz sieć użytkownika QEMU i liczba portów efemerycznych na komputerze deweloperskim. Dla stu tysięcy połączeń i więcej potrzebny jest vmnet-shared na macOS albo Linux z KVM, interfejsem tap i wieloma adresami klientów.
• SQLite bez systemu operacyjnego jest możliwy, ale tylko przy rygorystycznych warunkach: stała sterta, wyłączna blokada bez pamięci współdzielonej, VFS, który nie wie o plikach, oraz kontrola przyjęć, która nie pozwala bazie zalegać.
• Burze ponownych połączeń są normalnym stanem, a nie wyjątkiem. Gdy sieć komórkowa padnie i wróci, tysiące urządzeń pukają jednocześnie. Dlatego kontrola przyjęć odrzuca połączenie przed jakąkolwiek kryptografią, a każde odrzucone połączenie kosztuje prawie nic.

Co dalej

Prace po M17 zaplanowano w trzech kierunkach, a kolejność między nimi jest zapisana w docs/PLAN.md. Nic z tego nie zostało jeszcze zbudowane.

• Jeden ISO dla wielu platform. Ten sam plik urmqtt-<env>-<wersja>.iso i jeden surowy obraz GPT, które startują na aarch64 UEFI, x86_64 UEFI i x86_64 BIOS, w maszynach wirtualnych i na prawdziwym sprzęcie, zaczynając od jednego komputera PC z Intelem. Nadal urządzenie ze wszystkim w środku, powtarzalne i podpisane.
• Surowy dysk, bez systemu plików. Specyfikacja formatu na poziomie bajtów, narzędzie hosta urmqtt-disk współdzielące parsery z jądrem, wyrównanie regionów do 1 MiB, rozrost dysku wraz z danymi, discard dla dysków z cienkim przydziałem, migawki A/B bazy, weryfikacja bitów i, opcjonalnie, szyfrowanie AES-256-XTS ze sprzętowym AES.
• Udowodnione bezpieczeństwo. Unieważnianie i lista dozwolonych urządzeń w czasie pracy przez podpisany kanał kontrolny, bez nowego obrazu; testowanie różnicowe i zgodnościowe własnego TLS i TCP; KASLR, ochrona stosu, kCFI, MTE i wzmocniony alokator; SQLite wyizolowany na poziomie EL0; Secure Boot; SBOM i cargo-vet; a na końcu pakiet do audytu zewnętrznego.

Platformy, które oferują wyłącznie urządzenia inne niż virtio, takie jak AWS ENA czy Azure MANA, na razie nie są obsługiwane. Raspberry Pi 4 i 5 jako host KVM, Hetzner CAX i Oracle Ampere A1 są udokumentowane i obsługiwane w kodzie, ale nie zostały jeszcze wypróbowane w prawdziwej usłudze.

Wypróbuj

Repozytorium jest na github.com/zeljan-alduk/urMQTT. Z Rust z przypiętym łańcuchem narzędzi nightly i QEMU wystarczą make certs, make run i jeden klient mosquitto, aby wysłać pierwszy PUBLISH przez mTLS na własnym komputerze. Ostrzeżenie z początku obowiązuje także na końcu: to pre-alfa, a wszystko, co działa, jest opisane w docs/PROGRESS.md. Zgłoszenia błędów, pytania o projekt i zgłoszenia dotyczące bezpieczeństwa zgodnie z instrukcją w SECURITY.md są mile widziane. O każdym kolejnym kamieniu milowym damy znać tutaj.

Na tym blogu zapisujemy to, czego nauczyliśmy się po drodze. Nie teksty marketingowe, lecz konkretne notatki: co poszło nie tak, jak to rozwiązaliśmy i co dziś zrobilibyśmy inaczej.

O czym będziemy pisać

• Pobieranie opłat w transporcie publicznym. Karty zbliżeniowe, moduły SAM, praca bez sieci i wszystko, co terminal musi znieść w pojeździe, który trzęsie się dwanaście godzin dziennie.
• Aplikacje mobilne w terenie. Android i Flutter na urządzeniach, które nie są zwykłymi telefonami: z czytnikami kart, drukarkami i bateriami, które muszą wytrzymać całą zmianę.
• Backend i monitoring floty. Skąd wiedzieć, że urządzenie w pojeździe ma problem, zanim zgłosi go kierowca.
• Sprzęt. Od prototypu na biurku do płytki, która trafia do produkcji seryjnej, i wszystkie błędy po drodze.
• Lokalne modele AI. Gdzie modele na własnym sprzęcie mają sens, a gdzie chmura i API są po prostu lepszym wyborem.

Jak będziemy pisać

Krótko i konkretnie, z kodem i liczbami tam, gdzie je mamy. Będziemy publikować, kiedy mamy coś do powiedzenia, a nie według harmonogramu. Wpisy piszemy po chorwacku i tłumaczymy na wszystkie języki tej strony; możesz nas też śledzić przez RSS.

Jeśli interesuje Cię jakiś temat albo pracujesz nad podobnym problemem, napisz do nas na info@aldo.tech.