Marco 19 · Rede útil

A userland agora usa DHCP, DNS e TCP sem tocar na placa.

O kernel negocia a configuração, valida os pacotes e oferece duas syscalls pequenas; NET.ELF torna a prova visível.

Entender o C

2 MiB
disco virtual fixo
7 ELF64
apps C em ring 3
2 GiB
perfil de desenvolvimento
COM1 · 0x3F8 verificado

saída do SOIA

soia> run net.elf
DHCP 10.0.2.15/24: OK
UDP OFFER + ACK: OK
gateway.soia → 10.0.2.2: OK
TCP SYN → SYN-ACK → ACK: OK
Memoria devolvida: OK.

Ambiente seguro

Um computador dentro do computador.

O QEMU cria um laboratório isolado. O SOIA enxerga recursos virtuais; seu Windows e seu disco físico ficam fora do experimento.

O que entregamos
1 CPU virtual, perfil de 64 MiB ou 2 GiB, tela, teclado, COM1 e a imagem do projeto.

O que não entregamos
Seu HD/SSD físico, arquivos pessoais ou acesso direto ao Windows.

Seu ritmo

Escolha a profundidade.

Você pode trocar de nível a qualquer momento. O assunto continua o mesmo.

Seção especial · C no SOIA

Não é “C+”. É C freestanding.

C++ é outra linguagem e ainda não foi habilitada. Aqui o Clang transforma C em instruções x86_64 que o SOIA consegue carregar.

C é uma forma mais curta e organizada de escrever regras. A CPU continua executando código de máquina; o compilador faz a tradução.

O alvo é x86_64-unknown-none-elf. Não há Windows, libc, runtime hospedado ou símbolos externos.

Assembly

Controle fino.

Ideal para boot, registradores, interrupções e mudanças de privilégio.

mov cr3, rax
C++

Ainda não.

Exigiria definir runtime, construtores, new/delete, exceções e RTTI.

etapa futura

libsoia é a ponte: organiza registradores e chama INT 0x80. O aplicativo não toca no hardware.

.datavariável com valor gravado no ELF

.bssvariável que começa zerada

W^Xgravável ou executável; nunca ambos

agoraTERMINAL.ELF

Comandos, histórico, métricas e arquivos.

agoraNOTEPAD.ELF

Ctrl+S persiste NOTE.TXT no disco virtual.

agoraMONITOR.ELF

CPU, RAM, SOIAFS1, ATA, scheduler e rede.

agoraNET.ELF

DHCP, UDP, DNS e TCP por syscalls validadas.

agoraPersistência

Capacidade fixa, escrita e blocos livres.

Estudar C freestanding em detalhes

Marco 11 · Interface gráfica

De letras prontas a pixels controlados.

Antes, a VGA entregava uma grade pronta de caracteres. Agora o SOIA recebe uma tela vazia e decide a cor de cada ponto.

O estágio 2 seleciona VBE, copia a fonte BIOS 8 × 16 para 0x6000 e entrega ao kernel o endereço do framebuffer XRGB8888 informado pelo ModeInfo.

O salto conceitual

Um endereço agora representa uma cor.

Pense no framebuffer como papel quadriculado: para colorir um quadrado, o kernel encontra sua posição e grava o número da cor.

O pixel (x, y) fica em framebuffer + y × 4.096 + x × 4. O valor 0x00RRGGBB contém diretamente os três canais.

1024 × 768
786.432 pixels
32 bpp
XRGB8888 direto
3.145.728 bytes
framebuffer inteiro
118 × 39
células do terminal

Já funciona
1024 × 768 em janela GTK 1:1, terminal e notas C, foco por F1/F2/F3, texto 8 × 16, cursor, Backspace e rolagem.

Custo medido
2,56× mais pixels e cerca de 1,83 MiB adicionais de memória de vídeo.

Estudar o Marco 11 completo

Marco 13.1 · Monitor do sistema

Três programas pedem. O kernel mede e decide.

Terminal, notas e monitor são aplicativos C separados; o kernel conserva as chaves e fornece métricas validadas.

Três ELF executam em CPL 3. O scheduler usa round-robin, SLEEP e HLT; o TSC virtual separa trabalho de tempo ocioso.

A viagem de uma linha

De cat até os bytes do disco.

SOIA · janela 118 × 39
SOIA Terminal 0.7 - rede e processos em ring 3
F1 Terminal | F2 Notas | F3 Monitor | F4 ultimo app

soia> echo ola
ola
soia> ticks
ticks: 46
soia> _
01Terminalpixel, cursor e rolagem
02Shelllinha, comparação e comando
03Kernelautoridade e validação

