Pular para o conteúdo

RDRAND

Referência de arquiteturaFeex

RDRAND retorna valores aleatórios a partir do recurso de geração de números aleatórios por hardware do processador quando um valor estiver disponível. O software deve verificar sua indicação de sucesso e seguir um projeto criptográfico sólido.

O que você precisa saber

RDRAND retorna valores aleatórios a partir do recurso de geração de números aleatórios por hardware do processador quando um valor estiver disponível. O software deve verificar sua indicação de sucesso e seguir um projeto criptográfico sólido.

Como funciona

A instrução grava um valor e indica sucesso com a flag de transporte (carry flag). Um resultado temporariamente indisponível exige que o chamador siga a política documentada de novas tentativas ou de falha. A instrução é uma interface para um gerador, não uma substituição para uma API completa de aleatoriedade do sistema operacional e sua política de gerenciamento de entropia.

Onde é útil

Um SO ou runtime criptográfico pode incorporar uma fonte de aleatoriedade de hardware sob seu projeto documentado. A maioria dos códigos de aplicação deve solicitar aleatoriedade de sua interface mantida de SO ou biblioteca, permitindo que esse componente trate a disponibilidade, a composição e questões específicas da plataforma.

Como verificar o suporte e a ativação

CPUID.01H:ECX bit 30 enumera RDRAND. Toda execução deve verificar a carry flag; um valor de registrador por si só não comprova sucesso. Siga as orientações atuais do fornecedor e a implementação suportada da biblioteca de segurança.

Use uma implementação criptográfica mantida que lide com a seleção de recursos, condições de falha e o algoritmo completo. A aceleração de hardware fornece primitivas; gerenciamento de chaves, autenticação, regras de nonce e escolhas de protocolo continuam sendo responsabilidades do software.

O que o recurso não estabelece

RDRAND e RDSEED têm interfaces pretendidas diferentes e enumeração separada. Um recurso reportado não prova que um aplicativo específico verifique falhas, nem estabelece a certificação de um produto ou garante que uma VM exponha a mesma implementação de aleatoriedade do host.

Compatibilidade e desempenho na prática

Um campo de recurso não é uma certificação de produto ou evidência de que um aplicativo específico é seguro. O desempenho depende dos tamanhos de mensagem, modo, agrupamento em lote e do restante do protocolo. Verifique o provedor real e mantenha suas atualizações de segurança em dia.

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

Intel 64 and IA-32 Architectures Software Developer's Manual

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?