Quais são as possíveis armadilhas de ter um kernel mínimo que executa código gerenciado?

Suponha que eu queira construir um sistema operacional baseado em um kernel inferior nativo muito pequeno que atue como um interpretador de código gerenciado / tempo de execução e um kernel superior maior compilado em uma linguagem de máquina não nativa (Java bytecode, CIL etc.). Exemplos de sistemas operacionais semelhantes seriam Singularity e Cosmos .

Que armadilhas e desafios de desenvolvimento existem ao escrever um sistema operacional com esse tipo de infraestrutura em contraste com uma solução puramente nativa?

Dependendo do idioma, pode haver muitos desafios de desenvolvimento:

1. Ponteiros: se um idioma não tiver ponteiros, será um desafio realizar tarefas relativamente fáceis. Por exemplo, você pode usar ponteiros para gravar na memória VGA para imprimir na tela. No entanto, em uma linguagem gerenciada, você precisará de algum tipo de "plug" (do C / C ++) para fazer o mesmo.

2. Montagem: um sistema operacional sempre precisa de alguma montagem. Idiomas como C #, Java etc. não funcionam tão bem com isso, ao contrário do C / C ++. Em C ou C ++, você também pode ter um assembly embutido, o que é muito, muito útil para muitas tarefas. Existem MUITOS casos em que isso é necessário (exemplos em x86): carregamento de um GDT, carregamento de um IDT, ativação de paginação, configuração de IRQs etc.

3. Controle: se você estiver usando algo como o Cosmos, não terá controle total. O Cosmos é um micro-kernel e essencialmente "inicia" o seu "kernel". Você pode implementar algo como o Cosmos do zero, se realmente quiser, no entanto, isso pode levar muito, muito tempo.

4. Sobrecarga: com idiomas gerenciados, há MUITA sobrecarga em comparação com C ou mesmo C ++. Coisas como o Cosmos precisam implementar muitas coisas antes que até um kernel hello world C # possa ser executado. Em C, você está pronto para começar, nenhuma configuração real é necessária. No C ++, há apenas algumas coisas que precisam ser implementadas para usar alguns dos recursos do C ++.

5. Estruturas: No C / C ++, existem estruturas que muitas linguagens gerenciadas não possuem e, portanto, você precisa implementar alguma maneira de ter algo como uma estrutura. Por exemplo, se você deseja carregar uma IDT (tabela de descritores de interrupção), em C / C ++, é possível criar uma estrutura (com um atributo compactado) e carregá-la usando a instrução x86 ASM lidt . Em um idioma gerenciado, isso é muito mais difícil de fazer ...

Idiomas gerenciados, em termos de sintaxe, são mais fáceis, no entanto, pois muitas coisas relacionadas ao sistema operacional muitas vezes não são muito adequadas. Isso não significa que eles não possam ser usados, no entanto, algo como C / C ++ é frequentemente recomendado.

Ouvi dizer (por um pesquisador que trabalha em uma técnica concorrente de microkernel ) que pouco se sabe sobre como avaliar a segurança de sistemas extensíveis por meio de código gerenciado.

O problema é que os tipos de bugs que podem causar uma falha na segurança são muito diferentes do que os pesquisadores de segurança estão acostumados. Em um microkernel tradicional, todos os drivers e outras subpartes do kernel são isolados um do outro, executando-os em diferentes espaços de endereço. Em um microkernel em que o isolamento é implementado por meio de código gerenciado de verificação de tipo, você evita as enormes despesas gerais de trocar espaços de endereço toda vez que precisar usar um sub-serviço, mas a desvantagem é que agora é mais difícil avaliar o mecanismo de isolamento.

Qualquer parte específica do kernel (digamos, um driver de dispositivo) escrita no idioma gerenciado é segura se e somente se o verificador de tipos indicar que o driver é seguro e que o verificador de tipos não possui bugs. Portanto, o verificador de tipos faz parte do núcleo do kernel. Na prática, parece que os verificadores de tipo são consideravelmente maiores e mais complicados do que os núcleos tradicionais de microkernel. Isso significa que a superfície de ataque é potencialmente maior.

Não sei se as técnicas tradicionais de isolamento de micro-kernel ou técnicas de isolamento baseadas em código gerenciado são realmente mais ou menos confiáveis. Há um problema de inicialização aqui: até que as técnicas de isolamento de código gerenciado sejam amplamente usadas, não saberemos com que frequência elas são inseguras. Mas, sem saber quão inseguras elas são, é difícil implantá-las em situações críticas à segurança.