Contrato INT 0x80

Vinte e quatro pedidos pequenos e verificáveis.

RAX escolhe o serviço; registradores carregam argumentos e o retorno.

01writetexto → terminal
02read_keyfila → caractere
03clearredesenha a janela
04get_ticksconsulta IRQ0
05free_pagesconsulta memória
06read_direntrada da raiz
07read_filenome → bytes
08probeprova do aplicativo
09system_infométricas do SOIA
10active_taskconsulta o foco
11sleepespera sem polling
12set_cursoratualização parcial
13text_colorpaleta protegida
14write_filesalva NOTE.TXT
15spawncria CALC.ELF
16exitfinaliza o filho
17waitbloqueia o pai
18process_infoalimenta ps
19brkcresce o heap
20process_handlePID → handle
21ipc_sendcopia uma mensagem
22ipc_receiverecebe ou bloqueia
23dns_resolvenome → IPv4
24tcp_probehandshake virtual

O endereço também é conferido. O shell não pode apontar para qualquer lugar e mandar o kernel escrever.

Leitura: texto, dados, pilha ou heap concedido. Escrita: dados/BSS, pilha e heap RW+NX, nunca acima do break atual.

helpMapa do shell

Mostra os comandos disponíveis.

clearJanela limpa

Redesenha a interface e reposiciona o cursor gráfico.

echo TEXTOTexto de volta

Preserva o trecho digitado depois do espaço.

ticksTempo do kernel

Consulta quantos pulsos de 20 Hz ocorreram.

memRAM disponível

Consulta as páginas físicas livres de 4 KiB.

statusResumo honesto

Mostra CPU pelo TSC virtual, uptime, RAM, SOIAFS1, ATA e tarefas.

lsDiretório raiz

Percorre as entradas oferecidas pela VFS.

cat ARQUIVOArquivo real

Lê README.TXT, NOTE.TXT ou outro arquivo da raiz pelo nome.

psTabela de processos

Mostra PID, estado e nome das vagas ocupadas.

run CALC.ELFNovo processo

Cria a calculadora, aguarda sua saída e recolhe a memória.

run HEAP.ELFMemória dinâmica

Testa malloc, free, calloc e páginas sob demanda.

run IPC.ELFMensagem isolada

Envia ping, recebe pong e prova que um handle antigo deixa de valer.

run NET.ELFRede útil

Mostra DHCP, UDP, DNS e um handshake TCP real no QEMU.

Marco 13.1 · telemetria protegida

O painel vê números; o kernel toca nos sensores.

valores · 500 ms
SOIA Monitor 0.1
CPU virtual     4%
terminal        0%
notas           0%
monitor         3%
RAM usada       192 KiB
SOIAFS1         105.070 / 2.065.408 B
ATA             leituras + escritas · 0 erros
rede RTL8139    DHCP 1 · UDP 2 · DNS 2 · TCP 2
01SLEEP + HLTtempo ocioso real
02TSC virtualintervalos mais finos
03SET_CURSORsem apagar a janela
04CP437 + corblocos sem Unicode
Estudar o Marco 13.1 completo

Teste comportamental

O QEMU realmente digita.

O teste injeta comandos e percorre dez posições com as setas. O resultado só aparece se IRQ1, fila, tarefa, syscall, terminal, VFS e ATA cooperarem.

soia> ls
README.TXT
soia> cat readme.txt
Ola do SOIAFS: bytes persistentes no disco virtual.

Limite honesto

Janela funcional, ainda fixa.

  • ASCII, sem acentos ou teclado USB
  • histórico volátil limitado a dez comandos
  • CPU mede a vCPU do SOIA, não o Ryzen inteiro
  • sem temperatura, energia ou frequência turbo
  • escrita limitada a NOTE.TXT, sem delete ou diretórios
  • terminal, notas e monitor são ELF carregados do disco
  • Ctrl+S salva até 2.047 bytes no SOIAFS1
  • sem mouse, compositor ou janelas móveis
Estudar o Marco 13 completo

Capítulo zero · A base

Do interruptor ao endereço.

Antes de estudar kernel, precisamos separar três perguntas: qual é o valor, onde ele está e o que ele significa.

1Veranalogia + desenho 2Manipularmude os valores 3Preverpense antes 4Conferirveja a conta 5Aplicaruse o SOIA real

01 + 02 · Bit e byte

Oito interruptores formam um byte.

Cada bit é uma escolha entre 0 e 1. Ligue alguns interruptores; os pesos ligados são somados.

