Je dis peut-être des bêtises, mais d'après ce que j'ai compris c'est justement ce qui fait que les processeurs AMD ne sont pas touchés par Meltdown : ils vérifient les permissions avant l'exécution spéculative, alors que les Intel le font tout à la fin, comme tu dis.
Je ne suis pas allé vérifier si c'est vrai ou faux, donc je ne me prononcerai pas sur le fond, mais si c'est le cas, alors à moins d'avoir une MMU extrêmement performante (ce qui est peut-être le cas aussi), alors cela mettrait complètement à mal l'exécution spéculative puisqu'elle serait obligée d'attendre sa décision avant d'être exécutée. Donc, ce ne serait plus de l'exécution spéculative. Et c'est un problème puisque cela concernerait TOUS les accès mémoire, aussi bien en lecture qu'en écriture, puisqu'il est par définition impossible de savoir si un accès est en dehors de sa plage avant de l'avoir examiné (sauf modes indexés spéciaux avec un offset notoirement local, parce que défini dans un petit registre (par exemple, sur 8 bits)). Donc, ce serait extrêmement fréquent dans un programme.
Reste à savoir si c'était quelque chose qui était réellement imaginable à l'avance, surtout au moment où les premières puces à pipeline ont été produites, puisque les rares qui sont encore en fonctionnement aujourd'hui sont menacées aussi. Autrement dit : est-ce vraiment une faute grave du constructeur compte tenu de son expérience et de son expertise, ou est-ce vraiment la faute à pas de chance ?
Parce qu'à ce compte-là, des compromissions de ce genre, on en a connu beaucoup dans le domaine logiciel mais, elles, peuvent être facilement patchées. Les générations de collisions pour MD5 et SHA1, par exemple, sont dans leur genre des petites bombes elles aussi et la dernière concernait particulièrement Git. Alors, certes, il « suffit » de passer à une nouvelle fonction de hachage pour pallier le problème jusqu'à ce qu'elle soit cassée à son tour, mais étant donné la diffusion du logiciel, il n'est pas concevable de réécrire toutes les sommes de tous les objets de tous les dépôts du monde, qui parfois contiennent des objets qui sont aussi vieux que Git lui-même, à commencer par le dépôt du noyau Linux. La seule solution consisterait à faire cohabiter les deux versions en marquant la première comme dépréciée.
Ici, c'est particulièrement grave parce que la faille se produit à très bas niveau, et a donc un impact très large en conséquence mais étant donné la complexification toujours plus forte des systèmes et le point auquel ils sont répandus, je pense qu'il va falloir s'attendre à faire face à ce genre d'incident à intervalles relativement régulier.
[^] # Re: Comment une faille peut-elle toucher plusieurs processeurs de plusieurs fondeurs ?
Posté par Obsidian . En réponse à la dépêche Deux failles critiques : Meltdown et Spectre. Évalué à 6.
Je ne suis pas allé vérifier si c'est vrai ou faux, donc je ne me prononcerai pas sur le fond, mais si c'est le cas, alors à moins d'avoir une MMU extrêmement performante (ce qui est peut-être le cas aussi), alors cela mettrait complètement à mal l'exécution spéculative puisqu'elle serait obligée d'attendre sa décision avant d'être exécutée. Donc, ce ne serait plus de l'exécution spéculative. Et c'est un problème puisque cela concernerait TOUS les accès mémoire, aussi bien en lecture qu'en écriture, puisqu'il est par définition impossible de savoir si un accès est en dehors de sa plage avant de l'avoir examiné (sauf modes indexés spéciaux avec un offset notoirement local, parce que défini dans un petit registre (par exemple, sur 8 bits)). Donc, ce serait extrêmement fréquent dans un programme.
Reste à savoir si c'était quelque chose qui était réellement imaginable à l'avance, surtout au moment où les premières puces à pipeline ont été produites, puisque les rares qui sont encore en fonctionnement aujourd'hui sont menacées aussi. Autrement dit : est-ce vraiment une faute grave du constructeur compte tenu de son expérience et de son expertise, ou est-ce vraiment la faute à pas de chance ?
Parce qu'à ce compte-là, des compromissions de ce genre, on en a connu beaucoup dans le domaine logiciel mais, elles, peuvent être facilement patchées. Les générations de collisions pour MD5 et SHA1, par exemple, sont dans leur genre des petites bombes elles aussi et la dernière concernait particulièrement Git. Alors, certes, il « suffit » de passer à une nouvelle fonction de hachage pour pallier le problème jusqu'à ce qu'elle soit cassée à son tour, mais étant donné la diffusion du logiciel, il n'est pas concevable de réécrire toutes les sommes de tous les objets de tous les dépôts du monde, qui parfois contiennent des objets qui sont aussi vieux que Git lui-même, à commencer par le dépôt du noyau Linux. La seule solution consisterait à faire cohabiter les deux versions en marquant la première comme dépréciée.
Ici, c'est particulièrement grave parce que la faille se produit à très bas niveau, et a donc un impact très large en conséquence mais étant donné la complexification toujours plus forte des systèmes et le point auquel ils sont répandus, je pense qu'il va falloir s'attendre à faire face à ce genre d'incident à intervalles relativement régulier.