LRM Prof. Mantovani ← Aulas da disciplina
Semana 13 · Aula 13 de 14

Virtualização, firmware e segurança

Virtualização e contêineres, o processo de boot e firmware, a segurança de plataforma e um laboratório embarcado de cadeia de boot segura.

📚 Sistemas Operacionais📝 mini-quiz ao final
Objetivos da aula

O que você vai aprender

1

Diferenciar máquinas virtuais de contêineres e hipervisores tipo 1 e 2.

2

Descrever a sequência de boot e o papel do firmware (UEFI, bootloader).

3

Reconhecer mecanismos de segurança de plataforma (boot seguro, raiz de confiança).

4

Aplicar o princípio do menor privilégio e o isolamento por hardware.

1 · Motivação

Um computador, muitos sistemas — com segurança

Um servidor moderno roda dezenas de aplicações isoladas na mesma máquina; um celular executa apps que não confiam uns nos outros; um carro tem dezenas de computadores que precisam arrancar de forma confiável e segura. Como isolar tudo isso? E como garantir que, ao ligar, o software que sobe é o legítimo, não um malware?

Esta aula fecha o curso ligando três temas: virtualização (isolar sistemas inteiros), o boot (do firmware ao SO) e a segurança de plataforma (a cadeia de confiança que protege a partida).

2 · Mapa

O que veremos nesta aula

VMs ×
contêineres
Boot e
firmware
Boot seguro
(cadeia)
Isolamento e
menor privilégio

Da virtualização ao primeiro byte executado ao ligar, até os mecanismos que garantem que esse byte é confiável.

3 · Conceito

Máquinas virtuais e contêineres

Máquina virtual (VM). Um hipervisor virtualiza o hardware; cada VM roda seu próprio SO completo, isolada das demais.
Contêiner. Isolamento no nível do SO: vários contêineres compartilham o kernel do hospedeiro, isolando processos por namespaces e cgroups.
AspectoVMContêiner
IsolaHardware (via hipervisor)Processos (mesmo kernel)
PesoSO completo por VMLeve (compartilha kernel)
InícioSegundosMilissegundos
IsolamentoForte (fronteira de hardware)Mais fraco (mesmo kernel)
4 · Explicação

Como a virtualização usa o hardware

Virtualizar com segurança exige apoio do hardware. Quando uma VM executa uma instrução privilegiada (acessar um dispositivo, alterar a tabela de páginas), ela não pode mexer no hardware real diretamente. O hardware de virtualização (Intel VT-x, AMD-V) faz a CPU "sair" para o hipervisor (VM exit), que emula a operação e devolve o controle.

Para a memória, há tabelas de páginas aninhadas (EPT/NPT): a MMU traduz duas vezes — endereço da VM → endereço "físico" da VM → endereço físico real —, isolando a memória de cada VM. É a MMU da Aula 8 elevada a outro nível. Contêineres, por não virtualizarem hardware, dispensam isso, mas por isso isolam menos.

5 · Exemplo

Tipos de hipervisor

TipoOnde rodaExemplosUso típico
Tipo 1 (bare-metal)Direto no hardwareESXi, Xen, Hyper-VServidores, nuvem
Tipo 2 (hospedado)Sobre um SO hospedeiroVirtualBox, VMware WorkstationDesktop, testes
💡
Tipo 1 tem menos overhead (fala direto com o hardware) e domina a nuvem. Tipo 2 é mais prático para uso pessoal, ao custo de uma camada extra (o SO hospedeiro) entre a VM e o metal.
6 · Interativo

Passo a passo: a sequência de boot de um PC

Passo 1
Power-on: a CPU começa a executar em um endereço fixo, lendo o firmware (UEFI/BIOS) gravado na placa.
Passo 2
O firmware inicializa hardware essencial (RAM, controladoras) e procura um dispositivo de boot.
Passo 3
Carrega o bootloader (ex.: GRUB), que localiza e carrega o kernel do SO na memória.
Passo 4
O kernel inicializa drivers, monta o sistema de arquivos raiz e cria o primeiro processo.
Passo 5
O init/systemd sobe os serviços; a tela de login aparece. O sistema está pronto.
7 · Conceito

Firmware e bootloader