Um byte possui 2⁸ = 256 combinações. O bit mais à direita vale 2⁰; o mais à esquerda vale 2⁷.

Valoré o número guardado Representaçãoé como o escrevemos Significadodepende de quem lê

Um byte nem sempre viaja bit por bit. A COM1 usa start e stop; o ATA PIO entrega 16 bits por leitura.

A COM1 atual usa 38.400 baud em 8N1: 26,04 µs por bit e 260,42 µs por quadro. Offset localiza bytes já armazenados; não delimita o sinal.

Comparar tempo e enquadramento no Playground
Laboratório de 1 byte Toque nos bits
128643216 8421
Binário01010101
Hexadecimal0x55
Decimal85
Como textoU

Pesos ligados: 64 + 16 + 4 + 1 = 85

O U só aparece porque ASCII interpreta 0x55 como texto. Em uma instrução, o mesmo byte teria outro significado.

03 · Hexadecimal

Quatro bits cabem em um símbolo.

Hexadecimal conta com dez números e seis letras. Cada casa vai de 0 a F; depois de 0F vem 10.

08090A0B 0C0D0E0F 10

00 até FF 256 valores possíveis · máximo decimal 255

Meio byte = 1 nibbleEscolha um símbolo
5
Binário0101 Decimal5

04 · A rua da memória

Base é o começo. Offset é a distância.

A base é o número da porteira do terreno; o offset diz quantas casas andar dentro dele. Somando os dois, chegamos ao endereço.

Neste exemplo, segmentos estão zerados e ORG 0x7C00 corresponde à carga da BIOS. Em modo real, a regra geral é segmento × 16 + deslocamento.

Base
onde a região começa
Offset
distância desde o começo
Endereço
posição resultante no espaço
Calculadora hexadecimalTente prever antes de conferir
Endereço 0x7DFE

0x7C00 + 0x01FE = 0x7DFE · o offset vale 510 em decimal.

05 · Primeiro setor

Um terreno com exatamente 512 posições.

A BIOS copia o primeiro setor para 0x7C00. Os offsets começam em zero, então o último byte fica em 0x1FF, não em 0x200.

primeiro endereço0x7C00 assinatura0x7DFE e 0x7DFF

55 AA não é o texto “55 AA”. São dois valores binários usados pela BIOS como uma marca de setor inicializável.

Encontrar no stage1.bin ↓

06 · CPU e significado

Os bytes não mudam. A interpretação muda.

A CPU moderna inicia em um estado compatível com PCs antigos. Nosso carregador prepara gradualmente os ambientes de 32 e 64 bits antes de entregar o controle ao kernel.

A analogia que ajuda A CPU acorda com um manual antigo.

Ela começa com regras compatíveis com o 8086 e precisa ser preparada para usar os modos modernos.

Onde a analogia para 16 bits não significa ler só 2 bytes.

É principalmente o tamanho padrão de operandos e registradores. Instruções x86 têm tamanho variável.

Outro cuidado “Enxerga 1 MiB” é uma aproximação.

O modo real usa segmento × 16 + deslocamento; a linha A20 acrescenta uma nuance no limite.

Próxima volta do ciclo

Agora confronte a ideia com bytes reais.

O laboratório mostra offset, hexadecimal, texto e instrução nos arquivos que realmente inicializam o SOIA.

Abrir laboratório binário Ler o capítulo completo

Marcos 09 + 15 · Disco e persistência

Da porta do disco até salvar um nome.

O disco é o depósito, o driver busca caixas, o sistema de arquivos organiza e a VFS oferece um catálogo comum.

O kernel usa ATA PIO com LBA28, valida o SOIAFS1 v2, consulta o bitmap e grava dados e metadados com flush.

Capacidade fixa

4.096 caixas de 512 bytes.

2.097.152 bytesdisco virtual de 2 MiB

inicialização núcleo volume SOIAFS1

A distinção que evita a confusão

A caixa aumenta. O endereço inicial não.

Setor organiza bytes persistentes no disco. Endereço identifica onde cada byte será colocado na RAM durante a execução.

Armazenamento persistente

Disco · caixas de transporte

Os doze setores acomodam configuração DHCP, parsers, checksums, buffers e contratos de rede. O último setor continua preenchido até fechar sua caixa de 512 bytes.

bootloader 56 setores copia em sequência
Espaço de execução

RAM · rua de endereços

O começo continua em 0x10000. Apenas o fim passa de 0x157FF para 0x16FFF. Aqui cada endereço nomeia um byte; o kernel também gerencia a RAM em páginas de 4 KiB.

