Salut,

Je vois beaucoup de topics sur le bug des CPU Intel et aussi beaucoup de confusion (comme quoi ça ne concernerait que les serveurs etc.). Je me suis documenté hier et je vous propose ici un résumé avec une explication du contexte du bug, de ses implications, et du correctif ainsi que des pertes de perf qu'il peut entraîner.

En espérant que ça soit utile !

I. Contexte

Il touche tous les CPU Intel sortis depuis 10 ans et est 'défaut de conception, dans le matériel même, pas corrigible par une update du microcode ou du BIOS.

Il ne touche pas uniquement un genre d'usage (serveur etc.) mais permet à un programme d'accéder à une zone mémoire protégée réservée au noyau du système d'exploitation.

II. L'OS, les appels systèmes, l'exécution prédite

En résumé, voilà ce qui se passe. Un système d'exploitation c'est la couche logicielle basse qui interface les programmes avec le matériel. L'OS se charge d'allouer la mémoire, les voies de communication réseau, d'ordonnancer l'exécution des processus en parallèle, ouvrir/fermer les fichiers etc. Les programmes utilisateurs demandent ces ressources par des appels système.

À chaque fois qu'un programme fait un appel système, il doit rendre le contrôle du processeur au noyau du système. On appelle ça un changement de contexte. Pour rendre ça plus rapide, le noyau de l'OS est actuellement présent en partie dans tous les processus qui s'exécutent sur une machine, comme ça quand le processeur doit changer de contexte il gagne du temps (un processus a son propre espace mémoire, une partie est occupée par le noyau).

Maintenant le problème avec la conception des CPU Intel vient d'une technique d'optimisation qui consiste à laisser les processeurs prédire quel portion du code d'un programme est susceptible d'être exécutée après l'instruction courante, et de l'exécuter d'avance pour que le résultat soit déjà prêt.

III. La faille de sécurité et ses implications

Le bug découvert rend très probablement possible l'exécution d'instructions qui accèdent à l'espace mémoire réservé au noyau dans un programme par ce mécanisme de prédiction. Normalement il devrait y avoir des vérifications avant d'exécuter les instructions prédites pour s'assurer qu'elles sont safe, et s'il n'y a pas de vérification ce genre de comportement est possible.

Ce que ça veut dire concrètement c'est que si un attaquant arrive à écrire un programme qui fasse prédire au CPU des instructions qui lisent l'espace mémoire protégé, il pourrait profiter de l'exécution en avance sans vérification pour lire dans la mémoire du noyau, alors que c'est normalement interdit. Et dans l'espace mémoire protégé, il peut y avoir plein de trucs secrets, comme des mots de passe en clair (pensez aux trousseaux qui gardent en mémoire une clé déverrouillée), et des trucs du genre.

Ce qui est encore plus grave c'est que comme le problème vient du matériel lui-même, n'importe quel code qui s'exécute est susceptible d'être affecté, y compris du Javascript dans un navigateur web.

IV. Le correctif et son impact sur les performances

Le correctif qui est entrain d'être pushé sur Linux et bientôt Windows et Mac OS consiste à complètement séparer l'espace mémoire du noyau et celui des processus tournant en espace utilisateur.

Ce que ça implique niveau performances c'est qu'à chaque appel système, deux changements de contexte seront désormais nécessaires (user space vers noyau puis en sens inverse).

V. Jeux et applications professionnelles

Pour l'instant les bench qu'on a vu sur Phoronix etc. comparent les perfs sur des applications professionnelles qui font beaucoup d'appels système. C'est notamment le cas des systèmes de gestion de bases de données comme PostgreSQL.

Pour les jeux, on n'a pas encore beaucoup d'infos mais il semblerait que l'impact sera moindre.

----------

Voilà, la flemme de citer toutes les sources mais en gros ce sont celles qui tournent le plus souvent. Il y a pas mal de spéculations là dedans, par ce que le bug est tellement critique que les détails sont maintenus secrets jusqu'à ce que les correctifs soient déployés, mais ce que disent AMD et les chercheurs de TU Gratz qui ont écrit le patch Linux laisse penser qu'il s'agit du problème expliqué ici.