Firmware. Software de baixo nível gravado no hardware (UEFI no PC, gerenciador de boot em microcontrolador) que inicializa a plataforma logo após a energização.
Bootloader. Programa que o firmware carrega para localizar e dar partida no kernel do SO (ex.: GRUB, U-Boot).
Power-onFirmware
UEFI/BIOS
BootloaderKernelInit / tarefas
8 · Explicação

Boot em embarcados: direto da flash

Em embarcados, o boot costuma ser bem mais curto. Muitos microcontroladores não têm bootloader complexo nem SO completo: ao sair do reset, a CPU começa a executar o firmware da aplicação gravado diretamente na flash interna (execute-in-place). Não há disco para carregar um kernel.

Quando há um RTOS como o FreeRTOS, ele é linkado junto com a aplicação num único binário: o "boot" é apenas inicializar a stack, zerar a memória e chamar main(), que cria as tarefas e inicia o escalonador. Dispositivos maiores (roteadores, smart TVs) usam bootloaders como o U-Boot, que podem inclusive carregar a imagem pela rede.

9 · Analogia

A cadeia de confiança como lacres

🔐 Analogia
O boot seguro é como uma corrente de lacres de segurança. A fábrica (raiz de confiança em hardware) lacra a primeira caixa. Cada caixa, antes de abrir a seguinte, confere que o lacre dela está intacto e é autêntico. Se alguém adulterou qualquer caixa no caminho, o lacre não bate e a abertura para. Assim, do hardware ao SO, ninguém injeta software falso sem quebrar a corrente.
10 · Comparação

Mecanismos de segurança de plataforma

MecanismoO que fazApoio de hardware
Boot seguroVerifica assinatura de cada estágioChaves na raiz de hardware
Raiz de confiançaGuarda chaves e mede o bootTPM / enclave seguro
IsolamentoSepara processos e SOModos de CPU, MMU/MPU
Menor privilégioMínimo de permissões por componenteAnéis, capacidades
11 · Fluxo

A cadeia de boot seguro

Raiz de confiança
(hardware)
Verifica e roda
firmware
Verifica e roda
bootloader
Verifica e roda
kernel
🔑
Boot seguro (Secure Boot). Cada estágio verifica a assinatura criptográfica do próximo antes de executá-lo. A confiança parte de uma raiz imutável em hardware e se estende, elo a elo, até o SO. Quebrar um elo interrompe o boot.
12 · Aprofundamento

TPM, atestação e secure enclaves

TPM (Trusted Platform Module). Chip dedicado que guarda chaves criptográficas e registra medidas (hashes) de cada estágio do boot em registradores especiais (PCRs).
Atestação remota. A plataforma prova a um servidor, com assinaturas do TPM, que arrancou software íntegro e esperado.

Além do TPM, processadores oferecem enclaves seguros (Intel SGX, ARM TrustZone): áreas isoladas onde código e dados sensíveis (chaves, biometria) rodam protegidos até do próprio SO. Em embarcados, a TrustZone divide o chip em "mundo seguro" e "mundo normal", base para pagamentos e DRM em celulares.

13 · Interativo

Verifique seu entendimento

O que diferencia fundamentalmente um contêiner de uma máquina virtual?

A VM virtualiza o hardware e roda um SO completo por instância (isolamento forte, mais peso). O contêiner isola no nível do SO, compartilhando o kernel do hospedeiro — mais leve e rápido, porém com isolamento mais fraco.
14 · Caso prático

Segurança em IoT: o elo mais fraco

Dispositivos de IoT são alvos frequentes justamente por falharem nos fundamentos desta aula. Botnets como a Mirai tomaram milhões de câmeras e roteadores explorando senhas padrão nunca alteradas e firmware sem atualização.

As defesas são as mesmas que estudamos: boot seguro para impedir firmware adulterado; atualização assinada (OTA) para corrigir falhas; menor privilégio para que serviços não rodem como root; e isolamento por hardware (TrustZone) para chaves. Em IoT, a segurança de plataforma não é luxo — é o que separa um produto de uma porta de entrada para ataques.

15 · Erros comuns

Confusões frequentes

⚠️
Erros comuns nesta aula:
• Achar que contêiner é "uma VM leve" — não há SO próprio nem virtualização de hardware; o kernel é compartilhado.
• Inverter a ordem do boot — é firmware → bootloader → kernel → init.
• Confundir boot seguro (verifica assinatura) com boot rápido (só desempenho).
• Pensar que o menor privilégio é opcional — é princípio central de segurança.
16 · Dicas