Em uma frase

O disco ganhou quatro caixas de kernel; na RAM, o mesmo terreno inicial recebeu 6.144 bytes a mais no final.

LBA 62 · setor relativo 0

Superbloco

A ficha que permite reconhecer e validar o volume antes de confiar nele.

0x00
assinatura
SOIAFS1\0
0x08
versão
2
0x0C
entradas
9
0x10
diretório relativo
1
0x14
setores do volume
4.034
0x30
setores livres
3.819
LBA 63–64 · relativos 1–2

Diretório + bitmap

Entradas associam nomes aos dados; um bit marca cada setor livre ou ocupado.

exemplo · 16 BTERMINAL.ELF setor relativo4 tamanho real22.704 B tipoarquivo
volume62 + relativo4 = inícioLBA 66

O transporte

ATA PIO lê e escreve uma palavra por vez.

O kernel informa a caixa, espera o disco e transporta um setor entre a imagem e a RAM.

0x20 + REP INSW leem; 0x30 + REP OUTSW escrevem; 0xE7 solicita flush.

capacidadeIDENTIFY 256 palavras16 bits bloco512 bytes

A abstração

Quem pede não acessa portas.

A VFS recebe um nome. O driver do formato localiza a entrada; o driver de bloco busca os bytes.

vfs_read_file("README.TXT")
  └─ soiafs_lookup()
      └─ ata_read_sector(40)

Evidência no QEMU

O conteúdo sobreviveu a outro boot.

O teste salva NOTE.TXT, fecha o primeiro QEMU e exige o texto ao iniciar outro com a mesma imagem.

  1. 1Salvardados · Ctrl+S
  2. 2Marcarbitmap + diretório
  3. 3Reiniciarmesma soia.img
  4. 4ReabrirNOTE.TXT intacto
“NOTE.TXT carregado do disco virtual.”

Gravável, com uma fronteira pequena e explícita. Somente NOTE.TXT, com até 2.047 bytes, pode ser salvo. A imagem limpa começa com 215 usados · 3.819 livres no volume. Ainda não existem exclusão, diretórios, journal ou recuperação.

Estudar o Marco 15 completo

Fundamentos do núcleo

Abra somente a camada que quer estudar.

Estes marcos sustentam o terminal atual. O seletor evita repetir toda a história na página; a documentação Markdown conserva o desenvolvimento completo.

A syscall atual pertence ao Marco 10; aqui, Processos explica apenas o isolamento e a troca de tarefas que a tornam possível.

Marco 08 · Isolamento

Mesmo endereço. Memórias diferentes.

Cada programa vive em seu próprio apartamento. O número da sala pode ser igual; a planta escolhida pela CPU leva a lugares físicos diferentes.

Cada tarefa possui CR3, tabelas, código e pilhas próprios. PTEs de usuário usam U/S=1; as folhas do kernel permanecem U/S=0.

Autoridade em camadas

Ring 3 pede. Ring 0 decide.

A CPU impede que programas comuns executem instruções privilegiadas ou escrevam nas páginas do kernel.

Tradução por tarefa

CR3 escolhe a planta.

RIP 0x100000000
as duas enxergam0x100000000endereço virtual
Tarefa ACR3 APágina física A
Tarefa BCR3 BPágina física B

O mesmo número não significa o mesmo lugar depois da tradução.

Preempção a 20 Hz

O timer pode retirar a CPU de uma tarefa.

round-robin · A ↔ B
fotografia salva
15 registradoresRAX…R15
5 campos da CPURIP · CS · RFLAGS · RSP · SS
160 bytes
Do Marco 8 ao Marco 10

Isolamento, CR3 e scheduler ficam aqui. O contrato atual de INT 0x80, suas vinte e quatro syscalls e a prova interativa pertencem ao Terminal.

Detalhes do Marco 8

Marco 07 · Gerenciamento

RAM não é um terreno vazio.

A BIOS entrega uma planta. O kernel abre caminhos somente até a memória existente e distribui quartos de 4 KiB sem colisões.

E820 descreve intervalos físicos; 1.024 PDEs de 2 MiB ampliam o mapa e um bitmap controla 524.288 quadros de 4 KiB.

Mapa recebido da BIOS

E820 separa utilizável de reservado.

boot_info v2

Esquema didático: o mapa real contém várias entradas e pode ter pequenos “buracos” reservados.

Dois tipos de endereço

Virtual passa por uma tradução.

