Alors que la prise en charge d’Intel Shadow Stack existe depuis les processeurs Tiger Lake dans le cadre de la technologie CET (Control-flow Enforcement Technology) d’Intel, enfin, pour le noyau Linux 6.4, cette fonctionnalité de sécurité est activée avec le noyau Linux principal.
Les ingénieurs d’Intel Linux travaillent depuis longtemps sur la prise en charge de la pile fantôme dans le cadre de CET. L’autre partie de CET, Indirect Branch Tracking, a été intégrée en amont dans Linux 5.18.
La fonctionnalité de pile fantôme d’Intel pour Linux 6.4 est la protection des adresses de retour pour se défendre contre les attaques de programmation orientée retour (ROP). Les derniers processeurs AMD fournissent également une fonctionnalité Shadow Stack compatible avec l’implémentation d’Intel.
L’ingénieur de longue date d’Intel Linux, Dave Hansen, a soumis la demande d’extraction x86/shstk lundi pour avoir enfin introduit cette fonctionnalité. Il a expliqué dans ce message :
Veuillez tirer x86/shstk pour 6.4. Il s’agit du support tant attendu de Shadow Stack. Il s’agit de la fonctionnalité de sécurité matérielle la plus recherchée depuis longtemps. AMD et Intel ont des implémentations (compatibles). Il est présent du côté d’Intel depuis les processeurs de 11e génération, mais il a eu quelques trébuchements en cours de route et est un peu en retard.
La partie la plus délicate de tout cela (IMNHO) était que les piles fantômes existent dans une zone grise d’autorisation. Un PTE de pile fantôme indique littéralement Write=0, mais certaines instructions _peuvent_ y écrire. Les PTE ne peuvent pas non plus être en lecture seule, ils ne peuvent donc pas être COW’d. Ce sont des excentriques.
Les autorisations Write=0,Dirty=1 PTE signifient également que le bit sale ne peut pas être utilisé aussi librement qu’auparavant. Ces deux choses se combinent pour créer une bonne quantité de désabonnement de gestion PTE.
Quelques choses supplémentaires que vous devez savoir :
1. Il y a une quantité non triviale de baratte de mm de noyau. Il a des accusés de réception de mm et j’espère que ce n’est pas une surprise pour Andrew. Ceux-ci ajoutent un argument VMA à pte_mkwrite(). Il y a un nouvel utilisateur dans la pile d’Andrew qui devra être réparé avant que cela ne soit fusionné avec l’arbre mm.
2. Il y a eu un grondement inhabituel de problèmes de compatibilité de l’espace utilisateur avec les piles fantômes. Bien que le passage aux nouvelles valeurs arch_prctl() ait aidé, nous pouvons toujours envisager des scénarios où cet ancien code pourrait nous mordre. Le plan est d’essayer d’interdire à toutes les applications problématiques d’utiliser la pile fantôme si quelque chose se produit dans la pratique. Nous devrions évidemment être à l’affût de ceux-ci.
3. Cela entre en conflit avec le code LAM qui arrive en x86/mm. Je discuterai de la résolution lorsque j’enverrai x86/mm.
Au moment d’écrire ces lignes, Linus Torvalds n’a pas encore intégré le support Shadow Stack ni fait de commentaires sur la liste de diffusion. Nous verrons si tout va bien pour que Linus intègre cette fonctionnalité pour Linux 6.4 ou s’il a des réserves compte tenu des commentaires ci-dessus. Espérons que cette fonctionnalité de sécurité Intel/AMD pour aider à repousser les attaques ROP sera enfin fusionnée.
