Pular para o conteúdo

AMD SEV

Referência de arquiteturaFeex

O AMD Secure Encrypted Virtualization, SEV, criptografa a memória da máquina virtual sob um modelo de ameaça de plataforma definido. SEV, SEV-ES e SEV-SNP fornecem recursos diferentes e não devem ser tratados como equivalentes.

O que você precisa saber

O AMD Secure Encrypted Virtualization, SEV, criptografa a memória da máquina virtual sob um modelo de ameaça de plataforma definido. SEV, SEV-ES e SEV-SNP fornecem recursos diferentes e não devem ser tratados como equivalentes.

Como funciona

O SEV associa a criptografia de memória do convidado ao gerenciamento de chaves específico da VM. O SEV-ES adiciona proteção para o estado do registrador do convidado durante as saídas, enquanto o SEV-SNP adiciona mecanismos mais fortes em torno da integridade e propriedade da memória do convidado. Firmware, hipervisor, suporte do convidado e atestação participam da implantação completa de VM confidencial.

Onde é útil

Uma implantação em nuvem pode solicitar um tipo de VM confidencial explicitamente suportado e validar suas evidências de atestação antes de liberar segredos. O aplicativo ainda precisa de E/S segura, pares autenticados e uma política para as medições de plataforma que aceita.

Como verificar o suporte e a ativação

Verifique as informações de CPUID de criptografia de memória da AMD e a variante exata de SEV e, em seguida, valide firmware, suporte de host/convidado e atestação por meio da interface documentada do provedor. Consulte as orientações de segurança atuais da AMD para a geração e firmware implantados.

Capacidade, habilitação e aplicação devem ser verificadas separadamente. Um processador pode suportar uma proteção enquanto o SO, aplicativo ou política de máquina virtual não a ativa. Um campo de suporte do banco de dados não é uma atestação de um sistema em execução.

O que o recurso não estabelece

Um campo genérico de SEV não comprova SEV-SNP, status atual de mitigação de firmware ou um serviço de atestação específico. A criptografia por si só não é o mesmo que proteção de integridade, e a criptografia de memória não protege todos os dispositivos ou caminhos de rede.

Compatibilidade e desempenho na prática

Mantenha o SO, o firmware e o runtime afetado atualizados. Se uma proteção expuser um problema de compatibilidade, use primeiro os diagnósticos do fornecedor e as atualizações suportadas. Uma alternância ampla de proteção pode afetar aplicativos não relacionados e deve seguir uma política explícita de implantação e recuperação.

Uma lista de verificação prática de verificação

  1. Registre o modelo exato do processador ou da plataforma e as versões envolvidas do aplicativo, SO e runtime. Mantenha o texto exato do erro ou requisito.
  2. Consulte a referência do fabricante para esse modelo exato e, em seguida, inspecione a capacidade efetiva e o estado ativado no ambiente em que o programa é executado.
  3. Compare cada requisito do binário ou backend selecionado. Um recurso com nome semelhante, alias ou rótulo genérico de tecnologia não é suficiente.
  4. Confirme se o aplicativo selecionou a implementação pretendida. Use seus diagnósticos documentados e um fallback suportado quando os requisitos não forem atendidos.
  5. Faça uma alteração suportada por vez e repita a mesma carga de trabalho. Mantenha a configuração original e o caminho de recuperação disponíveis.

Se o recurso estiver listado, mas o software não puder usá-lo

Comece pelo componente exato com falha. Um banco de dados de hardware descreve a capacidade registrada; o sistema operacional ou o hipervisor pode expor um ambiente efetivo diferente. Um erro de instrução ilegal também precisa de investigação da instrução falha real e da compilação do binário, porque corrupção ou uma instrução não suportada não relacionada pode produzir um sintoma semelhante.

Instale a versão do aplicativo, driver ou runtime suportada para a plataforma exata e use a compilação de linha de base ou fallback documentada do fornecedor, se necessário. Uma atualização de software não pode criar uma instrução que o processador não possui. As alterações de firmware e de política de segurança devem seguir o procedimento do fabricante do sistema e um plano de recuperação em vez de uma receita genérica de otimização.

Fontes e escopo desta explicação

Recursos para desenvolvedores do AMD Secure Encrypted Virtualization · AMD64 Architecture Programmer's Manual, Volume 2: System Programming

Essas referências estabelecem o comportamento arquitetural e os requisitos de software. Elas não verificam de forma independente cada valor de recurso em uma página de modelo de hardware vinculada. Para obter suporte a modelos, use a evidência do fabricante dessa página e verifique a configuração efetiva do sistema. Este artigo não fornece um benchmark, certificação ou data de análise independente.

Fontes e verificação

Propriedade editorial: Feex. Nenhuma data de revisão independente foi registrada. Como pesquisamos.

Este artigo foi útil?

Um sim ou não é suficiente. Escolha um motivo se desejar, ou adicione uma breve observação.

Este artigo foi útil?