código usavirtual0x02000000
tabelasCR3consulta
RAM recebefísico0x02000000

Hoje os números são iguais: isso é um mapeamento identidade. A tradução ainda existe.

Um bit por página

Um painel compacto de ocupação.

11 11 1000 0010 0000
reservada ocupada livre

1 não pode ser entregue; 0 está livre para alocação.

Autoteste real no boot

Não basta dizer que funciona.

  1. 1Alocarrecebe página P
  2. 2Escrevergrava SOIAMEM7
  3. 3Liberardevolve P
  4. 4Reutilizarmesma P, zerada
aprovado no QEMU

A máquina ganhou campainhas

Eventos chegam ao kernel.

Em vez de perguntar sem parar se algo aconteceu, o kernel dorme. Timer e teclado tocam a campainha quando precisam de atenção.

IRQ0 e IRQ1 passam pelo PIC remapeado, chegam aos vetores 0x20 e 0x21 da IDT e retornam com IRETQ.

IDT na prática

A CPU recebeu o vetor 33. E agora?

registrador IDTR base 0x20000 · limite 4095
IRQ 1pedido do tecladolinha física
vetor 33índice para a CPU0x21 em hexadecimal
entrada 33porta na IDTguarda um endereço
ISRrotina do tecladocódigo executado
CPU recebe33vetor
cada porta16 Bdescritor
deslocamento0x21033 × 16
base da IDT0x20000IDTR
porta consultada0x20210entrada 33

Dentro de uma entrada

Uma porta de 16 bytes.

atributo 0x8E

O endereço da rotina é repartido em três pedaços porque o formato da porta evoluiu junto com a família x86.

O espaço de 8 bits

256 vetores não significam 256 aparelhos.

0–31exceções da CPUdivisão por zero, página inválida…
32–47IRQs do PICtimer 32 · teclado 33
48–255disponíveissoftware e futuras controladoras

O vetor é apenas um número de 8 bits usado como índice: 0 a 255.

Viagem completa da tecla A

O programa pausa e depois continua.

  1. 1

    Tecladolevanta IRQ 1

  2. 2

    PICentrega vetor 0x21

  3. 3

    CPUsalva RIP, CS e RFLAGS

  4. 4

    IDT[33]fornece o endereço da ISR

  5. 5

    ISRlê 0x60 e envia EOI

  6. 6

    IRETQrestaura e continua

Abrir a explicação técnica completa da IDT
Próxima consequência prática

IDT, vetores e a viagem da tecla ficam aqui. A fila de teclado, edição de linha e interpretação do comando estão reunidas no Terminal.

Detalhes do Marco 6

A primeira entrega

Do carregador ao núcleo do sistema.

O bootloader encontra o kernel, prepara a máquina, entrega uma ficha com o ambiente disponível e sai de cena.

O estágio 2 lê 56 setores por INT 13h/AH=42h em 0x10000, obtém o mapa E820, prepara VBE, entra em long mode e salta com RAX=SOIABOOT e RDI=&boot_info.

  1. 01

    Disco

    Kernel é localizado

    O segundo estágio busca o novo programa nos setores seguintes.

    INT 13h/AH=42h lê os LBAs 6–61 em 1000:0000.

  2. 02

    Preparação

    Máquina chega a 64 bits

    O carregador monta o ambiente antes de chamar o núcleo.

    A20, GDT, paginação e long mode permanecem responsabilidades do bootloader.

  3. 03

    Contrato

    boot_info é preenchido

    Uma ficha informa memória, tela, serial e endereço do kernel.

    A versão 4 descreve VBE, framebuffer, pitch, profundidade, fonte e conserva o mapa E820.

  4. 04

    Kernel

    Núcleo assume o controle

    Depois de conferir a ficha, ele limpa a tela e usa seus próprios recursos.

    A entrada em 0x10000 valida RAX/RDI e não retorna ao bootloader.

Disco, RAM e CPU

Três lugares, responsabilidades diferentes.

soia.img contém carregador, kernel e SOIAFS1. Código é carregado na RAM; o volume continua no disco até o kernel pedir seus setores.

01
Persistente

Arquivo no disco

O arquivo soia.img reúne quatro blocos persistentes que precisam existir antes de a máquina ligar.

O kernel abre o conteúdo que ficou depois dele no disco.

02
Temporário

Estruturas na RAM

O carregador copia o kernel e cria estruturas temporárias em endereços distintos do computador virtual:

