A nota prévia mantém-se: o projeto é pré-alfa, a primeira versão destina-se apenas a VPS com KVM, e os números medem código, testes e experiências determinadas, não maturidade em produção.

Como isto se desenrolou no tempo

Desde o texto anterior (31.10. às 23:00) até hoje (1.11. às 20:41) o repositório tem 59 commits novos, 178 no total. Todos nasceram num único dia de calendário, pelo que vale o mesmo aviso de antes: o projeto é construído com o Claude Code (os commits trazem Co-Authored-By: Claude), o plano, o código, os testes e os ADR nascem em ciclos curtos e fechados, e os números abaixo falam da quantidade de código e de verificações, não de quanto trabalho humano há neles.

Os números foram calculados com o mesmo método do texto anterior: todos os ficheiros .rs fora de vendor/ e fuzz/, funções #[test], títulos ## ADR- em docs/DECISIONS.md.

Trabalhou-se em paralelo em vários ramos, pelo que a ordem dos commits não é estritamente a ordem do trabalho. Os ADR estão numerados até 232, mas a numeração tem lacunas (parte foi renumerada ao juntar ramos); contamos os títulos, não o número mais alto. Versões: v0.2.0 (1.11., 18:45 UTC) e v0.2.1 (1.11., 20:22 UTC), ambas marcadas como pre-release.

H6: SQLite em modo utilizador

O que planeámos. O SQLite são 254 268 linhas de C que fazem o parsing da base de dados, do WAL e do diário a partir do disco, e o disco pode ser fabricado ou alterado. Até aí corria no kernel, com os privilégios do kernel. O que construímos (ADR-210 a ADR-212): o SQLite, as suas partes da libc e o heap foram movidos para um programa separado, dbworker, que corre em EL0 (aarch64) ou ring 3 (x86_64), no seu próprio espaço de endereçamento. O kernel já não liga o SQLite. O worker comunica com o kernel através de uma janela de memória partilhada e de doze chamadas de sistema, e cada comprimento e deslocamento devolvidos é verificado antes de ser usado. Um erro no worker (acesso ilegal, instrução indefinida, orçamento de tempo de 30 s excedido) termina a chamada, o worker é reiniciado e a base de dados é aberta a partir do WAL como num arranque; após 5 reinícios num minuto o armazenamento é declarado avariado, em vez de reiniciar indefinidamente.

O custo, medido em aarch64 sob HVF, a mesma VM, kernel com SQLite incorporado contra kernel com worker, seis arranques alternados de cada:

As escritas em disco (1 572) e os flushes (319) são idênticos, como tem de ser. O que não está isolado é isto: o kernel continua a confiar no que o worker devolve, depois de verificar a forma. Um worker comprometido pode mentir (por exemplo, devolver uma lista vazia de certificados revogados e assim "desrevogá-los"), mas não pode ler a memória do kernel, as chaves TLS nem as chaves dos tickets. Não há KPTI, pelo que as fugas do tipo Spectre/Meltdown não estão impedidas e não afirmamos nada sobre elas; a chave PAC é partilhada por EL0 e EL1. Em x86_64 não medimos o custo da mudança em KVM (sob TCG o número não faria sentido), e o fuzzing do próprio worker e do protocolo ainda não está concluído. O conjunto de testes de armazenamento (79 cenários, cada um a usar o SQLite no worker) passa em aarch64 HVF e x86_64 TCG, e em aarch64 TCG passam 76 (um é ignorado porque o TCG não tem MSI-X).

O H7 está fechado, mas não da forma que anunciámos. O limite inferior do tempo (ADR-050) e o SNTP com consenso (T1) cobrem o âmbito do H7; o NTS (RFC 8915) fica fora do âmbito e está registado como risco residual, não como algo que funciona. Não consideramos que a segurança do tempo esteja "resolvida", mas sim que a sua parte demonstrável está concluída.

Nova opção de rede. A Contabo não dá DHCP a um ISO personalizado, pelo que o VPS precisava, até aqui, de uma imagem diferente da da VM de laboratório. Agora network.mode = "auto" (ADR-214) pergunta primeiro ao DHCP e, se não houver concessão dentro do prazo (dhcp_timeout_s, por omissão 15 s) ou se a perder, aplica o endereço estático por omissão. Experimentado manualmente em QEMU (com DHCP usa a concessão, sem rede volta ao endereço estático ao fim de 5 s); ainda não existe um cenário de smoke para isto.

X11: comparação com o Mosquitto no mesmo VPS

O mesmo tipo de máquina do texto anterior (Contabo, 4 vCPU AMD EPYC, 8 GiB), carga a partir de um anfitrião Linux a 15 ms de distância, TLS 1.3 mútuo com os mesmos certificados dos dois lados, Mosquitto 2.0.21 em Debian 13 sem persistência. O método e as decisões estão no ADR-213, os dados em bruto em docs/perf-results/. Mediana de três execuções.

O que isto significa e o que não significa. Os handshakes são limites inferiores para os dois servidores: o gerador de carga é uma VM partilhada com 60 a 70% de tempo de CPU roubado e, com 128 threads, estava perto do seu próprio limite, enquanto os núcleos de trabalho do urMQTT estavam ocupados apenas 12 a 13%. A razão com 128 clientes (cerca de 2,2 vezes) é a mais significativa; com 32 e 64 mede sobretudo a espera dos clientes. Os números de memória não contam o mesmo (heap do kernel contra RSS do processo), pelo que "cerca de 50 vezes menos" é uma ordem de grandeza, não uma razão precisa. A latência de 14 ms é uma ida e volta da rede (cerca de 15 ms), ou seja, "sem tempo mensurável do broker"; as caudas (p99 cerca de 100 a 200 ms) são dominadas, nos dois brokers, pelos anfitriões partilhados. Não afirmamos diferenças abaixo de cerca de 20%.

O que não correu a nosso favor e ficou nas tabelas: um fluxo TCP único através do urMQTT transportou 2 a 8 vezes menos do que através do Mosquitto, com variações de zero a 7,7 mil mensagens por segundo entre execuções, e o watchdog de 20 ms do handler interrompeu ligações vivas quando o hipervisor parou um vCPU (na configuração de produção action = "drop", 6 a 8 ligações por execução com inundação QoS 0). As duas coisas são descritas na secção seguinte, porque tinham causas no nosso código.

Porque é que o fluxo único era lento: causas, não desculpas

O mais fácil seria dizer "VPS partilhado". Não o fizemos: com o mesmo VPS e o mesmo método, procurámos as causas. Foram encontradas cinco, quatro no caminho de dados e uma no watchdog (ADR-221 a ADR-224):

As paragens são reais: neste VPS os núcleos 0 a 2 tiveram uma mediana de 36 a 80 ticks atrasados por 5 segundos, e a pior paragem na janela teve mediana de cerca de 70 ms e chegou a 0,9 s (núcleo 3, base de dados e diário: até 1,55 s), enquanto o anfitrião não comunica tempo roubado (host steal 0 us). Por isso o watchdog precisava de outro relógio, não de um orçamento maior.

