NoWayOS
PT
GitHub
MenuFechar

Comece aqui

Seu primeiro sistema no QEMU

Inicialize o seL4 no QEMU com um domínio de proteção em Rust, leia os três arquivos que definem um sistema, veja o seL4 parar uma parte que vai longe demais e clique pela interface de usuário.

Um sistema NoWayOS é um conjunto de domínios de proteção, as partes de um dispositivo, inicializados juntos sobre o seL4. Todo sistema inicializa primeiro no QEMU, dentro do contêiner de desenvolvimento, e verifica a própria saída. Esta página inicializa o menor deles, e depois alguns que mostram mais.

Inicialize o hello

make qemu-test SYSTEM=hello

Isso compila o sistema hello, verifica as suas concessões, inicializa o seL4 em modo headless no QEMU e observa o que ele imprime. O teste passa quando todas as linhas que o sistema precisa imprimir aparecem, em ordem, e nada proibido aparece.

Para inicializá-lo você mesmo e acompanhar, rode make qemu SYSTEM=hello. Saia do QEMU com Ctrl-A e depois x.

Os três arquivos que definem um sistema

Cada sistema é formado por três arquivos em systems/, ao lado do código Rust em pds/.

hello.system é a descrição de sistema do Microkit: cada domínio de proteção, região de memória, canal e interrupção que o sistema tem. O hello tem um domínio de proteção e mais nada:

<system>
 <protection_domain name="hello" priority="1" stack_size="0x10000">
 <program_image path="nowayos-hello.elf" />
 </protection_domain>
</system>

hello.grants lista tudo o que o sistema concede, um fato por linha. O build falha se a descrição conceder algo que não esteja listado aqui, ou se o arquivo listar algo que ela não concede, então uma mudança no que um sistema pode fazer fica sempre visível na revisão:

system demo
role hello app

pd hello priority=1 budget=1000 period=1000

hello.expect lista as linhas que o sistema precisa imprimir, em ordem, e, depois de um !, textos que reprovam o teste na hora, onde quer que apareçam:

NOWAYOS: rust pd starting
NOWAYOS: hello from rust

!MON|ERROR
!seL4(CPU
!panicked

O mesmo arquivo expect verifica o sistema num Raspberry Pi 5, a partir do log serial da placa.

O próprio domínio de proteção

pds/hello/src/main.rs é o programa inteiro. Ele segue a forma mínima do exemplo de Microkit do rust-sel4: init roda uma vez no início, e o handler receberia notificações se o sistema lhe desse algum canal.

#![no_std]
#![no_main]

use sel4_microkit::{Handler, Infallible, debug_println, protection_domain};

#[protection_domain]
fn init() -> HelloPd {
 debug_println!("NOWAYOS: rust pd starting");
 debug_println!("NOWAYOS: hello from rust");
 HelloPd
}

struct HelloPd;

impl Handler for HelloPd {
 type Error = Infallible;
}

Não há heap (qualquer alocação falharia na linkedição), nem unsafe, nem dispositivo. Imprimir só funciona porque este é um build de depuração: um kernel de release não tem console de depuração.

Veja o seL4 parar uma parte

make qemu-test SYSTEM=isolation-test

Dois domínios de proteção de sondagem tentam, cada um, algo que não lhes foi concedido: um lê memória que não está mapeada para ele, o outro escreve numa página que só pode ler. O seL4 para cada um com uma falha, e um terceiro domínio, só de espectador, continua rodando intacto. A última linha do teste diz isso:

NOWAYOS: isolation-test: 2 of 2 forbidden accesses faulted and were contained; bystander still running

Mais sistemas para experimentar

Sistema O que ele mostra
ipc-demo Dois domínios de proteção trocam registros tipados por um anel compartilhado; um registro malformado é recusado
timer-demo O domínio de proteção de temporizador atende dois clientes e entrega os timeouts deles em ordem de prazo
supervisor-test O supervisor recebe uma falha e reinicia a placa, e a inicialização seguinte encontra a memória limpa
ui-demo A sessão roteirizada da interface de usuário, com um hash de cada quadro verificado

Rode qualquer um deles com make qemu-test SYSTEM=NAME, ou todos os sistemas com make qemu-test-all.

Clique pela interface de usuário

make qemu SYSTEM=ui-interactive VNC=1

A tela do QEMU é publicada via VNC em localhost:5900 na sua máquina, com uma senha impressa só para aquela execução. No macOS, abra vnc://localhost:5900 (no Finder: Ir, Conectar ao Servidor) e clique pelas telas da demo.

O que o build deixa ao lado de cada imagem

Em build/BOARD/SYSTEM/ (para estes, build/qemu_virt_aarch64/hello/ e assim por diante), ao lado de loader.img:

  • sel4-config.txt: a configuração do seL4 da imagem, e se ela está dentro das provas do seL4. Um build de depuração diz claramente que não está. Veja Segurança.
  • sbom.cdx.json: uma lista de materiais de software CycloneDX para a imagem: o kernel, o carregador, cada domínio de proteção e os crates dentro dele, cada um com o seu hash.
  • Os arquivos de licença do que a imagem contém, como as licenças da fonte e dos ícones.