0x1000PML4
0x2000PDPT
0x3000Diretório
0x5000Mapa E820
0x6000Fonte BIOS 8 × 16
0x7000VBE ModeInfo
0x8000Estágio 2
0x10000Kernel
0x20000IDT
0x30000Bitmap · 64 KiB
0x100000000Tarefas
0x90000Pilha
VBEFramebuffer MMIO

Bootloader e kernel coexistem na RAM, mas têm funções separadas.

03
Resultado

Estado da CPU

A CPU continua em 64 bits; o salto para 0x10000 entrega a execução a outro binário.

16 bitsmodo real
32 bitsmodo protegido
64 bitskernel em execução
Em uma frase

O disco guarda código e arquivos. A RAM recebe o código no boot e os setores do volume quando o kernel os lê. A CPU troca o dono da execução no salto para 0x10000.

01Bits, bytes e endereçosFundamentos →

02Entrega ao kernelBoot →

03Bytes reais da imagemBinários →

Laboratório hexadecimal

Dois dígitos que escondem oito bits.

Arquivos .bin não são texto: cada posição contém um número de 0 a 255. Aqui você pode abrir os bytes reais do SOIA sem precisar saber binário previamente.

A unidade

Como FA vira oito bits?

hexF1111
hexA1010
1 byteFA11111010

Um dígito hexadecimal representa quatro bits. Por isso dois dígitos, de 00 a FF, representam um byte.

Seu primeiro comando

Como ler Format-Hex.

00000000 FA 31 C0 8E D8 8E C0 8E .1......

1Offsetposição dentro do arquivo

2Bytesvalores em hexadecimal

3Textotentativa de ler como caracteres

Um ponto significa “este byte não forma um caractere imprimível”. Isso não é erro: provavelmente é instrução ou dado.

Seu segundo comando

Como ler ndisasm.

00007C00 FA cli

1Endereçoonde a CPU vê a instrução

2Byteo número armazenado

3Assemblytradução para humanos

Nesse contexto, FA significa cli: desligar interrupções enquanto a pilha é preparada.

Bytes reais do build

Clique em qualquer byte para investigá-lo.

arquivo selecionado stage1.bin
funçãoSetor inicial
tamanho512 bytes
modo16 bits
bytes 0x000–0x0FF
16 bytes por linha
código ou dado texto ASCII preenchimento longo assinatura 55 AA

Marcos 14 + 19 · Rede básica e útil

Do dispositivo ao aplicativo, sem entregar o hardware.

O kernel encontra a placa, negocia DHCP, resolve um nome e completa TCP; NET.ELF vê resultados, nunca portas ou buffers DMA.

Analogia

A RTL8139 continua sendo a caixa de correio.

Ethernet é o envelope; DHCP entrega a configuração; DNS acha um endereço; TCP confirma que os dois lados podem conversar.

Negociação real

DISCOVER, OFFER, REQUEST e ACK.

O endereço não é mais constante: DHCP entrega 10.0.2.15/24, gateway .2 e DNS .3.

UDP 68 → 67. O cliente transmite DISCOVER e REQUEST em broadcast.

Opções 1, 3 e 6. Máscara, gateway e DNS vêm do ACK aceito.

Validação. XID, magic cookie, portas, tipo DHCP e checksum IPv4 precisam coincidir.

Nome seguro e reproduzível

gateway.soia vira 10.0.2.2.

A syscall 23 copia até 63 bytes para o kernel. O registro local usa o gateway recebido; o cliente por UDP continua disponível para consultas A externas.

Determinístico. O teste não depende de internet nem do resolver do host.

Formato real. O caminho por fio monta QNAME, valida a resposta e percorre nomes comprimidos.

Limite honesto. A prova automática não afirma resolução externa quando o sandbox bloqueia a resposta.

Handshake mínimo

SYN → SYN-ACK → ACK.

guestfwd liga 10.0.2.100:8080 a um listener temporário em localhost. A syscall 24 repete a prova para NET.ELF.

Ainda não existem sockets genéricos, payload TCP, retransmissão, FIN, HTTP, TLS ou IPv6.

No fio virtual

Protocolos no fio ou o teste falha.

qemu-network.pcap
ARP    6 quadros
IPv4  14 quadros
DHCP   4 mensagens
TCP    2 handshakes

Na userland

run NET.ELF.

DHCP + UDP  OK
gateway.soia  OK
TCP :8080  OK
memória devolvida  OK
Estudar PCI, RTL8139, ARP e IPv4 Estudar DHCP, UDP, DNS e TCP

Marco 16 · processos dinâmicos

Um ELF deixa de ser só arquivo e ganha vida.

