Capítulo 8 — Arquitetura de computadores
Mapa da aula
Aula 08 publicada. Mapa, exemplo, EX022.
flowchart TD
N0["8.1 Processadores e aceleradores"]
N1["8.2 Formatos numéricos"]
N2["8.3 Superfícies de ataque arquiteturais"]
N3["8.4 Execução confiável e atestação"]
N4["Síntese"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Exemplo resolvido"]
EX --> Q["Exercício EX022"]
Desenho lógico
flowchart LR
N0["8.1 Processadores e aceleradores"]
N1["8.2 Formatos numéricos"]
N2["8.3 Superfícies de ataque arquiteturais"]
N3["8.4 Execução confiável e atestação"]
N4["Síntese"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX022"]
[8.1 Processadores e aceleradores]
|
v
[8.2 Formatos numéricos]
|
v
[8.3 Superfícies de ataque arquiteturais]
|
v
[8.4 Execução confiável e atestação]
|
v
[Síntese]
|
v
[Exemplo resolvido] --> [Exercício EX022]
Objetivos de aprendizagem
Você vai (1) descrever CPUs, hierarquias de memória, GPUs e aceleradores usados em aprendizado de máquina; (2) explicar os formatos numéricos e seu efeito sobre o comportamento do modelo; (3) identificar superfícies de ataque arquiteturais (isolamento de memória, canais laterais, firmware); e (4) raciocinar sobre execução confiável para cargas de trabalho de IA.
8.1 Processadores e aceleradores
CPUs executam instruções gerais com caches profundos. GPUs e aceleradores de IA executam milhares de operações simples em paralelo, o ideal para multiplicação de matrizes. Os modelos transitam entre a memória do host e a memória do dispositivo; na nuvem, os dados na memória do dispositivo podem ser compartilhados entre processos ou clientes, então o isolamento importa. As cópias são a preocupação de segurança: pesos carregados numa GPU, entradas mantidas num buffer compartilhado e resultados aguardando retorno existem por um instante em lugares que outro cliente ou um driver descuidado poderia ler. Provedores de nuvem isolam os clientes, mas engenheiros ainda perguntam se a memória do dispositivo é limpa entre tarefas e quem pode vê-la, e registram as respostas no modelo de ameaças da implantação.
8.2 Formatos numéricos
O treinamento costuma usar ponto flutuante de 32 ou 16 bits; a inferência pode usar inteiros de 8 bits (quantização). Uma precisão menor muda levemente as saídas e pode mudar decisões perto das fronteiras. Avaliações de segurança devem usar a precisão implantada: um ataque ou uma defesa medidos em 32 bits podem se comportar de outro modo em 8 bits, e vice-versa. A quantização leva cada valor ao mais próximo de um pequeno conjunto de níveis, então entradas próximas do limiar de decisão podem passar para o outro lado. Gradientes calculados numa cópia de 32 bits podem não corresponder ao comportamento do modelo de 8 bits, o que pode fazer os ataques parecerem mais fortes ou mais fracos do que são em serviço.
8.3 Superfícies de ataque arquiteturais
Bugs de segurança de memória no código que serve o modelo podem expor pesos ou entradas. Caches compartilhados e o tempo de execução podem vazar informação entre processos (canais laterais). Falhas de hardware — inclusive as induzidas deliberadamente, como inversões de bits ao estilo rowhammer — podem corromper pesos; pesquisas mostraram que um pequeno número de bits invertidos nos parâmetros de uma rede pode degradá-la ou redirecioná-la fortemente. Firmware e drivers fazem parte da base de computação confiável. Para um engenheiro, cada item sugere um controle: linguagens com segurança de memória ou revisão cuidadosa do código de serviço, isolamento entre clientes, memória com correção de erros e verificações de integridade dos pesos carregados. Calcular o hash do arquivo de pesos antes de carregá-lo detecta mudanças em disco, mas não bits invertidos na memória depois disso, então implantações críticas também comparam, em intervalos, as saídas sobre um conjunto fixo de verificação.
8.4 Execução confiável e atestação
Ambientes de execução confiável (TEEs) e GPUs de computação confidencial buscam proteger código e dados em uso contra o operador do host, e a atestação remota permite a um cliente verificar que código está sendo executado. Eles reduzem alguns riscos (um operador de nuvem curioso), mas não outros (um servidor de modelo vulnerável dentro do enclave, injeção de prompt). A atestação responde a uma pergunta estreita: este é o código esperado, em hardware genuíno? Ela nada diz sobre se esse código é seguro. Engenheiros tratam, portanto, um TEE como uma camada que protege contra um operador curioso e mantêm validação de entradas, limites de privilégio e monitoramento para ataques que chegam pela interface normal do modelo.
8.5 Exemplo resolvido (caso sintético da NRS)
O TrackEye roda num computador de borda no trem de inspeção, com um modelo quantizado de 8 bits. Sam descobriu que os testes de robustez tinham sido feitos no laboratório com o modelo de 32 bits; repeti-los na build implantada de 8 bits mudou os falsos negativos de madrugada de 9.0% para 9.6%. Sam acrescentou "avaliar no artefato e no hardware implantados" como requisito e anotou que a porta de manutenção do computador de borda dá acesso físico ao firmware — um item do modelo de ameaças. Uma alta de 0.6 ponto percentual é pequena, mas mostra que o resultado do laboratório não descrevia o sistema que de fato roda no trem. O novo requisito faz com que todo número de robustez futuro informe o hash do artefato e o hardware em que foi medido.
8.6 Erros e limites
Três erros são comuns: avaliar uma precisão numérica diferente da implantada; supor que TEEs resolvem ataques no nível da aplicação; e ignorar o firmware e as portas físicas de manutenção. Esses erros têm uma causa comum: avaliar um sistema idealizado em vez do implantado. A precisão usada nos testes é fácil de conferir contra a build. As alegações sobre TEEs devem ser lidas pelo que excluem. Portas de manutenção costumam ficar habilitadas por conveniência; a lista de verificação de Sam pergunta, para cada porta, se ela é necessária em serviço, quem pode alcançá-la e se seu uso é registrado.
Exercícios
- EX022 — Precisão. Por que a robustez precisa ser testada no modelo quantizado implantado? Rubrica: 3 = a quantização muda as saídas perto das fronteiras; os resultados podem diferir; 2 = parcial; 1 = vago; 0 = errado.
- EX023 — Limites do TEE. Cite uma ameaça que um TEE mitiga e uma que ele não mitiga num serviço de LLM. Rubrica: 3 = operador do host lendo dados vs. injeção de prompt/bugs do servidor; 2 = uma; 1 = vago; 0 = errado.
- EX024 — Inversões de bits. Explique por que verificações de integridade dos pesos no carregamento não resolvem por completo os ataques por falhas. Rubrica: 3 = as falhas podem ocorrer na memória depois do carregamento; são precisos verificações em tempo de execução/ECC/redundância; 2 = parcial; 1 = vago; 0 = errado.
Síntese
A IA roda em hardware real, com precisão finita, recursos compartilhados e firmware. Engenheiros testam o artefato implantado na plataforma implantada e incluem ameaças no nível da arquitetura no modelo.
Continue estudando — capítulo 08 de 50
← Capítulo 07 (rascunho) · Índice de capítulos do curso · Capítulo 09 (rascunho) →