A superfície de ataque do PCIe: isolando dispositivos com IOMMU e ACS

Nós construímos impérios de dados sobre a premissa de velocidade. Queremos IOPS, queremos latência zero, queremos que nossos arrays NVMe movam terabytes como se fossem kilobytes. Para conseguir isso, a indústria de hardware fez um pacto faustiano: concedemos aos dispositivos de armazenamento acesso irrestrito à memória do sistema.

O barramento PCIe não é apenas um tubo de dados; é uma extensão do cérebro do seu servidor. Quando você conecta um SSD NVMe Enterprise ou uma HBA SAS, você não está apenas plugando um disco. Você está conectando um computador independente, com seu próprio firmware e processador, diretamente na via expressa da sua RAM. Se esse dispositivo for malicioso, comprometido ou simplesmente mal projetado, ele pode ler suas chaves de criptografia antes mesmo que o sistema operacional termine de carregar.

Resumo em 30 segundos

DMA é um risco: O Acesso Direto à Memória permite que discos NVMe leiam/escrevam na RAM sem supervisão da CPU, expondo chaves de criptografia.

IOMMU é obrigatório: Tecnologias como Intel VT-d e AMD-Vi criam um "firewall" de memória, restringindo o que cada dispositivo pode acessar.

ACS fecha a porta dos fundos: Sem o Access Control Services, dispositivos PCIe podem se comunicar entre si (Peer-to-Peer) contornando o IOMMU completamente.

O privilégio excessivo do barramento PCIe

A arquitetura de computadores moderna depende do DMA (Direct Memory Access). Sem ele, a CPU teria que gerenciar cada bit transferido do SSD para a RAM, o que mataria a performance de qualquer servidor de armazenamento moderno. O DMA permite que o controlador do SSD diga: "Eu vou colocar esses dados no endereço de memória X, me avise quando eu terminar".

O problema é a confiança implícita. Por padrão, em muitas arquiteturas legadas ou mal configuradas, um dispositivo PCIe tem uma visão plana e total da memória física.

Isso significa que um controlador de armazenamento comprometido (seja por um ataque à cadeia de suprimentos ou um firmware bugado explorável) pode varrer a RAM em busca de chaves mestre do BitLocker, LUKS ou chaves de sessão TLS. Isso não é ficção científica; ferramentas como o PCILeech demonstram isso há anos. Se o atacante tem acesso físico para plugar um dispositivo, ou se o dispositivo já residente é reprogramado remotamente, o jogo acabou.

Figura: Diagrama ilustrando um ataque DMA onde um controlador NVMe acessa diretamente áreas protegidas da memória RAM, contornando a supervisão da CPU.

A anatomia de um ataque DMA em storage

Imagine um cenário em um datacenter. Você tem um servidor de arquivos rodando ZFS com encriptação nativa. As chaves estão na memória para permitir a operação de leitura/escrita.

Um atacante não precisa de senha de root. Se ele conseguir explorar uma vulnerabilidade no firmware da controladora HBA ou do próprio backplane NVMe, ele pode instruir o hardware a copiar os blocos de memória onde as chaves residem para uma área de armazenamento persistente ou exfiltrá-los pela rede (se houver colusão com a NIC).

⚠️ Perigo: O ataque DMA acontece "por baixo" do sistema operacional. O kernel do Linux ou o Windows Server muitas vezes nem registram que o acesso ocorreu, pois, do ponto de vista do hardware, foi uma transação legítima de barramento.

IOMMU: O firewall de hardware

A resposta da indústria para esse caos é a IOMMU (Input-Output Memory Management Unit). No mundo Intel, chamamos de VT-d (Virtualization Technology for Directed I/O); na AMD, é o AMD-Vi.

A IOMMU faz para os dispositivos o que a MMU faz para os processos de software: virtualização de endereços. Com a IOMMU ativa e configurada (o que é crucial), o dispositivo PCIe não vê mais a memória física real. Ele vê um espaço de endereçamento virtual mapeado pelo sistema operacional.

Se o seu SSD NVMe tentar acessar um endereço de memória fora do intervalo que lhe foi explicitamente concedido (o buffer de dados), a IOMMU intercepta a transação e a bloqueia, gerando um erro de hardware. É a segmentação aplicada ao silício.

No entanto, ativar "VT-d" na BIOS é apenas o primeiro passo. O sistema operacional precisa criar domínios de proteção. Em hypervisors como ESXi ou Proxmox (KVM), isso é vital para garantir que uma VM com passthrough de disco não consiga derrubar o host ou ler a memória de outra VM vizinha.

O buraco negro do tráfego Peer-to-Peer e o ACS

Aqui é onde a maioria das implementações de segurança de storage falha. Engenheiros habilitam o IOMMU e acham que estão seguros. Eles esquecem do tráfego Peer-to-Peer (P2P).

A especificação PCIe permite que dispositivos conversem diretamente entre si para otimizar latência. Uma placa de vídeo pode enviar dados diretamente para um SSD NVMe (GPUDirect Storage, por exemplo) sem passar pela memória principal ou pela CPU. Embora excelente para performance, isso é um pesadelo de segurança se não for controlado.

Se dois dispositivos estão conectados ao mesmo switch PCIe (ou na mesma raiz complexa que suporta P2P) e o ACS (Access Control Services) não estiver habilitado ou suportado, o tráfego entre eles não passa pela IOMMU.

