Les développeurs Linux testent la nouvelle atténuation de sécurité “DOITM” pour les derniers processeurs Intel

L’été dernier, Intel a publié des conseils sur le mode d’instruction Data Operand Independent Timing (DOIT) qui peut être activé sur les dernières générations de processeurs Intel afin d’assurer une synchronisation d’exécution cohérente pour un sous-ensemble du jeu d’instructions Intel, ce qui peut être particulièrement important pour les algorithmes cryptographiques. Les discussions des développeurs du noyau Linux ont eu du mal au cours de l’année écoulée avec la gestion de cette fonctionnalité DOIT pour ce qui est décrit comme une vulnérabilité du processeur dans les processeurs Intel récents. Cependant, maintenant, un correctif du noyau Linux d’un développeur Google activera ce changement sans condition pour les nouveaux processeurs Intel, mais soulève des problèmes de performances.

L’année dernière, Intel ainsi qu’Arm ont révélé qu’il n’est pas garanti que les instructions sur les processeurs récents et futurs soient “cohérentes dans le temps” en ce qui concerne leurs opérandes de données, à moins qu’une spécification spéciale spécifique au modèle ne soit définie. Cela a suscité des inquiétudes, en particulier autour du code de cryptographie pour Linux, du fait qu’il n’y a plus de garantie de temps constant et que le temps d’exécution d’une instruction peut varier en fonction des données sur lesquelles il est opéré. Une application continue de la synchronisation est nécessaire pour empêcher d’éventuelles attaques par canal latéral. Mais avec le nouveau drapeau d’Intel activé pour assurer la disponibilité, il a admis des implications sur les performances.

Eric Biggers, ingénieur de Google et développeur de longue date du noyau Linux, a envoyé un correctif cette semaine pour activer le contrôle du mode de synchronisation indépendant des données Intel pour le noyau Linux, ce qui activera cet indicateur par défaut pour les nouveaux processeurs Intel. Il est activé par défaut mais il fournit également un bouton pour désactiver cette fonction d’atténuation/sécurité. Greater décrit le problème et la motivation dans ce message de patch :

Selon la documentation publiée par Intel récemment, les processeurs Intel basés sur Ice Lake et les microarchitectures ultérieures ne garantissent pas par défaut une “synchronisation indépendante des opérandes de données”. C’est-à-dire que les temps d’exécution des instructions peuvent dépendre des valeurs de données utilisées. Cela est vrai pour une grande variété d’instructions, y compris de nombreuses instructions qui sont souvent utilisées en cryptographie et supposent toujours un temps constant, par ex. des ajouts, des XOR et même des instructions AES-NI.

Les algorithmes cryptographiques nécessitent des instructions persistantes pour empêcher les attaques par canal latéral qui récupèrent les clés cryptographiques en fonction des temps d’exécution. Par conséquent, sans cette vulnérabilité du processeur atténuée, il est fondamentalement impossible d’effectuer une cryptographie en toute sécurité sur les derniers processeurs Intel.

Il est également possible que cette vulnérabilité du processeur expose plus généralement les données privilégiées du noyau à des processus malveillants de l’espace utilisateur.

Pour atténuer cette vulnérabilité du processeur, il est possible d’activer le “Data Operand Independent Timing Mode” (DOITM) en définissant un bit dans un MSR. Alors que la documentation d’Intel suggère que ce bit ne doit être défini que lorsque “nécessaire”, cela est très peu pratique, étant donné que la cryptographie peut se produire presque n’importe où dans le noyau et l’espace utilisateur, et le fait que l’ensemble du noyau devra probablement être protégé de toute façon .

Par conséquent, activons simplement DOITM globalement par défaut pour corriger cette vulnérabilité. Il fournit principalement une “optimisation” sur les derniers processeurs, restaurant le comportement correct des processeurs précédents.

La documentation du noyau proposée pour la vulnérabilité DODT (Data Operand Dependent Timing) résume la situation comme suit :

DODT – Synchronisation dépendante de l’opérande de données
======================================

Data Operand Dependent Timing (DODT) est une vulnérabilité du processeur qui rend les temps d’exécution des instructions dépendants des valeurs de données sur lesquelles s’effectue l’opération.

Cette vulnérabilité permet potentiellement des attaques par canal latéral sur les données, y compris les clés cryptographiques. La plupart des algorithmes de cryptographie exigent que différentes instructions soient constantes dans le temps pour empêcher les attaques par canal latéral.

Processeurs concernés
————–

Cette vulnérabilité affecte les processeurs de la famille Intel Core basés sur Ice Lake et les microarchitectures ultérieures, et les processeurs de la famille Intel Atom basés sur Gracemont et les microarchitectures ultérieures.

Assouplissement
———-

L’atténuation de cette vulnérabilité implique la définition d’un bit de registre spécifique au modèle (MSR) pour activer le mode de synchronisation indépendant des opérandes de données (DOITM).

Par défaut, le noyau le fait sur tous les processeurs. Cette atténuation est globale, elle s’applique donc au noyau et à l’espace utilisateur.

Cette atténuation peut être désactivée en ajoutant “doitm=off“ à la ligne de commande du noyau. C’est également l’une des atténuations qui peuvent être désactivées avec “mitigations=off“.

Le guide publié par Intel sur la synchronisation indépendante des opérandes de données expose les risques de performances clairs de ce mode de fonctionnement :

DOIT nécessite la désactivation des optimisations matérielles et/ou des fonctionnalités de performances sur certains processeurs ; par exemple, l’activation de la synchronisation indépendante des opérandes de données peut désactiver la prélecture dépendante des données. Cela signifie que le mode DOIT peut avoir un impact sur les performances, et Intel s’attend à ce que l’impact sur les performances de ce mode soit plus important dans les futurs processeurs.

Les conseils d’Intel consistent généralement à utiliser ce mode DOIT avec parcimonie et pour une utilisation logicielle qui a déjà appliqué d’autres techniques recommandées par Intel pour réduire les canaux latéraux de synchronisation logicielle. Le noyau Linux avec sa base de code massive développée au fil des ans n’est pas nécessairement conforme à toutes les techniques logicielles recommandées par Intel. Il est un peu inquiétant que ce mode DOIT soit “supérieur” pour les futurs processeurs.

Notamment sur ce correctif de liste de diffusion du noyau Linux, il n’y a pas de chiffres de performance ni d’indications sur la gravité de la pénalité de performance, apparemment en raison d’un manque de matériel et de la recherche de tests de la part de la communauté du noyau.

Suite à ce patch d’Eric Biggers, une discussion a eu lieu dans le noyau pour savoir s’il était nécessaire de protéger l’intégralité du noyau, s’il était possible de protéger uniquement les opérations de cryptographie dans le noyau, et si vous n’optiez pas pour cette couverture, comment l’utilisateur- l’espace est également correctement protégé. Il n’y a pas de consensus à ce stade, mais en raison du manque de chiffres solides… J’ai lancé quelques premiers tests sur les systèmes Intel de la génération actuelle.