Execute Disable (NX)
Execute Disable, também chamado de NX ou XD na terminologia x86, permite que as tabelas de páginas marquem a memória como não executável. É um componente fundamental de hardware utilizado pelas políticas de proteção de execução do sistema operacional.
O que você precisa saber
Execute Disable, também chamado de NX ou XD na terminologia x86, permite que as tabelas de páginas marquem a memória como não executável. É um componente fundamental de hardware utilizado pelas políticas de proteção de execução do sistema operacional.
Como funciona
Quando ativado no ambiente de paginação aplicável, uma busca de instrução em uma página marcada como não executável gera uma falha em vez de executar seus bytes. As permissões de página diferenciam a execução do acesso a dados; o software é responsável por atribuir permissões adequadas e gerenciar transições para código gerado legítimo.
Onde é útil
Um SO pode mapear um buffer de dados sem permissão de execução para que a escrita de bytes de código de máquina nesse buffer não o transforme em uma página de código executável. Ambientes de execução JIT usam APIs documentadas de gerenciamento de memória e políticas de permissão para código gerado.
Como verificar o suporte e a ativação
O bit 20 de CPUID.80000001H:EDX enumera o recurso de execute-disable do x86 segundo a definição do fabricante correspondente. A aplicação efetiva também depende do modo de paginação e da habilitação no SO. Inspecione o status de proteção documentado do SO em vez de inferi-lo a partir do modelo da CPU.
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
O NX não comprova que um arquivo executável é seguro, não bloqueia todos os ataques de reutilização de código nem prova a qualificação para o Windows. Os dados continuam legíveis ou graváveis de acordo com permissões separadas. Um sinalizador de recurso não significa que todo mapeamento de memória siga uma política estrita de escrita/execução.
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
- 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.
- 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.
- 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.
- 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.
- 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.
- Intel 64 and IA-32 Architectures Software Developer's Manual · Os Volumes 1 e 2 descrevem as famílias de instruções nomeadas e CPUID; o Volume 3 descreve estado, paginação, VMX e controles de proteção. A documentação de arquitetura não estabelece o suporte para um modelo específico.
Este artigo foi útil?
Um sim ou não é suficiente. Escolha um motivo se desejar, ou adicione uma breve observação.
Obrigado. Isso nos ajuda a melhorar esta página.