💡 Dica Pro: O ACS força todas as transações PCIe a subirem até o Root Complex (o controlador principal na CPU) para serem verificadas pela IOMMU antes de descerem para o dispositivo de destino. Isso introduz uma latência minúscula, mas garante que o isolamento seja real.

Sem ACS, um dispositivo de rede comprometido poderia atacar seu array de armazenamento diretamente, ignorando completamente suas regras de firewall de memória.

Figura: Comparação de fluxo de dados PCIe: Sem ACS (esquerda), permitindo comunicação direta e não verificada entre dispositivos; Com ACS (direita), forçando a verificação de segurança pelo IOMMU.

Grupos IOMMU e a realidade da segmentação

Quando você audita um servidor Linux para verificar o isolamento, você se depara com o conceito de "IOMMU Groups". O kernel agrupa dispositivos que não podem ser isolados uns dos outros devido às limitações físicas do hardware ou falta de suporte ACS nos switches PCIe da placa-mãe.

Se o seu controlador NVMe e sua placa de rede de gerenciamento estiverem no mesmo grupo IOMMU, eles compartilham o mesmo contexto de segurança. Se um cai, o isolamento do outro é comprometido.

Para verificar seus grupos em um sistema Linux, o comando abaixo é seu melhor amigo na fase de validação de hardware:

#!/bin/bash
shopt -s nullglob
for g in /sys/kernel/iommu_groups/*; do
    echo "IOMMU Group ${g##*/}:"
    for d in $g/devices/*; do
        echo -e "\t$(lspci -nns ${d##*/})"
    done
done

Se você encontrar dispositivos críticos misturados com dispositivos periféricos não confiáveis no mesmo grupo, sua placa-mãe ou a topologia do seu slot PCIe está sabotando sua segurança.

Tabela Comparativa: Níveis de Isolamento PCIe

Para visualizar o impacto dessas tecnologias na segurança dos seus dados em repouso e em trânsito interno:

Cenário	Proteção contra Leitura de RAM	Proteção contra Ataque P2P	Impacto na Performance	Nível de Segurança
Padrão (Sem IOMMU)	Nenhuma. Dispositivo vê tudo.	Nenhuma.	Máximo (Nativo)	🛑 Crítico
IOMMU Ativo (Sem ACS)	Alta (Protege contra acesso à RAM do Host).	Baixa (Dispositivos vizinhos podem se atacar).	Desprezível	⚠️ Médio
IOMMU + ACS Ativo	Total (Isolamento granular).	Total (Tráfego forçado via Root Complex).	Mínimo (Latência marginal).	✅ Alto

Firmware e a cadeia de suprimentos

Nenhum isolamento de software corrige um hardware que mente. A superfície de ataque do PCIe também inclui o firmware que roda nos seus discos. Drives modernos possuem milhões de linhas de código.

Fabricantes de storage enterprise (Dell, HPE, NetApp) frequentemente assinam digitalmente seus firmwares para impedir a instalação de versões adulteradas. No entanto, no mercado de "white box" ou hardware entusiasta, essa verificação é rara.

Se você opera dados sensíveis, a política de "Zero Trust" deve se estender ao barramento. Assuma que o dispositivo é hostil. O IOMMU com ACS é a única maneira de operar hardware não confiável (que é todo hardware que você não fabricou pessoalmente) de maneira segura.

O futuro é compartimentalizado

A segurança defensiva não é sobre esperar que o ataque não aconteça; é sobre garantir que, quando acontecer, o dano seja contido. O armazenamento de dados evoluiu. Nossos discos são computadores. Nossos barramentos são redes.

Não aceite configurações padrão de BIOS que priorizam compatibilidade legada sobre segurança. Habilite VT-d/AMD-Vi. Verifique o suporte a ACS nos seus switches PCIe e processadores. Se o seu fornecedor de hardware não consegue explicar como os grupos IOMMU são separados na placa-mãe deles, troque de fornecedor.

A integridade dos seus dados depende de barreiras físicas e lógicas. Não deixe a porta da frente da sua memória RAM aberta só porque é mais conveniente.

Referências & Leitura Complementar

Intel Virtualization Technology for Directed I/O (VT-d) Architecture Specification: Documentação oficial sobre o funcionamento da remapeamento de DMA.
PCI Express Base Specification (PCI-SIG): Detalhes técnicos sobre Access Control Services (ACS) e transações Peer-to-Peer.
Thunderclap Vulnerabilities: Pesquisa detalhada sobre vulnerabilidades de DMA em sistemas operacionais modernos (thunderclap.io).
Linux Kernel IOMMU Support: Documentação do kernel sobre a implementação de grupos IOMMU e drivers VFIO.

O que é um ataque DMA via PCIe?

É quando um dispositivo malicioso ou comprometido conectado ao barramento PCIe acessa diretamente a memória do sistema (RAM) sem supervisão do processador, podendo ler chaves de criptografia ou injetar malware.

Por que o IOMMU é essencial para segurança de storage?

O IOMMU atua como um firewall interno, mapeando e restringindo os endereços de memória que cada dispositivo PCIe (como um SSD NVMe) pode acessar, impedindo que um disco comprometa o sistema operacional.

O que acontece se o ACS não estiver habilitado?

Sem o ACS (Access Control Services), dispositivos PCIe podem se comunicar diretamente entre si (Peer-to-Peer) contornando o IOMMU, permitindo que um dispositivo ataque outro sem que a CPU perceba.