Control-flow Enforcement (CET)

El que cal saber

Com funciona

Les piles ombra mantenen l'estat protegit de l'adreça de retorn, mentre que el seguiment de branques indirectes restringeix les destinacions de les branques indirectes rastrejades. Aborden transferències de flux de control diferents i tenen una enumeració i una habilitació separades. El SO, el carregador, el binari de l'aplicació i les biblioteques participen per fer funcionar un entorn d'execució protegit.

On és útil

Una aplicació compilada adequadament es pot executar amb una pila ombra gestionada pel SO de manera que una adreça de retorn discordant desencadeni l'excepció definida en lloc de redirigir silenciosament l'execució. La política de compatibilitat pot ser diferent per a mòduls heretats i per a la protecció en mode d'usuari respecte al mode de supervisor.

Com comprovar el suport i l'habilitació

Comproveu el bit 7 de CPUID.07H.00H:ECX per a la capacitat de pila ombra i el bit 20 d'EDX per al seguiment de branques indirectes; a continuació, inspeccioneu l'estat de protecció de processos documentat del SO. Un bit de CPU disponible per si sol no pot establir l'aplicació per a un programa en execució.

La capacitat, l'habilitació i l'aplicació s'han de comprovar per separat. Un processador pot admetre una protecció mentre que la política del SO, de l'aplicació o de la màquina virtual no l'activa. Un camp de suport en una base de dades no és una atestació d'un sistema en execució.

El que la característica no estableix

Un camp CET no demostra que ambdues subcaracterístiques estiguin presents o habilitades. CET no fa que un binari sigui de confiança, no evita tots els errors de corrupció de memòria ni substitueix les actualitzacions. Desactivar una protecció globalment no és una solució habitual per a una fallada d'aplicació.

Compatibilitat i rendiment a la pràctica

Manteniu actualitzats el SO, el microprogramari i l'entorn d'execució afectat. Si una protecció exposa un problema de compatibilitat, utilitzeu primer els diagnòstics del fabricant i les actualitzacions admeses. Una activació àmplia de protecció pot afectar aplicacions no relacionades i hauria de seguir una política explícita de desplegament i recuperació.

Una llista de verificació pràctica

1. Enregistreu el model exacte de processador o de plataforma i les versions d'aplicació, SO i entorn d'execució implicades. Conserveu la redacció de l'error o del requisit real.
2. Comproveu la referència del fabricant per a aquest model exacte, i després inspeccioneu la capacitat efectiva i l'estat habilitat en l'entorn on s'executa el programa.
3. Compareu cada requisit del binari o dorsal seleccionat. Una característica amb un nom similar, un àlies o una etiqueta de tecnologia àmplia no és suficient.
4. Confirmeu que l'aplicació ha seleccionat la implementació prevista. Utilitzeu els seus diagnòstics documentats i una alternativa compatible quan no es compleixin els requisits.
5. Feu un únic canvi admès a la vegada i repetiu la mateixa càrrega de treball. Manteniu disponibles la configuració original i la via de recuperació.

Si la característica apareix a la llista però el programari no la pot utilitzar

Comenceu pel component exacte que falla. Una base de dades de maquinari descriu la capacitat registrada; el sistema operatiu o l'hipervisor poden exposar un entorn efectiu diferent. Un error d'instrucció il·legal també requereix investigar la instrucció defectuosa real i la compilació del binari, perquè una corrupció o una instrucció no admesa no relacionada poden produir un símptoma similar.

Instal·leu la versió d'aplicació, controlador o entorn d'execució admesa per a la plataforma exacta, i utilitzeu la compilació base o alternativa documentada pel fabricant si cal. Una actualització de programari no pot crear una instrucció que li manqui al processador. Els canvis de microprogramari i de polítiques de seguretat han de seguir el procediment del fabricant del sistema i un pla de recuperació en lloc d'una recepta genèrica d'optimització.

Característiques relacionades i distincions útils

CET-IBT · CET shadow stacks · Execute Disable (NX) · OS Guard i SMEP

Fonts i abast d'aquesta explicació

Intel 64 and IA-32 Architectures Software Developer's Manual · Nucli de Linux: pila ombra de Control-flow Enforcement Technology

Aquestes referències estableixen el comportament arquitectònic i els requisits de programari. No verifiquen de manera independent cada valor de característica en una pàgina de model de maquinari enllaçada. Per al suport de models, utilitzeu l'evidència del fabricant d'aquesta pàgina i comproveu la configuració efectiva del sistema. Aquest article no proporciona cap data de prova de referència, certificació o revisió independent.

Relacionat

Aquestes entitats enllacen amb aquest article. El tipus es mostra a cada enllaç.

Fonts i verificació

Propietat editorial: Feex. No s'ha registrat cap data de revisió independent. Com investiguem.

• Intel 64 and IA-32 Architectures Software Developer's Manual · Els volums 1 i 2 descriuen les famílies d'instruccions anomenades i CPUID; el volum 3 descriu l'estat, la paginació, VMX i els controls de protecció. La documentació d'arquitectura no estableix el suport per a un model en particular.
• Nucli de Linux: pila ombra de Control-flow Enforcement Technology · Distingeix la compatibilitat de maquinari, els marcadors binaris, l'habilitació del carregador i la protecció activa per fil. Descriu IBT i les piles ombra com a funcions separades.