Ce que je ne comprend pas c'est pourquoi les hackers en question attendrait l'annonce de la fail pour agir ? En 10 ans ils ont vraiment rien fait ?

Un grand merci pour ton résumé en espérant que tes sources soient les bonnes.

Ce khey qui nous sors un paragraphe argumenté

Autre précision, s'ils déploient le patch sans tester si le proc est Intel ou AMD, alors le patch sera exécuté sur les deux plateformes et aura le même impact.

Il faudrait qu'ils gardent deux versions en parallèle, une AMD, une Intel, mais ça à mon avis faudrait pas trop rêver... On n'est pas non plus 100% sûr que les AMD sont exempts du bug, même si AMD dit que oui

Merci pour ce topic
C'est bien résumé

Juste une question (si tu as la source sous le coude ça sera génial)
Il me semblé que le patch KPTI visé à corriger quelque chose d'encore plus critique que la faille sur le mécanisme de prédiction.
Il me semble que la faille sur le mécanisme de prédiction est connu depuis quelque temps ?
J'ai peut-être tous mélangé avec les news pas claire

Le 03 janvier 2018 à 14:25:37 jc-angel a écrit :
Merci pour ce topic
C'est bien résumé

Juste une question (si tu as la source sous le coude ça sera génial)
Il me semblé que le patch KPTI visé à corriger quelque chose d'encore plus critique que la faille sur le mécanisme de prédiction.
Il me semble que la faille sur le mécanisme de prédiction est connu depuis quelque temps ?
J'ai peut-être tous mélangé avec les news pas claire

Je vais double check mais de ce que j'ai compris le KPTI c'est justement la séparation des pages mémoire kernel et user process, et la faille du mécanisme de prédiction qui check pas permet de laisser un processus accéder à la zone mémoire kernel qui se trouve actuellement dans celle du processus user space. Donc en séparant les deux, c'est plus possible.

Le 03 janvier 2018 à 14:17:40 Murcielago93 a écrit :
Ce que je ne comprend pas c'est pourquoi les hackers en question attendrait l'annonce de la fail pour agir ? En 10 ans ils ont vraiment rien fait ?

Tous simplement parce que la faille vient d'être découvert par les "gentils hackers" que maintenant.
On ne sait pas et on ne sera probablement jamais si cette faille à été utilisé par des "méchant hackers" pour faire des méchantes chose

Le 03 janvier 2018 à 14:26:33 kermitou3 a écrit :

Le 03 janvier 2018 à 14:23:26 GilbertSukhey a écrit :
Autre précision, s'ils déploient le patch sans tester si le proc est Intel ou AMD, alors le patch sera exécuté sur les deux plateformes et aura le même impact.

Il faudrait qu'ils gardent deux versions en parallèle, une AMD, une Intel, mais ça à mon avis faudrait pas trop rêver... On n'est pas non plus 100% sûr que les AMD sont exempts du bug, même si AMD dit que oui

Y'a pas d’exécution en avance chez AMD.
Puis ils sont pas cons, le patch concerne que les procs Intel.

Ben y a pas d'exécution en avance, c'est ce qu'AMD a dit, mais j'ai aussi vu des sources disant que pour le moment le doute est permis donc plutôt qu'affirmer quelque chose de faux, je préfère dire qu'on aura confirmation plus tard.

Pour ce qui est du patch, le soucis c'est que puisque ça modifie la façon même dont l'OS fonctionne avec ses processus, si la modif est pushée sur l'OS et que l'ancienne manière de faire est supprimée, alors les zones mémoires kernel et processus seront toujours séparées peu importe le proco. Donc deux changements de contexte même sur AMD.

Pour ne pas dégrader les perfs sur AMD, il faudrait que le patch rajoute la séparation en parallèle du code actuel et que le code path soit choisi à chaque fois en fonction du processeur, ce qui demande plus d'efforts.

Le 03 janvier 2018 à 14:23:26 GilbertSukhey a écrit :
Autre précision, s'ils déploient le patch sans tester si le proc est Intel ou AMD, alors le patch sera exécuté sur les deux plateformes et aura le même impact.