O kernel prepara um espaço isolado para o programa e limpa tudo quando ele sai. As syscalls 15–18 implementam spawn, exit, wait e leitura validada da tabela de processos.

Experimento útil

run CALC.ELF

A calculadora aceita inteiros, + - * /, trata divisão por zero e encerra com sair.

Ciclo do pai. spawn + wait cria o filho e bloqueia o terminal sem polling.

Tabela de oito. Três vagas residentes e cinco vagas dinâmicas.

Estados reais. Livre, pronto, dormindo, aguardando e finalizado.

Sem vazamento. O teste exige a mesma contagem de páginas antes e depois.

soia> ps
PID  ESTADO       PROGRAMA
1    executando   TERMINAL.ELF
2    dormindo     NOTEPAD.ELF
3    dormindo     MONITOR.ELF

soia> run calc.elf
Processo iniciado; PID 4.
calc> -7 + 2
resultado: -5

exit primeiro marca o filho como zombie, pois sua pilha de kernel ainda está em uso. Depois da troca de contexto, o pai recolhe CR3, sete páginas de tabelas, oito de userland e uma pilha de kernel. O mesmo loader valida CALC.ELF e continua rejeitando deliberadamente BROKEN.ELF.

Estudar o Marco 16 completo

Marco 17 · heap + libc mínima

Memória que cresce quando o programa precisa.

O aplicativo ganha uma bancada privada, reaproveita espaços livres e devolve tudo ao fechar. A syscall 19 mapeia até 16 páginas RW+NX no PT de usuário; first-fit administra blocos alinhados em 16 bytes.

Experimento verificado

run HEAP.ELF

Três alocações atravessam duas páginas, um bloco liberado volta no mesmo endereço e a coleta encerra sem vazamento.

Base fixa. O heap começa vazio em 0x100008000.

Limite honesto. São no máximo 16 páginas, ou 64 KiB por processo.

W^X preservado. Dados dinâmicos são graváveis e nunca executáveis.

Camada essencial

Free guarda para o próximo pedido.

Pequenos blocos vizinhos são unidos. As páginas continuam no processo para evitar trabalho repetido e voltam ao kernel no exit.

Camada técnica

Break lógico + páginas físicas.

base   0x100008000
break  base + 6.288 B
mapa   2 × 4 KiB
limite 0x100018000
soia> run heap.elf
primeiro bloco: 0x0000000100008020
buffer dinamico via WRITE: buffer do heap aceito pela syscall WRITE
bloco liberado reutilizado no mesmo endereco: OK
calloc zerou 128 bytes: OK
paginas fisicas mapeadas sob demanda: 2
Memoria devolvida: OK.

Se uma alocação física falhar, BRK desfaz somente as PTEs criadas naquela chamada. INVLPG invalida o TLB e a validação das outras syscalls usa o break atual como limite.

Estudar o Marco 17 completo

Marco 18 · IPC + serviços

Mensagens atravessam o isolamento com o kernel no meio.

Cada processo tem uma caixa postal privada. O kernel confere o destinatário, copia a mensagem e acorda quem estava esperando. Cada tarefa possui uma fila circular de duas mensagens de até 48 bytes; handles codificam geração e PID para rejeitar identidades obsoletas.

Experimento verificado

run IPC.ELF

O terminal envia ping, bloqueia sem consumir CPU e volta a executar quando o filho responde pong.

Identidade temporal. O handle combina geração e PID; reutilizar a vaga não ressuscita uma referência antiga.

Cópia controlada. O remetente não recebe acesso ao CR3 nem aos ponteiros do destinatário.

Espera eficiente. RECEIVE vazio muda a tarefa para RECEIVING; o timer executa outra tarefa.

Camada essencial

Handle é uma senha com validade.

O PID diz qual vaga procurar; a geração confirma que ainda é a mesma vida do processo. Ao recolher o filho, o kernel troca a geração.

Camada técnica

Contrato pequeno e limitado.

handle = geração << 8 | PID
fila   = 2 mensagens
dados  = até 48 bytes
struct = 64 bytes
soia> run ipc.elf
Processo iniciado; PID 4; handle 772.
ping enviado ao filho: OK
RECEIVE bloqueou sem consumir CPU: OK
pong recebido do filho: OK
conteudo da resposta: OK
handle do remetente: OK
handle antigo rejeitado: OK
Memoria devolvida: OK.

As syscalls 20, 21 e 22 abrem um handle, enviam e recebem. Ao entregar diretamente para um receptor bloqueado, o kernel desabilita interrupções, troca temporariamente para o CR3 do receptor, valida e copia o resultado, grava o retorno salvo em RAX e restaura o CR3 do remetente. Ainda não existem nomes de serviço, permissões por handle nem mensagens maiores.

