Talvez seja hora de revisitar microkernels na era do hardware moderno

• No passado, microkernels tinham utilidade prática limitada por causa do alto overhead, mas hoje podem voltar a ser uma opção realista graças à popularização de IOMMU e memória compartilhada
• Isolar drivers e subsistemas no espaço do usuário permite limitar o alcance de falhas ou ataques, aumentando segurança, confiabilidade e modularidade
• Nas décadas de 1980 e 1990, processos em espaço do usuário não podiam acessar dispositivos diretamente, então até operações como leitura de disco exigiam chamadas de sistema e trocas de contexto, além de locks e cópias de memória
• Com IOMMU e filas de comandos compartilhadas, é possível tratar IPC assíncrono e acesso a dispositivos no caminho normal sem trocas de contexto, cópias entre espaços de endereço nem locks
• Também é possível aproveitar componentes existentes como Xen, FreeBSD e Linux DRM, então o custo de criar hipervisor e servidores de sistema do zero não é tão alto

---

Estrutura dos microkernels e efeitos do isolamento

• Um microkernel é uma arquitetura de kernel que executa no espaço do usuário tudo o que não seja escalonamento, controle de acesso a dispositivos de I/O e comunicação entre processos (IPC)
• O isolamento de subsistemas oferece três vantagens
  • Segurança: a vulnerabilidade de um único driver pode dar ao invasor acesso apenas àquele subsistema ou driver, e não ao sistema inteiro
  • Confiabilidade: a falha de um subsistema afeta apenas aquela parte, e não o sistema todo
  • Modularidade: reduz a carga sobre a equipe do kernel Linux de precisar integrar todos os drivers de hardware e revisar até o funcionamento interno de cada chip
• Se o Windows fosse um sistema de microkernel, o bug da CrowdStrike talvez tivesse se limitado a interromper apenas a coleta de telemetria de parte dos responsáveis por segurança de TI

Limites de desempenho no passado e a solução com IOMMU

• Nos microkernels do passado, processos em espaço do usuário não podiam acessar certos dispositivos diretamente, então cada operação exigia chamadas de sistema e trocas de contexto, além de locks caros e cópias de memória
  • O Mach, por causa de problemas de desempenho, foi gradualmente trazendo processos de espaço do usuário para dentro do kernel e acabou ficando mais próximo de um kernel monolítico comum
• Hoje, PCs já vêm com IOMMU como padrão há cerca de 10 anos, e seu uso com memória compartilhada permite eliminar completamente as trocas de contexto no caminho normal quando há núcleos suficientes
  • Aceitando um pouco mais de latência, também é possível quase eliminar as trocas de contexto no geral
  • Um escalonador baseado em tecnologia de virtualização pode ser estruturado de forma semelhante ao hipervisor Xen
  • O acesso a dispositivos de I/O é gerenciado pelo hardware IOMMU
• O IPC pode ser implementado alocando buffers compartilhados entre processos e fornecendo compare-and-swap atômico sobre inteiros
  • O buffer compartilhado pode ser usado como uma fila de comandos em forma de ring buffer, atualizando atomicamente os ponteiros de início e fim
  • No caminho normal, mensagens assíncronas podem ser entregues sem trocas de contexto, cópias entre espaços de endereço nem locks, e essa abordagem já é amplamente usada em drivers de GPU

Organização por bibliotecas e reaproveitamento de código existente

• Em ambientes nos quais o processo é um guest de VM, bibliotecas compartilhadas podem ser linkadas na inicialização do programa, e funções que não precisam rodar em outro processo podem ser tratadas localmente no estilo exokernel
  • Hoje, com aplicações no estilo Electron distribuindo seus próprios componentes de sistema operacional, bibliotecas duplicadas na memória não são um problema tão grande quanto eram há 30 anos
• A base principal necessária para a implementação também já existe
  • Xen já tem a maior parte das funções necessárias na camada de hipervisor
  • Como no Mach, é possível compor servidores de rede e sistema de arquivos, mas aproveitando código do FreeBSD
  • Como o DRM já é baseado em buffers de comando assíncronos, o subsistema gráfico do Linux pode rodar no espaço do usuário
  • Por conveniência, também é possível executar o servidor de display e o subsistema gráfico no mesmo processo

[GN⁺]

Comentários do Lobste.rs