Il faudrait qu'ils gardent deux versions en parallèle, une AMD, une Intel, mais ça à mon avis faudrait pas trop rêver... On n'est pas non plus 100% sûr que les AMD sont exempts du bug, même si AMD dit que oui

Comme dit sur l'autre sujet, si AMD n'a rien à se reprocher, et que ça les touche, ça va pas être joli joli et il risque d'y avoir du procès dans l'air à tout va, bref ça n'arrivera pas

Après si ils ont un problème ça devient une autre histoire

J'espère sincèrement que les OS implémenteront le KPTI uniquement sur les procos Intel, maintenant reste à voir ce qui se passera en pratique

(J'ai un Ryzen 5 1600X)

Le 03 janvier 2018 à 14:27:53 GilbertSukhey a écrit :

Le 03 janvier 2018 à 14:25:37 jc-angel a écrit :
Merci pour ce topic
C'est bien résumé

Juste une question (si tu as la source sous le coude ça sera génial)
Il me semblé que le patch KPTI visé à corriger quelque chose d'encore plus critique que la faille sur le mécanisme de prédiction.
Il me semble que la faille sur le mécanisme de prédiction est connu depuis quelque temps ?
J'ai peut-être tous mélangé avec les news pas claire

Je vais double check mais de ce que j'ai compris le KPTI c'est justement la séparation des pages mémoire kernel et user process, et la faille du mécanisme de prédiction qui check pas permet de laisser un processus accéder à la zone mémoire kernel qui se trouve actuellement dans celle du processus user space. Donc en séparant les deux, c'est plus possible.

Oui c'est ça mais le patch initial s'appelé KAISER (ou la série de patch). Ca date de quelque temps déjà.
Et aujourd'hui on a un vent de panique à l'approche du patch KPTI.
Je me demande juste pourquoi aujourd'hui et pas aux première annonce de KAISER.
Peut-être a cause de bench...

Bref ce décalage me faisait pensé que KPTI annoncé une faille encore plus grave que le bug sur le mécanisme de prédiction.

Bref je me suis probablement trompé l’essentiel de l'information est la et je chipote sur un détail

ça va juste faire la maj sur les windows avec intel nn? Sinon j'aurai des fichiers AMD installé sur mon ordi après le premier reboot (sachant que j'ai intel). Windows fais les maj en fonction de ce que tu as donc les amd sont bon?

Pour AMD voila ce qu'il y a sur un commit du 4 décembre sur le noyaux linux :
(Flemme de me taper tous les répos pour voir si il y a des changement plus récent pour exclure le processeur AMD)
Many x86 CPUs leak information to user space due to missing isolation of user space and kernel space page tables. There are many well documented ways to exploit that. The upcoming software migitation of isolating the user and kernel space page tables needs a misfeature flag so code can be made runtime conditional. Add the BUG bits which indicates that the CPU is affected and add a feature bit which indicates that the software migitation is enabled. Assume for now that _ALL_ x86 CPUs are affected by this. Exceptions can be made later.

En bref, le patch (dans linux) peut-être activé ou non en fonction des processeurs. Mais actuellement tous les processeur x86 sont considéré comme pas sûr et le patch est donc activé que ça soit AMD ou Intel ou un processeur vieux de 15ans.
Il faudra plus de recherche pour savoir si les processeur AMD sont sûr ou non. Le principe de précaution veut qu'on les considère pas sûr pour l'instant.