Estudar o Marco 18 completo

Roteiro

Uma camada de cada vez.

A IA ajuda a construir este projeto, mas não executa dentro dele. O roteiro agora segue os subsistemas clássicos de um SO completo.

  1. 01
    Setor de bootcontrole recebido
    concluído
  2. 02
    Segundo estágiomais de 512 bytes
    concluído
  3. 03
    Modo protegidoA20 + GDT + 32 bits
    concluído
  4. 04
    Long mode64 bits
    concluído
  5. 05
    Kernel mínimotela + serial
    concluído
  6. 06
    Interrupçõestimer + teclado
    concluído
  7. 07
    MemóriaE820 + páginas de 4 KiB
    concluído
  8. 08
    Processosring 3 + preempção + syscall
    concluído
  9. 09
    ArquivosATA + SOIAFS1 + VFS
    concluído
  10. 10
    Espaço de usuário terminal + shell em ring 3 ◆ marco importante
    concluído
  11. 11
    Interface gráfica desenho + janelas ◆ marco importante
    concluído
  12. 12
    Plataforma de desenvolvimento C freestanding + ELF + WHPX opcional ◆ marco importante
    concluído
  13. 13
    Terminal + bloco de notas primeiros aplicativos em C ◆ marco importante
    concluído
  14. 13.1
    Monitor do sistema CPU virtual + RAM + ATA
    concluído
  15. 14
    Rede básicaNIC + Ethernet + ARP + IPv4◆ marco importante
    concluído
  16. 15
    Persistênciadisco fixo + escrita + blocos livres
    concluído
  17. 16
    Processos dinâmicosspawn + exit + wait + CALC.ELF◆ marco importante
    concluído
  18. 17
    Heap + libc mínimabrk + malloc + free + HEAP.ELF◆ marco importante
    concluído
  19. 18
    IPC + serviçosmensagens + handles + IPC.ELF◆ marco importante
    concluído
  20. 19
    Rede útilDHCP + UDP + DNS + TCP + NET.ELF◆ marco importante
    concluído
  21. 21
    Robustezfalhas isoladas + testes hostis
  22. 22
    Plataforma modernaUEFI + ACPI + APIC
  23. 23
    Distribuição do SOIALauncher.exe + mídia bootável
    meta de entrega

Concluído · Marco 19

Um aplicativo isolado usa a rede por contratos do kernel.

DHCP configura o guest; DNS resolve um nome; TCP confirma o handshake; NET.ELF enxerga apenas syscalls e métricas.

Configuração real. DISCOVER/OFFER/REQUEST/ACK aparecem no PCAP.

Isolamento. PCI, RTL8139 e DMA continuam exclusivos do ring 0.

Prova obrigatória. O QEMU confirma DNS local e dois handshakes TCP.

Estudar o Marco 13 completo Estudar o Marco 13.1 completo Estudar o Marco 14 completo Estudar o Marco 15 completo Estudar o Marco 16 completo Estudar o Marco 17 completo Estudar o Marco 18 completo Estudar o Marco 19 completo

Ferramenta de desenvolvimento

A IA ajuda a construir; não executa no SOIA.

Ela apoia arquitetura, código, revisão, testes e documentação. A imagem final funciona sem modelo, conta, API ou conexão de IA.

Vocabulário

Termos sem mistério.

Abra um conceito quando precisar. O glossário completo permanece na documentação técnica.

Ver glossário em Markdown
01 Kernel

Simples: a autoridade que permanece administrando o computador.

Técnico: código em ring 0 que controla memória, hardware e serviços.

02 Ring 3

Simples: a área limitada em que programas comuns executam.

Técnico: CPL 3, sem acesso a páginas supervisoras ou instruções privilegiadas.

03 Syscall

Simples: um pedido controlado que um programa faz ao kernel.

Técnico: travessia validada por INT 0x80, com número e argumentos em registradores.

04 Terminal

Simples: a área que mostra texto e permite editar uma linha.

Técnico: driver de console em janela gráfica, com cursor, rolagem e entrada enfileirada.

05 Shell

Simples: o programa que entende o comando digitado.

Técnico: tarefa em ring 3 que analisa comandos e usa syscalls para pedir serviços.

06 VFS

Simples: uma porta comum para abrir arquivos sem conhecer o disco por baixo.

Técnico: interface que traduz operações genéricas para o formato SOIAFS1.