Les ingénieurs de Red Hat s’efforcent de faire face au fait que la spéculation indirecte restreinte aux branches (IBRS) est trop coûteuse pour atténuer Spectre V2 et Retbleed sur les anciens processeurs Intel Xeon Scalable. Un nouveau correctif a été lancé pour désactiver IBRS lorsqu’il est inactif et fonctionne bien au moins pour Red Hat Enterprise Linux 9, bien qu’il ne soit pas encore clair s’il sera accepté dans le noyau en amont.
Le patch de Waiman Long de Red Hat explique les difficultés auxquelles ils sont toujours confrontés autour d’Intel IBRS pour gérer Spectre et Retbleed :
Pour les processeurs Intel qui doivent activer IBRS pour se protéger contre Spectre v2 et Retbleed, le bit IBRS dans le SPEC_CTRL MSR affecte les performances de l’ensemble du noyau même si un seul thread l’active lors de son exécution dans le noyau. Pour les applications gourmandes en espace utilisateur, l’impact sur les performances de l’activation occasionnelle d’IBRS pendant les appels système ne devrait pas être significatif. Malheureusement, ce n’est pas le cas lorsque le thread frère est inactif dans le noyau. Dans ce cas, l’impact sur les performances peut être significatif.
Lorsque DPDK s’exécute sur un thread CPU isolé traitant des paquets réseau dans l’espace utilisateur alors que son thread frère est inactif. Les performances du thread DPDK occupé avec IBRS activé et désactivé dans le thread inactif frère sont :
IBRS activé IBRS désactivé
—————
paquets/seconde : 7,8 M 10,4 M
cycles tsc moy/paquet : 282,26 209,86
Il s’agit d’une dégradation des performances de 25 %. Le système de test est un processeur Intel Xeon 4114 à 2,20 GHz.
Cette série de correctifs désactive IBRS lorsqu’il est dans divers modes d’inactivité pour éliminer l’impact sur les performances du thread inactif sur son thread frère occupé.
Ouch, un succès de 25 % sur Xeon Scalable Skylake pour le Data Plane Development Kit (DPDK) open source.
Il y a ce thread du noyau où le patch pour désactiver IBRS en cas d’inactivité est flottant. L’éminent ingénieur Intel Linux, Peter Zijlstra, a cependant suggéré un autre correctif qui n’est actuellement pas rétroporté sur RHEL9. De plus, la possibilité d’utiliser Call Depth Stuff/Tracking au lieu d’IBRS. Dans mes tests, le suivi de la profondeur des appels trouvé dans la version principale de Linux 6.2+ propose en effet d’aider à récupérer certaines performances perdues sur les processeurs de l’ère Intel Skylake qui reposent autrement sur IBRS. Nous verrons donc où va l’activité du noyau en amont ou si Red Hat finit par simplement transporter ce correctif dans le cadre de son noyau RHEL9 pour le moment jusqu’à ce que de nouvelles options soient rétroportées. En tout état de cause, ce dernier fil de liste de diffusion du noyau continue de montrer les difficultés d’atténuation que rencontrent encore les utilisateurs Linux d’entreprise à la mi-2023 sur les plates-formes plus anciennes.