De plus d'après ce que j'ai pu lire le principe même du KASLR semble être remis en question d'un point de vu sécurité
(C'est le fait d'avoir le KASLR qui permet d'avoir des appels systèmes plus rapide)

Le 03 janvier 2018 à 14:48:47 jc-angel a écrit :
Pour AMD voila ce qu'il y a sur un commit du 4 décembre sur le noyaux linux :
(Flemme de me taper tous les répos pour voir si il y a des changement plus récent pour exclure le processeur AMD)
Many x86 CPUs leak information to user space due to missing isolation of user space and kernel space page tables. There are many well documented ways to exploit that. The upcoming software migitation of isolating the user and kernel space page tables needs a misfeature flag so code can be made runtime conditional. Add the BUG bits which indicates that the CPU is affected and add a feature bit which indicates that the software migitation is enabled. Assume for now that _ALL_ x86 CPUs are affected by this. Exceptions can be made later.

En bref, le patch (dans linux) peut-être activé ou non en fonction des processeurs. Mais actuellement tous les processeur x86 sont considéré comme pas sûr et le patch est donc activé que ça soit AMD ou Intel ou un processeur vieux de 15ans.
Il faudra plus de recherche pour savoir si les processeur AMD sont sûr ou non. Le principe de précaution veut qu'on les considère pas sûr pour l'instant.

De plus d'après ce que j'ai pu lire le principe même du KASLR semble être remis en question d'un point de vu sécurité
(C'est le fait d'avoir le KASLR qui permet d'avoir des appels systèmes plus rapide)

C'est donc que les 32 bits? Pas les 64?

Le 03 janvier 2018 à 14:45:24 Belz3buth a écrit :
ça va juste faire la maj sur les windows avec intel nn? Sinon j'aurai des fichiers AMD installé sur mon ordi après le premier reboot (sachant que j'ai intel). Windows fais les maj en fonction de ce que tu as donc les amd sont bon?

La...logique voudrait que oui mais bon on en saura plus bientôt:oui:

Et juste une semaine avant le CES....hummm

Le 03 janvier 2018 à 14:55:32 superbegita a écrit :

Le 03 janvier 2018 à 14:45:24 Belz3buth a écrit :
ça va juste faire la maj sur les windows avec intel nn? Sinon j'aurai des fichiers AMD installé sur mon ordi après le premier reboot (sachant que j'ai intel). Windows fais les maj en fonction de ce que tu as donc les amd sont bon?

La...logique voudrait que oui mais bon on en saura plus bientôt:oui:

Et juste une semaine avant le CES....hummm

Qui a laissé le truc fuité? Qui le savait mais n'a rien dit? Ceux qui détenaient l'infos et qui n'ont rien moufter devaient avoir des couilles en OR. Les renseignements des états devaient se frotter les mains sur ce genre de faille..

Le 03 janvier 2018 à 14:52:49 Belz3buth a écrit :

Le 03 janvier 2018 à 14:48:47 jc-angel a écrit :
Pour AMD voila ce qu'il y a sur un commit du 4 décembre sur le noyaux linux :
(Flemme de me taper tous les répos pour voir si il y a des changement plus récent pour exclure le processeur AMD)
Many x86 CPUs leak information to user space due to missing isolation of user space and kernel space page tables. There are many well documented ways to exploit that. The upcoming software migitation of isolating the user and kernel space page tables needs a misfeature flag so code can be made runtime conditional. Add the BUG bits which indicates that the CPU is affected and add a feature bit which indicates that the software migitation is enabled. Assume for now that _ALL_ x86 CPUs are affected by this. Exceptions can be made later.

En bref, le patch (dans linux) peut-être activé ou non en fonction des processeurs. Mais actuellement tous les processeur x86 sont considéré comme pas sûr et le patch est donc activé que ça soit AMD ou Intel ou un processeur vieux de 15ans.
Il faudra plus de recherche pour savoir si les processeur AMD sont sûr ou non. Le principe de précaution veut qu'on les considère pas sûr pour l'instant.

