Pilhas de sombra CET

O que você precisa saber

Como funciona

Uma pilha de sombra mantém uma cópia protegida das informações de retorno junto com a pilha de execução comum. Um retorno protegido verifica a consistência de acordo com as regras da arquitetura. O SO gerencia a ativação, as permissões de memória e o estado das threads, enquanto os ambientes de execução devem tratar corretamente as exceções e as transições de contexto.

Onde é útil

Uma sobrescrita de pilha que altere um endereço de retorno normal pode produzir uma exceção de proteção de controle quando discordar do estado de retorno protegido. Um depurador ou runtime deve compreender o ambiente de pilha de sombra em vez de tratá-lo como uma pilha gravável comum.

Como verificar o suporte e a ativação

CPUID.07H.00H:ECX bit 7 enumera a capacidade de pilha de sombra. Use a interface de status documentada do SO por processo ou por thread para estabelecer a ativação. Um travamento inexplicável justifica verificar as atualizações de software suportadas e a compatibilidade antes de alterar a política de proteção.

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

As pilhas de sombra não estabelecem suporte a IBT, não protegem todos os dados do aplicativo nem eliminam todos os ataques de fluxo de controle. Um rótulo de CPU não prova que todo executável e biblioteca carregada estejam cobertos sob a política de compatibilidade do SO.

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.

Recursos relacionados e distinções úteis

Control-flow Enforcement (CET) · CET-IBT · Execute Disable (NX)

Fontes e escopo desta explicação

Intel 64 and IA-32 Architectures Software Developer's Manual · Kernel do Linux: pilha de sombra de Control-flow Enforcement Technology

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.

Relacionados

Estas entidades conectam-se a este artigo. O tipo é indicado em cada link.

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.
• Kernel do Linux: pilha de sombra de Control-flow Enforcement Technology · Distingue suporte de hardware, marcadores de binário, habilitação de carregador e proteção ativa por thread. Descreve IBT e pilhas de sombra como recursos separados.