L'auteur est la personne qui a reviewé le patch du kernel Linux mergé par torvalds.
La faille semble en effet liée à l'exécution spéculative de certaines instructions. En juillet, celui-ci a réalisé que les données de l'espace noyau pouvaient se retrouver en cache en éxecution non privilégiée, alors que l'accès devrait lever une faute de protection. Il ne peut en revanche pas lire le contenu de la mémoire. Entre ce moment et aujourd'hui, je pense que ce qui a été trouvé est une façon de lire cette mémoire (les détails viendront sûrement dans les jours à venir).
Visiblement, seuls les processeurs Intel sont concernés, les AMD implémentant correctement cette vérification dans le cadre de l'exécution spéculative.
Le fix implémenté par les OS, si j'ai bien compris, est ainsi de complètement séparer les espaces kernel et user (alors que jusqu'à présent, pour des raisons de perf (éviter un flush de TLB lors du passage en noyau), l'espace kernel était mappé en haut de l'espace user (d'où les 3GB de mémoire utilisable seulement sur un processeur 32 bits). Évidemment, l'accès aux pages du kernel est protégé via un bit d'accès User/Supervisor (http://wiki.osdev.org/Paging, section Page Directory). C'est visiblement ce bit qui n'est pas respecté dans le cadre de l'exécution spéculative.
J'imagine que le plus gros bazar dans cela, en plus de forcer un flush de la TLB (ce qui explique la chute des perfs dans les benchmarks), est de pouvoir toujours lire la mémoire user depuis le kernel, ce qui demande de jongler entre les 2 espaces. Je pense que c'est ce qui fait le plus gros du patch intégré au noyau. Et si torvalds l'a mergé sans broncher en insistant, c'est car c'est grave, et qu'il est encore impossible de divulguer cette faille.
Ce bug est donc assez exceptionnel dans le sens où aucune mise à jour côté microcode du cpu ne peut venir corriger ce problème (sur certains CPU avec des bugs hardware, c'est aux compilos de s'adapter). Il reste donc aux OS à corriger ce souci (Linux, Windows, FreeBSD, MacOS, et tous les autres). La question du parano en suspens est: cette faille était-elle connue avant par certains gouvernements et l'ont ils utilisé?
# Les prémisses de cette faille
Posté par Pierrick Bouvier . En réponse au journal Ça sent pas bon chez Intel ?. Évalué à 10.
En cherchant un peu plus sur cette faille, je suis tombé sur l'article suivant datant du mois de juillet dernier.
https://cyber.wtf/2017/07/28/negative-result-reading-kernel-memory-from-user-mode/
L'auteur est la personne qui a reviewé le patch du kernel Linux mergé par torvalds.
La faille semble en effet liée à l'exécution spéculative de certaines instructions. En juillet, celui-ci a réalisé que les données de l'espace noyau pouvaient se retrouver en cache en éxecution non privilégiée, alors que l'accès devrait lever une faute de protection. Il ne peut en revanche pas lire le contenu de la mémoire. Entre ce moment et aujourd'hui, je pense que ce qui a été trouvé est une façon de lire cette mémoire (les détails viendront sûrement dans les jours à venir).
Visiblement, seuls les processeurs Intel sont concernés, les AMD implémentant correctement cette vérification dans le cadre de l'exécution spéculative.
Le fix implémenté par les OS, si j'ai bien compris, est ainsi de complètement séparer les espaces kernel et user (alors que jusqu'à présent, pour des raisons de perf (éviter un flush de TLB lors du passage en noyau), l'espace kernel était mappé en haut de l'espace user (d'où les 3GB de mémoire utilisable seulement sur un processeur 32 bits). Évidemment, l'accès aux pages du kernel est protégé via un bit d'accès User/Supervisor (http://wiki.osdev.org/Paging, section Page Directory). C'est visiblement ce bit qui n'est pas respecté dans le cadre de l'exécution spéculative.
J'imagine que le plus gros bazar dans cela, en plus de forcer un flush de la TLB (ce qui explique la chute des perfs dans les benchmarks), est de pouvoir toujours lire la mémoire user depuis le kernel, ce qui demande de jongler entre les 2 espaces. Je pense que c'est ce qui fait le plus gros du patch intégré au noyau. Et si torvalds l'a mergé sans broncher en insistant, c'est car c'est grave, et qu'il est encore impossible de divulguer cette faille.
Ce bug est donc assez exceptionnel dans le sens où aucune mise à jour côté microcode du cpu ne peut venir corriger ce problème (sur certains CPU avec des bugs hardware, c'est aux compilos de s'adapter). Il reste donc aux OS à corriger ce souci (Linux, Windows, FreeBSD, MacOS, et tous les autres). La question du parano en suspens est: cette faille était-elle connue avant par certains gouvernements et l'ont ils utilisé?