• O motivo de o Linux incluir todos os drivers é que não existe uma API estável para módulos de kernel fora da árvore, e um microkernel não é obrigatório para oferecer esse tipo de API

  • Mesmo um microkernel não evita a instabilidade da API interna; ele apenas faz isso atravessar a fronteira entre processos
    Lembro de ter visto reclamações na LKML de que, mesmo assumindo que todos os drivers do Linux fossem movidos para o espaço do usuário, mudanças na API interna ainda ficariam difíceis

• Pelo que sei, os kernels da família L4 são conhecidos por serem rápidos. Fico curioso sobre como ficam Redox OS e Fuchsia

  • O kernel L4 pode ser rápido, mas na prática só parece útil em sistemas embarcados com configuração muito fixa
    O Genode suporta vários kernels, mas em seL4 e outros o desempenho é ridiculamente ruim. Quando colegas meus tentaram iniciar uma VM Linux, só havia suporte a 32 bits, e mesmo para dar meio boot levava vários minutos
    Há um motivo para o fork do Genode para o microhipervisor NOVA ser a plataforma padrão: ele realmente funciona e o desempenho é suficiente
  • Pela documentação do Redox, ainda há troca de contexto ao montar mensagens de requisição, provavelmente por causa da etapa de validação
    Como usa buffer circular, se o receptor já estiver rodando em outro núcleo talvez a segunda troca de contexto não seja necessária. Interpretar a mensagem sem troca de contexto pode exigir que o receptor valide a mensagem, o que pode ampliar demais a superfície de ataque, embora pareça haver espaço para mitigar isso com bibliotecas dinâmicas fornecidas pelo kernel
    Não sou especialista, mas tive a impressão de que o texto original deixa de fora algumas considerações importantes

• QNX é conhecido como um microkernel rápido, então fico curioso sobre o que ele acertou

  • Pela minha experiência direta, o QNX não era rápido
    Há muito tempo, eu e um amigo ficamos encantados com a elegância dos microkernels, especialmente do QNX, e implementamos um problema de processamento de vídeo baseado em FireWire. O código era simples e bonito, mas era terrivelmente lento. Na época, ao adicionar suporte a transmissão isócrona com DMA ao driver 1394 do Linux em cerca de 12 horas, o desempenho melhorou muito, e isso também acabou com o ceticismo da empresa quanto ao uso de Linux em seu equipamento de seleção óptica
    Os ideais do QNX, dos microkernels e da passagem de mensagens continuam excelentes, mas para se estabelecerem amplamente será preciso reduzir muito mais o custo de transferência de dados entre processos
    Hoje faço aplicações web em Elixir e desfruto do mesmo isolamento de processos que o QNX defendia. Como não é uma carga crítica de desempenho como processamento óptico, tudo bem, mas Elixir/BEAM também sofre do mesmo problema de cópia de dados

• Mesmo que o Mach não tenha conseguido separar completamente os componentes como previsto originalmente, ouvi dizer que ele não se tornou um kernel monolítico comum, e que sua arquitetura ainda oferece vantagens
  Em benchmarks clássicos de listagem de arquivos POSIX, como chamar readdir() e stat() para cada item, o microkernel inevitavelmente fica em desvantagem. Mas, usando APIs em lote como io_uring para reduzir a frequência de chamadas de sistema, a alta latência talvez não seja uma fraqueza tão grande

  • Em “on μ-Kernel Construction”, 1995, Liedtke atribuiu a lentidão do Mach ao grande uso de cache, ou seja, a um projeto que não era pequeno o bastante
    No Linux também não dá para acompanhar a velocidade da linha se você fizer uma chamada de sistema para cada pacote de rede. Processamento em lote é importante tanto no Linux quanto em microkernels

• Um participante recente interessante nessa área é HongMeng, mas infelizmente é software proprietário

• A menos que o custo de movimentação de dados caia mais de uma ordem de grandeza, parece difícil que microkernels consigam competitividade suficiente
  Em teoria são elegantes e limpos, mas a realidade é complexa, então talvez o kernel também precise ser complexo até certo ponto para lidar com isso

• Gosto de arquiteturas corretas, mas acho que a posição dominante do Linux também deve muito a fatores secundários além da pura tecnologia. Eu gostaria de ler um texto que analisasse isso sob vários ângulos