Watchdog: 148 ligações interrompidas em 30 execuções com carga antes, 0 em 24 execuções depois; num aparelho local que atrasa e perde tramas, com 0,1% de perda um fluxo único de 64 B com 14,3k mensagens/s (kernel do X11) passa a ter 41,0k, e com 0,5% de 5,0k para 17,7k.

O que isto não diz. O urMQTT continua a não ser mais rápido do que o Mosquitto num fluxo único: com 64 B publica cerca de 80% da velocidade dele e entrega cerca de 40%, porque descarta QoS 0 quando o fluxo do subscritor é mais lento do que o do publicador (o Mosquitto, sem limite, põe em fila). Com 1 KiB na inundação de 16 pares o Mosquitto está à frente cerca de 15%, o que está dentro do ruído. O gerador voltou a ser uma VM partilhada com 58 a 77% de tempo roubado. A segunda ronda (bloqueio do heap fora do caminho de dados, SACK do lado do envio e outras coisas) está no ramo não integrado perf-single-flow-wip; os seus números ainda não são afirmações e não os apresentamos aqui.

A promessa que não fizemos, mas cumprimos: a configuração é dado

Até agora cada configuração era uma nova compilação: as chaves e os limites estavam incorporados na imagem. O C1 inverte isto (ADR-215 a ADR-219): o kernel é compilado uma vez e a configuração é dado.

• Blob urmqtt-cfg (C1a): registo versionado e canónico (campos por etiquetas crescentes, impressão digital SHA-256, assinatura Ed25519 separada opcional), 70 campos com valores por omissão e limites, e um descodificador que rejeita tudo o que esteja incorreto.
• O kernel lê-o como módulo do Limine (C1b), antes de qualquer outra coisa, em aarch64 e x86_64. Existe um único kernel de versão para cada ENV exceto dev (os ELF aarch64 de release, prod e bench têm o mesmo SHA-256; verificado apenas em aarch64). O kernel de versão rejeita uma configuração de desenvolvimento e, sem configuração, escreve "refusing to serve" e não serve nada.
• O disco instalado transporta a configuração e a atualização mantém-na (C1c).
• urmqtt-config e o modelo de ISO (C1d): pack, show, verify, e pack --iso substitui as duas cópias do espaço de configuração e os 24 resumos de módulos num ISO já pronto. O resultado é byte a byte igual ao ISO que mkiso.sh --config constrói. O modelo da versão v0.2.0 tem 63 111 168 bytes.
• Declaração de confiança (ADR-219): uma imagem configurada escreve no arranque a impressão digital da configuração (config: fingerprint ...), e a assinatura é opcional e desativada por omissão. Um ISO alterado não tem o resumo oficial; a impressão digital é a forma de ver o que está dentro dele.

O construtor em aldo.tech

O que urmqtt-config pack --iso faz, faz também uma página web, com o mesmo código: a biblioteca de ferramentas compilada para WebAssembly (1,06 MB, sem importações e sem blocos unsafe). A página está em aldo.tech/pt/produtos/urmqtt-builder/ e existe nos 15 idiomas do sítio (por exemplo hr).

• Nada sai do navegador. Os certificados, as chaves privadas e o ISO pronto ficam no computador; a página só descarrega os ficheiros da versão deste sítio, sem rastreamento nem scripts de terceiros. Num teste em produção, nenhum pedido transportou material de chaves.
• Espelho das versões (ADR-227): de hora a hora (systemd timer, baixa prioridade) copia as versões do GitHub, verifica cada uma antes de a publicar, e a página, no navegador, verifica a assinatura de SHA256SUMS com a chave incorporada na página, e só depois escreve a configuração no modelo. Uma verificação falhada bloqueia a transferência.
• Simples por omissão, avançado quando necessário (ADR-232): o primeiro ecrã tem três passos (onde vai funcionar, os seus certificados, o nome da imagem). Um único campo de arrastar ficheiros separa certificado, chave e CA pelo conteúdo. A vista avançada abre cada um dos 70 campos, pesquisa, importação e exportação de TOML; as duas vistas editam o mesmo estado. O modelo (63 MB) é descarregado enquanto o utilizador preenche o formulário. Num ensaio em produção, com um espelho de teste e uma chave de teste, a construção do ISO no navegador demorou 5 a 18 s.

Emulador, opcional. Ao lado de "Descarregar ISO" está "Experimentar no emulador": o QEMU compilado para WebAssembly executa a imagem acabada de construir num separador do navegador. Nada dele é descarregado antes do clique (cerca de 3 MB da primeira vez). O emulador é só BIOS, sem rede (para que o tráfego do utilizador não passe por um intermediário e desminta o "nada sai do navegador"), precisa de cerca de 1,5 GB de memória e de um navegador de computador (testado o Chrome; o Firefox e o Safari não). Nele o urMQTT chega a URMQTT READY em cerca de 8 s (com a contagem decrescente ignorada) e escreve a mesma impressão digital da configuração que a página, o que prova que foi arrancada exatamente essa configuração. O arranque é cerca de 2 vezes mais lento do que o QEMU nativo no mesmo Mac (0,82 s contra 1,9 s), e a criptografia cerca de 58 vezes mais lenta porque as instruções de hardware são emuladas. Por isso não tiramos do emulador nenhuma afirmação sobre velocidade, e a página diz-o antes do arranque. Na construção foi preciso corrigir quatro bytes no .wasm devido a um erro na tradução da instrução POPCNT no emulador original (ainda não o comunicámos); o próprio emulador está sob GPL, com oferta do código-fonte.

MQTT simples, só para redes em que confia

O MQTT simples (TCP 1883, sem TLS) é muito comum em IoT: é o predefinido no Mosquitto, na maioria dos firmwares para Arduino e ESP, no Tasmota, no Zigbee2MQTT e no Home Assistant, e usa-se também dentro de redes industriais segmentadas, atrás de VPN e em LAN privadas, incluindo em dispositivos sem relógio (os certificados exigem uma data), sem flash ou processador suficientes para TLS. Numa rede não fiável não é aceitável: quem está no caminho lê e altera o tráfego. Por isso o P1 (ADR-229 a ADR-231) é uma escolha explícita e limitada, desativada por omissão, e a porta TLS mantém-se; o TLS não é desligado por isto, a porta simples vem juntamente com ele.

• A lista de redes permitidas é obrigatória (allow_from, CIDR) e é verificada no SYN: fora da lista não há SYN-ACK nem estado. A internet inteira (0.0.0.0/0) exige uma opção explícita à parte.
• Três modos de autenticação: palavra-passe (por omissão quando ativado; PBKDF2-HMAC-SHA-256, sal, 10 000 iterações, comparação em tempo constante, bloqueio por endereço), anónimo (uma identidade configurada com a sua própria ACL) e por endereço (ip). O construtor calcula o hash da palavra-passe no navegador e guarda em memória apenas o resumo.
• Menos direitos do que o mTLS: um cliente simples nunca tem direitos de serviço, de operador nem de gestão, não tem $SYS nem consola, tem sessões próprias ($plain/<identidade>/<id do cliente>, apenas limpas), limites próprios, e o registo de permitidos continua a vinculá-lo.
• O que se perde está em SECURITY.md: confidencialidade, integridade, autenticidade do broker e a repetição de um início de sessão gravado. Isto não se corrige com configuração; é assim quando não há TLS.