De plus d'après ce que j'ai pu lire le principe même du KASLR semble être remis en question d'un point de vu sécurité
(C'est le fait d'avoir le KASLR qui permet d'avoir des appels systèmes plus rapide)

C'est donc que les 32 bits? Pas les 64?

Non je pense pas, x86 c'est l'architecture et le jeu d'instruction (bon en vrai ça fait longtemps que les archis sont plus comme les Intel 8086 qui ont donné leur nom au jeu d'instruction, c'est du x86-compatible avec des instructions étendues).

Les 64 bits c'est x86_64, ça reste le même genre.

Un autre genre de proco ça serait plutôt PowerPC

Le 03 janvier 2018 à 15:00:06 GilbertSukhey a écrit :

Le 03 janvier 2018 à 14:52:49 Belz3buth a écrit :

Le 03 janvier 2018 à 14:48:47 jc-angel a écrit :
Pour AMD voila ce qu'il y a sur un commit du 4 décembre sur le noyaux linux :
(Flemme de me taper tous les répos pour voir si il y a des changement plus récent pour exclure le processeur AMD)
Many x86 CPUs leak information to user space due to missing isolation of user space and kernel space page tables. There are many well documented ways to exploit that. The upcoming software migitation of isolating the user and kernel space page tables needs a misfeature flag so code can be made runtime conditional. Add the BUG bits which indicates that the CPU is affected and add a feature bit which indicates that the software migitation is enabled. Assume for now that _ALL_ x86 CPUs are affected by this. Exceptions can be made later.

En bref, le patch (dans linux) peut-être activé ou non en fonction des processeurs. Mais actuellement tous les processeur x86 sont considéré comme pas sûr et le patch est donc activé que ça soit AMD ou Intel ou un processeur vieux de 15ans.
Il faudra plus de recherche pour savoir si les processeur AMD sont sûr ou non. Le principe de précaution veut qu'on les considère pas sûr pour l'instant.

De plus d'après ce que j'ai pu lire le principe même du KASLR semble être remis en question d'un point de vu sécurité
(C'est le fait d'avoir le KASLR qui permet d'avoir des appels systèmes plus rapide)

C'est donc que les 32 bits? Pas les 64?

Non je pense pas, x86 c'est l'architecture et le jeu d'instruction (bon en vrai ça fait longtemps que les archis sont plus comme les Intel 8086 qui ont donné leur nom au jeu d'instruction, c'est du x86-compatible avec des instructions étendues).

Les 64 bits c'est x86_64, ça reste le même genre.

Un autre genre de proco ça serait plutôt PowerPC

merci !

Le 03 janvier 2018 à 15:00:06 GilbertSukhey a écrit :

Le 03 janvier 2018 à 14:52:49 Belz3buth a écrit :

Le 03 janvier 2018 à 14:48:47 jc-angel a écrit :
Pour AMD voila ce qu'il y a sur un commit du 4 décembre sur le noyaux linux :
(Flemme de me taper tous les répos pour voir si il y a des changement plus récent pour exclure le processeur AMD)
Many x86 CPUs leak information to user space due to missing isolation of user space and kernel space page tables. There are many well documented ways to exploit that. The upcoming software migitation of isolating the user and kernel space page tables needs a misfeature flag so code can be made runtime conditional. Add the BUG bits which indicates that the CPU is affected and add a feature bit which indicates that the software migitation is enabled. Assume for now that _ALL_ x86 CPUs are affected by this. Exceptions can be made later.

En bref, le patch (dans linux) peut-être activé ou non en fonction des processeurs. Mais actuellement tous les processeur x86 sont considéré comme pas sûr et le patch est donc activé que ça soit AMD ou Intel ou un processeur vieux de 15ans.
Il faudra plus de recherche pour savoir si les processeur AMD sont sûr ou non. Le principe de précaution veut qu'on les considère pas sûr pour l'instant.

De plus d'après ce que j'ai pu lire le principe même du KASLR semble être remis en question d'un point de vu sécurité
(C'est le fait d'avoir le KASLR qui permet d'avoir des appels systèmes plus rapide)

C'est donc que les 32 bits? Pas les 64?

Non je pense pas, x86 c'est l'architecture et le jeu d'instruction (bon en vrai ça fait longtemps que les archis sont plus comme les Intel 8086 qui ont donné leur nom au jeu d'instruction, c'est du x86-compatible avec des instructions étendues).

Les 64 bits c'est x86_64, ça reste le même genre.

Un autre genre de proco ça serait plutôt PowerPC

Un autre genre de proco ça serait plutôt ARM utilisé notamment sur les smartphones (exemple plus pertinent )
(Au passage les smartphones utilisent aussi un noyau linux)