1. [Wiki](https://feex.it/wiki/) 2. [Hardware](https://feex.it/wiki/hardware/) 3. [Sistemas e arquitetura](https://feex.it/wiki/hardware/system/) 4. Control-flow Enforcement (CET) # Control-flow Enforcement (CET) Referência de arquitetura: Feex Também chamado de CET CET, Control-flow Enforcement Technology, adiciona mecanismos de hardware para proteger o fluxo de controle, principalmente pilhas de sombra (shadow stacks) e rastreamento de desvios indiretos. Suporte por hardware e proteção ativa em um processo específico são estados diferentes. ## O que você precisa saber CET, Control-flow Enforcement Technology, adiciona mecanismos de hardware para proteger o fluxo de controle, principalmente pilhas de sombra (shadow stacks) e rastreamento de desvios indiretos. Suporte por hardware e proteção ativa em um processo específico são estados diferentes. ## Como funciona Pilhas de sombra mantêm o estado protegido de endereços de retorno, enquanto o rastreamento de desvios indiretos restringe os destinos de desvios indiretos rastreados. Eles tratam de diferentes transferências de fluxo de controle e possuem enumeração e habilitação separadas. O SO, o carregador, o binário do aplicativo e as bibliotecas participam para fazer um ambiente de execução protegido funcionar. ## Onde é útil Um aplicativo construído de maneira adequada pode ser executado com uma pilha de sombra gerenciada pelo SO para que um endereço de retorno incompatível acione a exceção definida em vez de redirecionar a execução silenciosamente. A política de compatibilidade pode diferir para módulos legados e proteção em modo de usuário versus modo supervisor. ## Como verificar o suporte e a ativação Verifique o bit 7 de CPUID.07H.00H:ECX para capacidade de pilha de sombra e o bit 20 de EDX para rastreamento de desvios indiretos, e então inspecione o status de proteção de processo documentado pelo SO. Um bit de CPU disponível por si só não consegue estabelecer a imposição para um programa em execuçã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 Um campo de CET não prova que ambos os sub-recursos estejam presentes ou habilitados. O CET não torna um binário confiável, não previne todos os erros de corrupção de memória nem substitui atualizações. Desativar uma proteção globalmente não é uma correção rotineira para o travamento de um aplicativo. ## 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 [CET-IBT](https://feex.it/wiki/l/pt/hardware/system/cet-ibt/) · [Pilhas de sombra CET](https://feex.it/wiki/l/pt/hardware/system/cet-ss/) · [Execute Disable (NX)](https://feex.it/wiki/l/pt/hardware/system/execute-disable/) · [OS Guard e SMEP](https://feex.it/wiki/l/pt/hardware/system/os-guard/) ## Fontes e escopo desta explicação [Intel 64 and IA-32 Architectures Software Developer's Manual](https://www.intel.com/content/www/us/en/developer/articles/technical/intel-sdm.html) · [Kernel do Linux: pilha de sombra de Control-flow Enforcement Technology](https://docs.kernel.org/arch/x86/shstk.html) 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. [CET-IBT: Referência de arquitetura](https://feex.it/wiki/l/pt/hardware/system/cet-ibt/)[Pilhas de sombra CET: Referência de arquitetura](https://feex.it/wiki/l/pt/hardware/system/cet-ss/)[Execute Disable (NX): Referência de arquitetura](https://feex.it/wiki/l/pt/hardware/system/execute-disable/)[OS Guard e SMEP: Referência de arquitetura](https://feex.it/wiki/l/pt/hardware/system/os-guard/) ## Fontes e verificação Propriedade editorial: Feex. Nenhuma data de revisão independente foi registrada. [Como pesquisamos](https://feex.it/wiki/research/). - [Intel 64 and IA-32 Architectures Software Developer's Manual ](https://www.intel.com/content/www/us/en/developer/articles/technical/intel-sdm.html)· 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 ](https://docs.kernel.org/arch/x86/shstk.html)· 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. ## Este artigo foi útil? Um sim ou não é suficiente. Escolha um motivo se desejar, ou adicione uma breve observação. Fatos rápidos A identificação resumida desta página. Especificações, fontes e o conteúdo completo permanecem no artigo. --- Source: [Canonical Feex Wiki page](https://feex.it/wiki/l/pt/hardware/system/cet/) [Developer guide](https://feex.it/wiki/developers/) | [API policy](https://feex.it/developers/api-policy/) | [Agent guidance](https://feex.it/wiki/llms.txt)