Medido num portátil (Apple silicon, HVF, rede de utilizador do QEMU), 16 pares, 64 B, três execuções de 10 s: com 8 000 mensagens por segundo o caminho TLS e o simples entregam todas as mensagens com a mesma latência (p50 0,17 ms contra 0,13 a 0,18 ms), novas ligações por segundo: TLS cerca de 2 600 a 2 750, simples anónimo cerca de 4 900 a 7 800, e o início de sessão com palavra-passe é a parte cara: um PBKDF2 custa cerca de 2,5 ms, pelo que o número de novos inícios de sessão fica limitado a cerca de 200 por núcleo de dados por segundo (medido 308 a 342 em dois núcleos). A inundação nesta máquina não é um instrumento estável (20k a 440k entregues por segundo entre execuções) e não tiramos conclusões dela. A comparação do caminho simples com o Mosquitto no VPS ainda não foi feita. Testes: o grupo de smoke plaintext 7 de 7 em aarch64 HVF e em x86_64 TCG, novo alvo de fuzz plain_input (2,3 milhões de execuções sem achados).

Erros que o trabalho em produção encontrou

Duas coisas não foram apanhadas pelos testes, mas sim pela primeira ativação no sítio real:

• A página pedia os ficheiros da versão um diretório acima do correto, pelo que cada verificação de assinatura respondia 404 (correção 13af301). O teste usava um espelho de teste noutro caminho.
• O teclado do emulador nunca chegava ao convidado: a causa não era uma tradução incorreta das teclas, mas o facto de o diálogo nem sequer estar a escutar as teclas (correção no ADR-232, com uma entrada de arranque que não precisa de teclas).

Lições

• Procurem a causa, não culpem o ambiente. A maior parte das fraquezas do fluxo único e todas as ligações interrompidas eram nossas; o hipervisor é real, mas era preciso medi-lo, não presumi-lo.
• A comparação com outro produto tem de incluir também as perdas. Uma tabela em que só há vitórias nossas não seria uma comparação.
• O instrumento de medição tem limites. Um gerador partilhado com 60 a 70% de tempo roubado muda o que os números significam; por isso escrevemos "limite inferior" e não afirmamos diferenças abaixo de 20%.
• O isolamento não é uma prova. O SQLite em EL0 reduz o que um erro nele pode fazer, não aquilo sobre que pode mentir.
• Uma instalação real encontra o que os testes não pedem: um caminho mal composto e teclas que ninguém escuta.

O que ainda não está provado

• A chave de assinatura das versões é, por agora, uma chave de teste; a v0.2.0 e a v0.2.1 são pre-release, e as imagens que as acompanham são de desenvolvimento com certificados de teste (exceto o modelo, que não tem configuração).
• 13 traduções da página do construtor (e deste texto) foram escritas por uma IA e verificadas por testes e amostras, não por falantes nativos.
• A comparação com o Mosquitto é uma sessão, um caminho e um gerador partilhado, num VPS partilhado; diferenças abaixo de 20% não são afirmações.
• O caminho simples não foi medido no VPS nem contra o Mosquitto.
• O Lighthouse na nova vista simples não está confirmado (vista antiga: acessibilidade 95 ou mais).
• Bare metal, custo do worker em x86_64 em KVM, Firefox e Safari para o emulador: não medido.

O que se segue

• D1: broker de demonstração público. Não podemos tornar público o emulador do navegador: vive no separador de um visitante, é 20 a 100 vezes mais lento do que o KVM, não tem rede de entrada e desaparece quando o separador é fechado; redirecionar a internet para o navegador de outra pessoa seria também um abuso. É possível um verdadeiro broker de demonstração: o urMQTT num VPS atrás de um nome em aldo.tech, com uma CA de teste publicada, uma ACL estrita e pequenos limites. Por agora é apenas uma ideia, não uma construção, e precisa de consentimento explícito para a exposição pública.
• Segunda ronda para o fluxo único (ramo perf-single-flow-wip): só quando estiver medida no VPS e integrada.
• O caminho simples contra o Mosquitto no VPS, início de sessão e revogação de contas para MQTT simples através do canal de gestão assinado.
• Depois da versão: bare metal (X12 a X16), IOMMU e Secure Boot, cifragem do disco.

O código está em github.com/zeljan-alduk/urMQTT, e docs/PROGRESS.md continua a ser a única fonte de verdade sobre o que realmente funciona, docs/PERFORMANCE.md sobre o que foi medido. Pré-alfa, como antes; relatórios de erros e relatórios de segurança, segundo as instruções em SECURITY.md, são bem-vindos.

Uma nota prévia: o projeto continua pré-alfa. Os números do texto medem código e testes, não maturidade em produção, e a primeira versão está deliberadamente limitada a VPS com KVM. O bare metal fica para mais tarde.

Como isto se desenrolou no tempo

O primeiro commit foi feito a 28 de outubro de 2026 às 23:48 (M0). A 31 de outubro às 23:00 o repositório tem 119 commits, distribuídos como 3, 39, 38 e 39 por dia de calendário. Digamos já como isso é possível: o projeto é construído com o Claude Code, e os commits trazem trailers Co-Authored-By: Claude. Quatro dias de calendário de histórico não significam que uma pessoa tenha escrito 90 000 linhas em quatro dias; significam que o plano, a implementação, os testes e os ADR são escritos em ciclos curtos e fechados, e que cada passo termina com o mesmo ritual de verificação de antes. Os números abaixo falam da quantidade de código e de testes, não de quanto de tudo isto foi validado em trabalho real.

O gráfico mostra três curvas que crescem quase em conjunto, o que é intencional: os testes e as decisões registadas acompanham o código, em vez de ficarem para trás. A inclinação é maior a 29 de outubro, quando nasce todo o caminho do kernel até ao broker. Depois as linhas acrescentam-se mais devagar, mas os testes crescem mais depressa do que o código (27 testes para 1,6 mil linhas no início, 739 para 89,8 mil hoje).

As linhas são todos os ficheiros .rs fora de vendor/ e fuzz/, e os testes são funções #[test]. O que cada fase acrescentou, segundo as datas do histórico do git:

Promessa 1: um ISO para várias plataformas

O que planeámos. Um único ficheiro que arranca em UEFI aarch64, UEFI x86_64 e BIOS x86_64. O que construímos. O port para x86_64 (X0 a X10) e um ISO universal com o bootloader Limine, um ISO híbrido a partir do qual arrancam todas essas combinações; os smoke tests arrancam-no em quatro máquinas virtuais. O menu tem três entradas: urMQTT (modo live, corre a partir da RAM, não escreve nada no disco), instalação no disco da máquina em que está a correr (a instalação escreve o GPT e os dados e depois desliga a máquina) e Diagnóstico (deteção de hardware e medições).