Como pensar segurança de plataforma

Pergunte-se sempre: "onde está a raiz de confiança e até onde a cadeia se estende?". A segurança começa no hardware (TPM, chave fundida no chip) e sobe elo a elo. Aplique menor privilégio em cada camada, mantenha o firmware atualizável e assinado, e isole o que for sensível em enclave. Lembre que cada mecanismo desta aula se apoia em hardware já visto: modos de CPU, MMU/MPU e criptografia dedicada.
17 · Interativo

Revele a resposta

Por que o isolamento de um contêiner é considerado mais fraco que o de uma VM?
Porque todos os contêineres de um hospedeiro compartilham o mesmo kernel. Uma vulnerabilidade no kernel (uma falha que permita escapar do namespace ou escalar privilégio) pode comprometer todos os contêineres e o próprio hospedeiro de uma vez. Já uma VM tem seu próprio kernel e é separada por uma fronteira de hardware imposta pelo hipervisor; escapar dela exige furar o hipervisor, uma barreira bem mais estreita e auditada. Por isso, cargas que exigem isolamento forte (multi-inquilino sem confiança mútua) costumam preferir VMs ou microVMs.
18 · Flashcards

Revisão relâmpago

Hipervisor tipo 1virar
Roda direto no hardware (bare-metal): ESXi, Xen. Menos overhead; domina a nuvem.
Contêinervirar
Isolamento no nível do SO; compartilha o kernel via namespaces e cgroups. Leve, isolamento mais fraco.
Boot segurovirar
Cada estágio verifica a assinatura do próximo, formando uma cadeia de confiança desde o hardware.
TPMvirar
Chip que guarda chaves e mede o boot (PCRs); base para atestação remota.
Menor privilégiovirar
Cada componente recebe só as permissões estritamente necessárias.
19 · Conexões

Para onde isso leva

Esta aula reúne quase todo o curso sob a ótica do isolamento:

  • O isolamento usa modos de CPU (Aula 1) e MMU/MPU (Aula 8).
  • A virtualização de memória estende a paginação (Aula 8) com tabelas aninhadas.
  • O boot em embarcados liga-se ao RTOS (Aula 12) linkado à aplicação.
  • Tudo prepara a apresentação do projeto e a revisão (Aula 14).
20 · Síntese

Resumo da aula

🔑
VMs virtualizam o hardware e rodam um SO completo por instância (isolamento forte); contêineres compartilham o kernel do hospedeiro (leves, isolamento mais fraco). O boot vai do firmware ao bootloader, ao kernel e ao init; em embarcados, frequentemente direto da flash. O boot seguro forma uma cadeia de confiança da raiz de hardware (TPM/enclave) ao SO. Isolamento, raiz de confiança e menor privilégio — apoiados em hardware — sustentam a segurança de plataforma, vital em IoT.
Mão na massa · colaborativo

Atividade em grupo · Laboratório embarcado: cadeia de boot segura

Em grupos, mapeiem a cadeia de confiança de um dispositivo embarcado.

⏱️ 40 min👥 grupos de 3–4🧩 laboratório

Roteiro

  1. Escolham um alvo: roteador, smart camera ou microcontrolador com bootloader.
  2. Desenhem a sequência de boot, do reset ao firmware da aplicação.
  3. Identifiquem onde uma assinatura deveria ser verificada (boot seguro).
  4. Apontem 3 vulnerabilidades plausíveis e como mitigá-las.
Arquiteto de bootdesenha a sequência
Analista de segurançacaça vulnerabilidades
Mitigadorpropõe defesas
📤 Entrega: Diagrama da cadeia de boot + 3 vulnerabilidades com mitigações.
Teste seu conhecimento

Mini-quiz · Aula 13

20 questões sobre esta aula. Escolha e veja a explicação na hora.

0/20

📌 Resumo — leve isto para a prova

  • VMs virtualizam hardware (isolamento forte); contêineres compartilham o kernel (leves).
  • Hipervisores tipo 1 rodam bare-metal; tipo 2, sobre um SO hospedeiro.
  • O boot vai do firmware ao bootloader, ao kernel e ao init; embarcados bootam da flash.
  • O boot seguro forma uma cadeia de confiança da raiz de hardware (TPM) ao SO.
  • Isolamento, raiz de confiança e menor privilégio sustentam a segurança de plataforma.