O primeiro alvo real foi um VPS, e não um computador físico: a decisão é que a primeira versão suporte apenas VPS (KVM), e o bare metal vem depois. Testámos num VPS da Contabo com um processador AMD EPYC (família 23, Zen 1), 4 vCPU e 8 GiB de RAM, com rede virtio-net e disco virtio-scsi. A primeira tentativa surpreendeu-nos: o ISO ligado como CD virtual arrancava a entrada predefinida, a imagem de produção recusava-se a servir a partir de um suporte só de leitura e reiniciava, e ficámos com um ciclo infinito de menu, kernel, reinício sem nada legível. Hoje, um erro fatal na imagem de produção deixa uma mensagem na consola durante 60 segundos antes de reiniciar e, a partir de um suporte ótico, escreve que arrancou de um suporte só de leitura e pára. O modo live em RAM (O3) contornou depois esse problema para o caso habitual.

A entrada de diagnóstico nasceu dessa experiência: uma máquina que não vemos tem de poder ser interrogada sobre o que tem. Mostra CPU, RAM, rede, discos e dispositivos PCI, mede a largura de banda da memória, o disco e a criptografia, e escreve as mesmas medições em JSON na porta série. A escrita no disco só é permitida no espaço não atribuído e apenas depois de se escrever WIPE; na captura abaixo isso foi ignorado.

O que fica em aberto. Hardware real. Depois da primeira versão segue-se o bare metal (arranque por USB, NVMe e AHCI, a placa de rede de um computador verdadeiro), juntamente com IOMMU e Secure Boot, porque sem IOMMU um dispositivo malicioso ou avariado pode escrever em toda a memória. Nesta versão não afirmamos nada sobre isso.

O handshake: de 1,2 ms para 0,24 ms

A primeira medição do diagnóstico no VPS deu um número incómodo: o handshake mTLS, apenas a criptografia do lado do servidor, demorava 1,2 ms. No aarch64 já usávamos as instruções de hardware AES e SHA, mas o x86_64 não tinha nada de semelhante para a chave pública: o RustCrypto é portável e constant-time, e por isso também lento. Três alterações baixaram esse valor.

• Para o P-256 adotámos o assembly nistz256 do OpenSSL e do ring (ADR-130), com tabelas de base fixa para a assinatura e para a verificação de assinaturas da CA (ADR-110, ADR-111).
• O X25519 foi reescrito com quatro membros de 64 bits e instruções MULX/ADX (ADR-131).
• Depois disso, perfilámos o resto (ADR-132, ADR-200).

Os números variam cerca de 10% de execução para execução, por isso registámos um intervalo em vez de um único valor. No total, isto representa aproximadamente cinco vezes menos tempo de CPU por handshake.

O que aprendemos sobre o memcpy. Quando a criptografia baixou, o perfil mostrou algo que não esperávamos: as funções mem* (memcpy, memmove, memset) consumiam 7% do handshake, 13 a 39% do caminho de um registo TLS (39% para 64 B, 13% para 4 KiB) e 17 a 34% da distribuição de um PUBLISH. Substituímo-las por assembly SSE2 para x86_64 (ADR-200), com testes diferenciais face à implementação de referência para todos os tamanhos, alinhamentos e sobreposições. Por chamada, são 55 a 75 ciclos contra 7 a 12 para 1 a 64 bytes.

Como ler o gráfico: quanto mais pequeno é o registo, maior é a parte do tempo que vai para a cópia, e por isso maior é o ganho. Para mensagens pequenas, que são a maioria do tráfego MQTT, é isto que conta.

O que isto não significa. Em x86_64 nativo medimos o OpenSSL 3.5.5 apenas como referência para o assembly (ADR-130), e não como comparação de produtos. A comparação Linux mais Mosquitto no mesmo VPS (tarefa X11) ainda não foi feita. Por isso não afirmamos que o urMQTT é mais rápido do que o Linux: não foi medido. Os números acima comparam o urMQTT consigo próprio.

A sobrecarga foi o segundo resultado. No VPS, a partir de um Mac (RTT de 35 ms), 128 clientes deram 618 handshakes por segundo, 256 clientes deram 393 e 512 clientes deram 67, com milhares de ligações recusadas. Não foi um patamar, foi um colapso. Encontrámos as causas no código (duas foram confirmadas no QEMU/HVF e não puderam ser reproduzidas no VPS), várias em simultâneo: uma ligação recusada devolvia o cliente pelo segmento seguinte que traz um SYN cookie válido, a recusa por RST dizia ao cliente para tentar de novo de imediato, e a receção era O(fila). A correção (ADR-080 a ADR-082) descarta o SYN que não seria aceite, memoriza os fluxos recusados, mantém a receção em O(1) e conta os handshakes por núcleo. É possível (hipótese, não verificada) que parte da causa estivesse também no cliente: a ferramenta de carga fechava primeiro, pelo que um Mac com 16 384 portos efémeros e um TIME_WAIT de 30 segundos ficava limitado a cerca de 550 ligações por segundo. Por isso ainda não medimos o verdadeiro teto do servidor.

Promessa 2: disco em bruto, mas cuidadoso

O que planeámos. Manter a disposição própria sem sistema de ficheiros e acrescentar tudo o que um sistema de ficheiros normalmente dá: alinhamento, crescimento, discard, cópias de segurança e verificações. Porque não um sistema de ficheiros. Discutimos o assunto e a decisão foi confirmada: o urMQTT escreve uma base de dados, um diário de telemetria e os seus próprios metadados, não precisa de diretórios, permissões nem nomes de ficheiros, e cada camada adicional seria mais código na parte de confiança e mais uma forma de uma escrita desaparecer em silêncio. O disco é GPT, com uma partição ESP e uma partição de dados do urMQTT, na qual está a disposição própria.

O que construímos (S2 a S6).

• Disposição v2 (S2). Topologia do disco, alinhamento a 1 MiB ou ao tamanho ótimo de I/O, blocos físicos inteiros, par A/B de superblocos com geração (ADR-140). A disposição v1 é recusada pelo kernel com uma mensagem clara e migrada pela ferramenta offline urmqtt-disk migrate (ADR-141): por omissão é uma passagem de ensaio, copia-se e só depois se comuta, com reversão e injeção de falhas em cada escrita.
• Crescimento (S3). No arranque o disco pode crescer (nunca encolhe) e, em virtio-blk, também durante a execução, através da interrupção de alteração de configuração (ADR-142, ADR-143).
• Discard e write-zeroes (S4). Os discos de provisionamento dinâmico devolvem o espaço ao anfitrião. Num teste, o ficheiro qcow2 no anfitrião desceu de 62 para 16 MiB depois de expirarem os segmentos de telemetria, e a recuperação nunca confia no conteúdo que foi descartado.
• Cópia de segurança da base de dados no disco (S5). Uma cópia A/B com a API de backup online do SQLite em passos de 16 páginas: o passo mais longo é de 4,6 ms contra 445 ms quando se copia numa única chamada. Os commits durante a cópia tiveram um máximo de 2,4 ms contra 2,2 ms sem ela. Se o quick_check falhar no arranque, a base de dados é restaurada a partir da cópia.
• Limpeza e arranque limitado (S6). O scrubber lê o disco com um orçamento de I/O limitado e comunica os registos danificados, e o arranque lê apenas o segmento mais recente de cada partição, de modo que o tempo de arranque não cresce com o tamanho da região de telemetria. Fechámos assim um problema que tínhamos calculado de antemão: num disco grande, a recuperação completa demoraria de minutos a dezenas de minutos.

Todo o grupo de smoke tests de armazenamento passa nas duas arquiteturas: 79 com sucesso, 0 falhados, em aarch64 sob HVF e em x86_64 sob TCG. Medimos também que o S4 não tornou a base de dados mais lenta: 53,3 mil inserções por segundo em lotes antes e depois, sem diferença mensurável.

O que surpreendeu. Quanto de uma disposição "simples" se vai em casos limite: virtio-scsi e virtio-blk comunicam a topologia de formas diferentes, e uma escrita incompleta a meio de uma migração tem de deixar sempre pelo menos uma versão válida. Por isso cada escrita no caminho da migração e do crescimento passou por injeção de falhas.

O que fica em aberto. As páginas do SQLite não têm checksum, pelo que a base de dados não deteta um bit alterado dentro do valor de uma linha; os registos de telemetria e o conteúdo das cópias têm CRC e são detetados. A cifragem do disco (S7) não está feita.

Promessa 3: comprovadamente seguro, tanto quanto conseguirmos

Reforço (H4). O alocador apaga a memória libertada e verifica-a na reutilização, deteta a dupla libertação, liga os ponteiros da lista livre com XOR e zera as chaves ao libertar (ADR-170). Proteção da pilha (-Zstack-protector=strong, 1315 funções, e o SQLite com -fstack-protector-strong, ADR-171). Os relatórios de erro em produção não contêm registos nem endereços (ADR-172). KASLR nas duas arquiteturas: o kernel é PIE e o Limine desloca-o cerca de 19 bits, e o heap, as pilhas e a janela MMIO são colocados aleatoriamente (ADR-173). No aarch64 o MTE marca o heap (ADR-174), mas só sob TCG: o HVF e o x86 não o têm. O kCFI foi avaliado e não o adotámos porque o compilador no nightly fixado falha com um erro interno; o IOMMU foi adiado juntamente com o bare metal (ADR-175, ADR-176).

O custo foi medido, não presumido. No caminho do handshake (dp-bench, aarch64 HVF, handshakes completos TLS 1.3 + mTLS + CONNECT):

No total, o custo no caminho do handshake é portanto de cerca de 5% para as partes medidas de forma limpa e, com PIE e marcas, sai cerca de 7% com um núcleo e cerca de 11% com quatro, mas esta medição tem ruído. Consideramo-lo aceitável, mas não o repetimos no VPS x86_64.

Vale a pena comparar com o número do primeiro texto (862 handshakes por segundo num núcleo). A mesma ferramenta hoje, com o controlador de cifragem por hardware no aarch64 (X0b) e uma série de acelerações que chegaram desde então, dá 1941 antes do reforço. Não isolámos a contribuição de cada alteração, por isso não afirmamos nada sobre a causa.

Como foi verificado, e o que não foi. O H5 acrescentou o Miri a um subconjunto de crates do host, provas Kani, sanitizers, um model-fuzzer para a ACL e relatórios de cobertura. O Kani provou o record_len no TLS, o parse no TCP e duas aritméticas da roda de temporizadores. Não está provado (tempo esgotado): os dois descodificadores MQTT, os dois parsings de configuração e o comportamento da roda de temporizadores; por isso o trabalho de CI do Kani ainda não é bloqueante. O Miri não consegue executar assembly. Cadeia de abastecimento (H9): SBOM CycloneDX com 215 componentes, o cargo-vet passa com 39 totalmente auditados e 140 exceções, e o cargo-deny está configurado para tratar os avisos de vulnerabilidades como falha da CI (esses trabalhos de CI foram até agora verificados só localmente, não no GitHub, e o teste negativo não foi executado), juntamente com o VULNERABILITY-HANDLING.md. O estado honesto: das 67 versões de crates de terceiros ligadas ao kernel, 53 são exceções e não auditorias. O vet prova que o conjunto de dependências não pode mudar sem uma diferença visível, não que o TCB tenha sido revisto. Não escrevemos uma auditoria nossa para nenhum crate.

O SNTP (T1) é, nesse sentido, uma pequena história de segurança: é opcional, apenas para servidores IPv4 privados, com um salto máximo e a condição de as fontes concordarem (mediana, maioria dentro de um segundo). Um relógio que qualquer pessoa no caminho pode deslocar não é um relógio em que possamos confiar para a validade dos certificados.

No Mac: aarch64 nativo e x86_64 por emulação

Desenvolvemos num Mac, e este tem duas formas de executar o mesmo código, muito diferentes entre si.

A regra é simples: os números sob TCG são emulação e não os citamos como desempenho. O desempenho em x86 só o medimos num VPS real. Por isso os números de criptografia acima vêm do VPS da Contabo, e não do Mac.

Lições

• Meçam numa máquina real antes de otimizar. A primeira abordagem foi otimizar o que pensávamos ser lento; só o diagnóstico no VPS mostrou os 1,2 ms e onde exatamente o tempo se perde.
• A sobrecarga é uma funcionalidade à parte. Um sistema rápido sob carga pode colapsar acima dela; recusar tem de ser mais barato do que aceitar.
• O perfil surpreende. O maior ganho individual para mensagens pequenas não esteve na criptografia, mas na cópia de memória.
• Um disco sem sistema de ficheiros dá mais trabalho, não menos. O que o sistema de ficheiros normalmente dá (alinhamento, crescimento, discard, cópias, verificações) temos de o escrever e verificar nós, cada passo com injeção de falhas.
• Honestidade nos números. As medições de memória num VPS partilhado variam até 10 vezes entre execuções e não dizem nada sobre o código, por isso não as citamos. Os números de criptografia são estáveis até cerca de 10%.
• A velocidade de desenvolvimento não é maturidade. Os testes e os ADR crescem com o código, mas quatro dias não são operação a sério.

O que se segue

• H6: SQLite isolado ao nível EL0, para que um erro na base de dados não abra o kernel.
• H7: o resto da segurança do tempo (NTS e tratamento de saltos); o SNTP é apenas o primeiro passo.
• X11: comparação com o Linux e o Mosquitto no mesmo VPS, só então faz sentido falar de velocidade relativa.
• Versão: a primeira publicação pública para VPS (KVM), com artefactos assinados e instruções.
• Depois da versão: bare metal (X12 a X16), IOMMU e Secure Boot, e a cifragem do disco.

O código está em github.com/zeljan-alduk/urMQTT, e o docs/PROGRESS.md continua a ser a única fonte de verdade sobre o que realmente funciona. Pré-alfa, como antes; relatórios de erros e comunicações de segurança, seguindo as instruções em SECURITY.md, são bem-vindos.

Foi assim que nasceu o urMQTT: um unikernel que é um broker MQTT. Kernel, TCP/IP, TLS 1.3, MQTT e uma base de dados integrada num único binário Rust, que arranca a partir de um único ISO. Não há processos, nem chamadas de sistema, nem shell. A primeira plataforma em que é construído e testado é aarch64, e o mesmo código caminha para x86_64, por UEFI e por BIOS clássico, e para hardware real: o objetivo é um único ISO que arranque em todos eles. O projeto é de código aberto, sob licença MIT ou Apache 2.0, e neste texto queremos registar onde chegámos, como está organizado por dentro e o que aprendemos pelo caminho.

O que significa exatamente "unikernel"

Um broker habitual é um programa que corre sobre um sistema operativo. O urMQTT não tem sistema operativo por baixo: arranca sozinho através do firmware UEFI e do bootloader Limine, configura as suas próprias tabelas de páginas, programa o controlador de interrupções e o temporizador, encontra os dispositivos virtio através de PCIe, obtém um endereço por DHCP e escuta num único porto. Tudo o que normalmente seria feito pelo kernel, pelos controladores, pela pilha de rede e pela aplicação é aqui um único ELF que corre ao nível EL1.

A comparação com uma instalação típica fala por si:

As prioridades são, por esta ordem: segurança, escalabilidade, desempenho multinúcleo, pequena pegada e instalação imutável. Sempre que dois objetivos entram em conflito, ganha o que está mais acima nesta lista.

Onde estamos agora

O projeto está numa fase pré-alfa, mas já fechámos dezassete marcos de desenvolvimento, de M0 a M17. Hoje o urMQTT serve MQTT 3.1.1 sobre TLS 1.3 com certificados de cliente obrigatórios e guarda o estado em SQLite num disco em bruto. Em resumo, o que já funciona:

• Kernel: vetores de exceção próprios com relatórios descodificados, tabelas de páginas próprias com W^X imposto, páginas de guarda, PAC e BTI onde o processador os tem, GICv3 e GICv2, temporizador genérico, SMP até 64 núcleos.
• Deteção de hardware a partir de DTB ou ACPI, numa única descrição da plataforma, com resultado idêntico a partir de ambas as fontes.
• Controladores: PCIe ECAM, MSI-X, virtio-net, virtio-blk, virtio-scsi e virtio-rng, e um CSPRNG inicializado com entropia de hardware.
• Rede: DHCPv4, ARP, ICMP e IPv4 estrito próprios, e um TCP próprio apenas do lado do servidor: SYN cookies, roda de temporizadores hierárquica, NewReno, fusão de ACK, sem estado TIME_WAIT.
• TLS: apenas TLS 1.3, mTLS obrigatório, identidade do dispositivo a partir do CN ou do SAN URI; o handshake é feito pelo rustls e, depois dele, por uma camada de registos própria com AES-128-GCM e ChaCha20-Poly1305. Retoma de sessão com tickets PSK, lista de revogação, controlo de admissão logo no handshake.
• MQTT: codec sem cópia, testado com fuzzing e com clientes mosquitto reais; QoS 0 e 1, wildcards, mensagens retidas, testamento (LWT), sessões persistentes, ACL limitada a devices/{id}/#, limites de débito por dispositivo.
• Armazenamento: SQLite dentro do kernel através de um VFS sobre o disco em bruto, em modo WAL, com verificação de integridade no arranque; registo de dispositivos, revogações, mensagens retidas, sessões persistentes com filas de mensagens para dispositivos offline; por núcleo, um diário de telemetria separado com CRC por registo e recuperação após falha.
• Operação e supervisão: watchdog para os handlers, verificação de saúde, registo de logs limitado, syslog e statsd por UDP, admissão que sobrevive a tempestades de religações.
• Entrega: compilações bit a bit idênticas verificadas na CI, ISO e imagem de disco GPT em bruto, assinaturas minisign, instruções para KVM, Proxmox e Hetzner.

Cada passo está assinalado com o marco que o trouxe, e o ficheiro docs/PROGRESS.md no repositório é a única fonte de verdade sobre o que realmente funciona.

Arquitetura em três imagens

Todo o desenho está descrito em docs/ARCHITECTURE.md, e as razões de cada decisão importante estão registadas como ADR em docs/DECISIONS.md. Aqui fica uma visão geral.

Camadas

De cima para baixo: o broker (sessões, árvore de tópicos, QoS, mensagens retidas, testamentos, ACL, limites), o codec MQTT, TLS, TCP, a camada de rede e, por fim, os controladores. Ao lado deste caminho principal está o armazenamento (SQLite e diário de telemetria) e, por baixo de tudo, a gestão de memória, a deteção da plataforma e a configuração, que é convertida em constantes no momento da compilação, juntamente com o certificado da CA, o certificado do servidor e a chave incorporados. O hipervisor com os dispositivos virtio é a única coisa que fica fora da imagem.

Uma thread por núcleo, sem estado partilhado

Cada núcleo de dados executa o seu próprio ciclo, com a sua pilha TCP, os seus estados TLS, uma parte do broker (sessões e árvore de tópicos), a cache do heap e a partição de telemetria. Os núcleos não partilham qualquer estado mutável, apenas anéis limitados e sem locks, um para cada par ordenado de núcleos. O núcleo mais alto executa o SQLite e mais nada.

A placa de rede tem hoje um único par de filas, que pertence ao núcleo 0. Este encaminha cada fluxo MQTT para um dos núcleos de trabalho, segundo o hash Toeplitz do respetivo quádruplo, e envia o que os núcleos de trabalho devolvem. A sessão vive no seu núcleo de origem, determinado pelo hash do identificador do cliente, pelo que a tomada de controlo, os testamentos e a persistência nunca atravessam núcleos. Uma ligação que aterre noutro núcleo mantém aí o seu TCP e o seu TLS, mas reencaminha o MQTT simples para o núcleo de origem, com controlo de fluxo baseado em créditos. Cada mensagem encaminhada é também distribuída pelas restantes partes do broker, cada uma das quais mantém uma réplica das mensagens retidas.

Três regras mantêm este modelo coeso. Processamento até ao fim: um pacote recebido é tratado por inteiro num único núcleo, do TCP, passando pela decifragem TLS no local, pelo parsing de MQTT e pelo encaminhamento, até à resposta cifrada, sem filas de tarefas e sem cópias para buffers da aplicação. Polling adaptativo: sob carga, as filas de receção são consultadas ativamente e, em repouso, o núcleo regressa às interrupções e a WFI; os handlers de interrupção apenas confirmam a interrupção e marcam o trabalho. Watchdog: um tique de 10 ms por núcleo apanha os handlers que excedem o seu orçamento.

A vida de um PUBLISH

O dispositivo envia um registo TLS. A placa de rede entrega-o ao ciclo do núcleo através de um descritor, sem cópia. O ciclo verifica o TCP, decifra o TLS no local e faz o parsing do MQTT a partir do buffer emprestado; depois verifica em memória a ACL, o limite de débito e o caminho pela árvore de tópicos. Se outro núcleo estiver interessado nesse tópico, recebe uma mensagem de encaminhamento com uma referência ao conteúdo e o identificador do tópico; a base de dados recebe um registo de telemetria ou a atualização de uma mensagem retida, em lote. A resposta PUBACK é cifrada diretamente para o buffer de saída e fundida com o ACK de TCP, pelo que ao dispositivo chega um único segmento. A mensagem custa a outro núcleo uma cifragem por subscritor, no momento do envio.

Quanto custa uma ligação

O objetivo é no máximo 512 bytes por ligação TLS inativa, com a ambição de chegar a 256. Enquanto a ligação está em repouso, nada é retido para ela em buffers: os dados recebidos são processados diretamente a partir da trama de rede, e os buffers de envio, de registos e de MQTT só existem enquanto houver algo por concluir ou por confirmar. O kernel mede-o ele próprio: contadores exatos do heap, em bytes pedidos e em blocos ocupados, escritos de dez em dez segundos como heap acima do nível base por ligação aberta.

Medido sob HVF com quatro núcleos virtuais, três deles de trabalho, em que cada dispositivo mantém uma ligação mTLS e uma subscrição com QoS 1, incluindo o arredondamento do alocador:

O conjunto de tramas de rede é fixo, com cerca de 2 MiB, o que equivale a aproximadamente 200 B por ligação com dez mil ligações e a cerca de 2 B com um milhão. Não conseguimos medir mais do que isso: a rede de utilizador do QEMU no macOS deixou de aceitar ligações às 10 197, aproximadamente no limite de 10 240 descritores do processo QEMU. O valor desce à medida que as partes fixas se repartem por mais ligações, pelo que não cresce com o seu número.

Modelo de segurança

A segurança é a primeira prioridade e ganha todos os conflitos com os restantes objetivos. O modelo tem várias camadas:

• Um só porto. TCP 8883, apenas TLS 1.3, certificados de cliente obrigatórios assinados pela CA incorporada na imagem. O identificador do cliente MQTT tem de ser igual ao identificador do dispositivo constante do certificado.
• Sem entrada. Sem shell, sem entrada pela consola, sem SSH, sem API de administração, sem código dinâmico, sem SQL acessível pela rede e sem sistema de ficheiros.
• Segurança de memória. Rust, com forbid(unsafe_code) nos pacotes de protocolo; cada bloco unsafe tem um comentário // SAFETY: verificado por lint, e perante entrada externa não há panic: o clippy, nos pacotes do caminho de dados, proíbe unwrap, expect, indexação e panic!.
• Mitigação de exploração. O W^X é imposto pela codificação dos descritores e pelo bit SCTLR_EL1.WXN, e é auditado em cada arranque. Depois do arranque, as tabelas de páginas são só de leitura, sem alias gravável. A metade inferior do espaço de endereçamento está excluída. Cada pilha tem páginas de guarda e as exceções correm numa pilha separada. PAC e BTI são ativados quando o processador os suporta, o que é verificado pelos smoke tests.
• Resistência ao abuso. SYN cookies; a admissão recusa novas ligações, antes de qualquer criptografia, quando o heap está baixo, quando a base de dados está atrasada, quando há demasiados handshakes em curso por núcleo ou por endereço de origem, ou quando o ritmo de handshakes é demasiado elevado. Limites de débito por dispositivo, filas limitadas, janela TCP ligada à contrapressão do broker, registo de logs limitado, watchdog e verificação de saúde.
• Imutabilidade. A configuração, a CA e a chave do servidor estão incorporadas na imagem. Alterar seja o que for implica uma nova imagem.

O modelo de ameaças está registado em docs/SECURITY.md.

Armazenamento sem sistema de ficheiros

Os dados vivem num disco separado, virtio-blk ou virtio-scsi, no qual não existe sistema de ficheiros. A disposição é mínima e própria:

LBA 0      [ superbloco: magia · versão da disposição · uuid · tabela de regiões · CRC-32C ]
LBA 8, 16  [ tabela de tamanhos dos ficheiros, posições A/B (vence a mais recente válida) ]
LBA 64     [ base principal SQLite ½ ][ WAL do SQLite ⅛ ][ diário 1 MiB ][ diário de telemetria: 8 partições … ]
últimos 4 KiB [ espaço para a autoverificação do dispositivo de blocos no arranque ]

O SQLite (3.54.1 incorporado, com verificação do hash na compilação) é compilado para dentro do kernel com o clang, sem biblioteca padrão, e usa um heap memsys5 fixo. O seu VFS mapeia três ficheiros fixos para regiões do disco. Funciona em modo WAL com locking_mode=EXCLUSIVE, pelo que não precisa de um índice em memória partilhada, e com synchronous=FULL; se o quick_check no arranque encontrar um erro, o sistema pára em segurança. Na base de dados estão o registo de dispositivos, as revogações, as mensagens retidas e as sessões persistentes, com filas de mensagens QoS 1 para dispositivos que não estão ligados.

O núcleo da base de dados, o de número mais alto, executa o SQLite e mais nada. O plano de dados envia-lhe as alterações de estado através de um anel SPSC sem locks; este agrupa-as numa única transação a cada 5 ms ou a cada 512 operações e devolve as confirmações por outro anel. Um disco vazio é formatado no primeiro arranque; tudo o resto nunca é formatado por cima.

A telemetria segue outro caminho. Cada PUBLISH aceite em tópicos de storage.telemetry_topics vai para a partição do diário de telemetria do seu núcleo: um anel de segmentos com CRC por registo, salgado com a sequência do segmento, de modo que as passagens antigas do anel nunca voltam a aparecer. Os núcleos entregam os registos à base de dados através de um anel próprio, sem cópia, e esta escreve-os a cada 5 ms ou a cada 256 KiB. No arranque, a recuperação mantém todos os registos escritos, corta a cauda incompleta e continua num novo segmento. A retenção é por tamanho, através do anel, e por idade, através de retention_days. Verificámo-lo com um milhão de registos e com kill -9 a meio da escrita.

Os números

A ferramenta de carga em tools/loadgen faz três coisas: uma tempestade de handshakes TLS 1.3 com mTLS e CONNECT, ligações de longa duração com PINGREQ que publicam telemetria a cada segundo, e tempestades de religações. O make bench num Apple M4 Pro sob HVF dá:

O valor no convidado, em que o cliente e o servidor estão dentro da mesma máquina virtual e cada núcleo de trabalho funciona por si, mostra que o plano de dados escala linearmente. O valor de rede é limitado pela rede de utilizador de uma só thread do QEMU, não pelo convidado; isto também está registado, como ADR-032.

As tempestades de religações testamo-las fazendo com que todos os dispositivos se liguem ao mesmo tempo, repitam as tentativas recusadas com atraso e depois caiam todos sem DISCONNECT. O parâmetro heap_limit_mb= no modo de desenvolvimento faz com que a admissão considere o heap mais pequeno do que é, pelo que uma tempestade maior do que o heap pode ser testada com poucos sockets. Numa ronda destas, com 3 000 dispositivos, ligaram-se 1 368 em 36 segundos e 5 619 tentativas foram devidamente recusadas, com um limite de 8 MiB; a memória voltou ao normal depois da tempestade.

Como trabalhamos

O projeto é conduzido por uma especificação escrita, PROMPT.md, com o plano de marcos, e cada marco termina com o mesmo ritual: make check e make smoke a verde, um commit com a etiqueta M<n>, uma entrada em docs/PROGRESS.md e um ADR para cada decisão que não seja óbvia. As regras são curtas e não se negoceiam: sem panic perante entrada externa, unsafe apenas nos pacotes de hardware e FFI e sempre com comentário, sem alocações no caminho quente, um comentário junto de cada ordenação de operações atómicas, cada limite vem da configuração, e as partes provisórias intencionais falham de forma ruidosa.

A CI faz mais do que conseguiríamos fazer à mão: fmt, clippy para o host e para aarch64-unknown-none, typos, actionlint e shellcheck; testes em Linux e em macOS em arm64; compilação do kernel para as configurações de desenvolvimento e de produção, com o tamanho do ELF no resumo; arranque sob QEMU com todos os cenários do smoke test e guardando os logs de série; cargo-deny para avisos, licenças e fontes; um minuto de fuzzing em cada um dos onze alvos e, durante a noite, dez minutos por alvo com corpus em cache. Além disso, CodeQL, OpenSSF Scorecard, Dependabot e publicação com proveniência SLSA. Cada action de terceiros está fixada ao SHA completo do commit.

Levamos a reprodutibilidade à letra: o make repro compila o HEAD duas vezes em árvores de trabalho limpas e compara o ELF, o ISO e a imagem em bruto byte a byte. As versões publicadas são assinadas com minisign, e os artefactos podem ser verificados com gh attestation verify. A imagem de produção contém a chave privada do servidor, pelo que o próprio ISO é um segredo; as imagens que acompanham as versões no GitHub são de desenvolvimento, com chaves temporárias, e servem apenas para experimentar.

O que aprendemos

Algumas lições que mudaram o plano:

• Afinal, o TCP próprio compensou. O protótipo funcionava com o smoltcp e serviu-nos bem até ao M13. Mas um servidor que mantém centenas de milhares de ligações não precisa de um TCP de cliente: precisa de SYN cookies, de uma roda de temporizadores e de um estado de 96 bytes. No M14 substituímos o smoltcp por uma pilha própria apenas do lado do servidor, com testes de perda simulada e fuzzing de segmentos.
• Meçam a memória por dentro. As estimativas por ligação eram inúteis até o kernel começar a contar ele próprio o heap em blocos do alocador, e não em bytes pedidos. Só então vimos para onde vão realmente os 512 bytes e baixámos para 494.
• A ferramenta de teste faz parte do produto. A maior limitação não foi o kernel, mas a rede de utilizador do QEMU e o número de portos efémeros no computador de desenvolvimento. Para cem mil ligações ou mais é preciso vmnet-shared no macOS ou Linux com KVM, interface tap e vários endereços de cliente.
• SQLite sem sistema operativo é possível, mas só em condições estritas: heap fixo, bloqueio exclusivo sem memória partilhada, um VFS que desconhece ficheiros e uma admissão que não deixa a base de dados atrasar-se.
• As tempestades de religações são o estado normal, não a exceção. Quando a rede móvel cai e volta, milhares de dispositivos batem à porta ao mesmo tempo. Por isso a admissão recusa a ligação antes de qualquer criptografia, e cada ligação recusada custa quase nada.

O que se segue

O trabalho depois do M17 está planeado em três direções, e a ordem entre elas está registada em docs/PLAN.md. Nada disto está ainda construído.

• Um ISO para várias plataformas. O mesmo ficheiro urmqtt-<env>-<versão>.iso e uma única imagem GPT em bruto que arrancam em UEFI aarch64, UEFI x86_64 e BIOS x86_64, em máquinas virtuais e em hardware real, começando por um PC Intel. Continua a ser um aparelho com tudo lá dentro, reprodutível e assinado.
• Disco em bruto, sem sistema de ficheiros. Especificação do formato ao nível do byte, uma ferramenta de host urmqtt-disk que partilha os parsers com o kernel, alinhamento das regiões a 1 MiB, crescimento do disco com os dados, discard para discos de provisionamento dinâmico, snapshots A/B da base de dados, verificação de bits e, opcionalmente, cifragem AES-256-XTS com AES por hardware.
• Comprovadamente seguro. Revogação e lista de dispositivos permitidos em tempo de execução através de um canal de controlo assinado, sem nova imagem; testes diferenciais e de conformidade do TLS e do TCP próprios; KASLR, proteção da pilha, kCFI, MTE e um alocador reforçado; SQLite isolado ao nível EL0; Secure Boot; SBOM e cargo-vet; e, por fim, um pacote para auditoria externa.

As plataformas que oferecem apenas dispositivos não virtio, como o AWS ENA ou o Azure MANA, não são suportadas por agora. O Raspberry Pi 4 e 5 como anfitrião KVM, o Hetzner CAX e o Oracle Ampere A1 estão documentados e suportados no código, mas ainda não foram experimentados num serviço real.

Experimente

O repositório está em github.com/zeljan-alduk/urMQTT. Com o Rust com a toolchain nightly fixada e o QEMU, make certs, make run e um cliente mosquitto bastam para o primeiro PUBLISH sobre mTLS no seu próprio computador. O aviso do início vale também no fim: isto é pré-alfa, e tudo o que funciona está em docs/PROGRESS.md. Relatórios de erros, perguntas sobre o desenho e comunicações de segurança, seguindo as instruções em SECURITY.md, são bem-vindos. Voltaremos a falar aqui de cada marco seguinte.

Neste blog registamos o que aprendemos pelo caminho. Não textos de marketing, mas notas concretas: o que correu mal, como o resolvemos e o que faríamos de forma diferente hoje.

Sobre o que vamos escrever

• Bilhética no transporte público. Cartões sem contacto, módulos SAM, funcionamento sem rede e tudo o que um terminal tem de aguentar num veículo que vibra doze horas por dia.
• Aplicações móveis no terreno. Android e Flutter em dispositivos que não são telemóveis comuns: com leitores de cartões, impressoras e baterias que têm de durar um turno inteiro.
• Backend e monitorização da frota. Como saber que um dispositivo no veículo tem um problema antes de o motorista o comunicar.
• Hardware. Do protótipo na bancada à placa que vai para produção em série, e todos os erros pelo meio.
• Modelos de IA locais. Onde os modelos em hardware próprio fazem sentido, e onde a nuvem e uma API são simplesmente a melhor escolha.

Como vamos escrever

Curto e concreto, com código e números quando os temos. Publicaremos quando tivermos algo a dizer, não segundo um calendário. Os artigos são escritos em croata e traduzidos para todas as línguas deste site; também pode acompanhar-nos por RSS.

Se algum tema lhe interessa ou trabalha num problema parecido, escreva-nos para info@aldo.tech.