Une faille matérielle touche les puces M1, M2 et M3, Réactions à la publication du 22/03/2024

[Lionel]

Des chercheurs en sécurité ont découvert une faille dans les puces Apple Silicon.

La faille est liée à des optimisations permettant d'améliorer les performances mémoire en réalisant des prédictions. Pour faire simple, la puce va tenter de prédire quelles données mémoire seront demandées par le code exécuté en cours et les charger pour les mettre à sa disposition.
En cas de succès, on gagne du temps, en cas d'échec on en perd seulement un tout petit peu.
Le système n'est cependant pas parfait et il s'avère que celui utilisé par Apple permet via une attaque de récupérer les clés de chiffrement utilisées par la puce pour protéger les contenus et ainsi les rendre lisibles
Une preuve de concept fonctionnelle existe déjà.

Mauvaise nouvelle, tous les systèmes dont nous vous parlons sont codés en dur dans les puces. Il n'est donc pas possible de les corriger sauf à modifier de manière matérielle ces dernières.
On peut bien entendu imaginer une atténuation logicielle mais elle pèserait considérablement sur les performances de ces processeurs. Intel a déjà connu ça par le passé.

Apple s'en remettra. Il reste seulement à trouver le moyen de régler le problème et que les machines dans le futur ne soient pas concernées. Pour les actuelles c'est une autre histoire.

Lien vers le billet original

[Paul Emploi]

Rien de tout cela!

• Optimiser l'usage des "multi-processeurs"? Non. Ça optimise les performances du cœur.
• Prédiction de processus? Non.
• Prédiction de la répartition du code exécuté? Non.
• Raccourcir les temps d'allocation? Non. Pas d'allocation là-dedans.
• Problème étant que le code "reste" en cache? Non. Le code reste en cache L1 des deux cotés et on s'en fout d'aillleurs.
• La fréquence d'actualisation est connue? Non. De quelle fréquence parles-tu, puisque le code reste en cache L1.
• Il devient alors parfaitement possible de l'identifier et donc de le lire [le code]? Non. Le code n'est pas lu.
• Il serait possible de changer les allocations mémoire et fréquences? Non. Pas d'allocation.
• Il serait possible [...] de les chiffrer [les allocations memoire et fréquences]? Non. Aucun rapport.
• Atténuant l'intérêt du multiprocesseur? Non. Aucun rapport.

il s'agit d'une attaque de side-channel sur le cache L2 partagé dans chaque cluster de cœurs, au travers du DMP des cœurs de type Performance qui précharge des données dans ce cache lorsqu'un registre utilisé comme pointeur semble pointer sur dse pointeurs, et d'une validation de chargement ou non via les timing d'accès permettant d'en déduire les traitements effectués ou non, timing précis lus grâce à la mémoire partagée avec le 3ème process pour bypasser tout jitter extérieur (des protections au niveau de macOS).
Voir sur GoFetch.fail.

[Benzebut]

Rien de tout cela!

Tout cela, mais avec le mauvais terme. Il s'agit bien sur de "multi-cœurs" et non pas de "multi-processeurs" dans le précédent message. Je vais apporter la motion pour clarifier, car bien évidemment, la fonction Data Memory-dependent Prefetcher (ou DMP) ne peut que concerner les cœurs des processeurs.

il s'agit d'une attaque de side-channel sur le cache L2 partagé dans chaque cluster de cœurs, au travers du DMP des cœurs de type Performance qui précharge des données dans ce cache lorsqu'un registre utilisé comme pointeur semble pointer sur dse pointeurs, et d'une validation de chargement ou non via les timing d'accès permettant d'en déduire les traitements effectués ou non, timing précis lus grâce à la mémoire partagée avec le 3ème process pour bypasser tout jitter extérieur (des protections au niveau de macOS).
Voir sur GoFetch.fail.

Ce qui fut le cas de Meltdown et Spectre sur Intel, s'appuyant sur les technologies de prédiction pour identifier des données confidentielles et qui entraînaient la fuite de « l'adresse ». Encore une fois, pas évident qu'il s'agisse d'une "faille", mais plus des limites de l'architecture des microprocesseurs actuels avec trop de cœurs à gérer...

[Paul Emploi]

il s'agit d'une attaque de side-channel sur le cache L2 partagé dans chaque cluster de cœurs, au travers du DMP des cœurs de type Performance qui précharge des données dans ce cache lorsqu'un registre utilisé comme pointeur semble pointer sur dse pointeurs, et d'une validation de chargement ou non via les timing d'accès permettant d'en déduire les traitements effectués ou non, timing précis lus grâce à la mémoire partagée avec le 3ème process pour bypasser tout jitter extérieur (des protections au niveau de macOS).
Voir sur GoFetch.fail.

Ce qui fut le cas de Meltdown et Spectre sur Intel, s'appuyant sur les technologies de prédiction pour identifier des données confidentielles et qui entraînaient la fuite de « l'adresse ». Encore une fois, pas évident qu'il s'agisse d'une "faille", mais plus des limites de l'architecture des microprocesseurs actuels avec trop de cœurs à gérer...

Rien à voir avec les microprocesseurs actuels car les attaques de side-channel sur les caches sont des dérivés des attaques sur les fautes de page des années 60 et suivantes. Le principe est le même, on a la trace d'un accès mémoire fait ou pas qui modifie l'état interne et dont on peut mesurer l'effet.

Et ça n'est pas lié au nombre de cœurs, cette attaque fonctionnerait parfaitement en mono-cœur si macOS n'introduisait pas un jitter important sur les mesures de temps, une protection servant à rendre ce type d'attaque très difficile car extrêmement lent. Enfin, encore plus lent.
D'où le troisième processus qui sert de base de temps au travers d'adresses mémoires partagées et en fait via le cache L2 puisque sur le même cluster.

Le DMP n'a définitivement aucun rapport avec le fait qu'une CPU soit multicœur, il ne sert qu'à ramener des données au plus près en anticipant leur potentiel accès.

[Benzebut]

Rien à voir avec les microprocesseurs actuels car les attaques de side-channel sur les caches sont des dérivés des attaques sur les fautes de page des années 60 et suivantes. Le principe est le même, on a la trace d'un accès mémoire fait ou pas qui modifie l'état interne et dont on peut mesurer l'effet.

Et ça n'est pas lié au nombre de cœurs, cette attaque fonctionnerait parfaitement en mono-cœur si macOS n'introduisait pas un jitter important sur les mesures de temps, une protection servant à rendre ce type d'attaque très difficile car extrêmement lent. Enfin, encore plus lent.
D'où le troisième processus qui sert de base de temps au travers d'adresses mémoires partagées et en fait via le cache L2 puisque sur le même cluster.

Le DMP n'a définitivement aucun rapport avec le fait qu'une CPU soit multicœur, il ne sert qu'à ramener des données au plus près en anticipant leur potentiel accès.

L'architecture des processeurs actuels amplifie les risques d'attaques sur les caches, simplement par le nombre actif et les accès faits. Idem pour le DMP, l'usage du multi-cœur demande de ramener et anticiper au plus près, pour optimiser les accès et éviter les goulots d'étranglement avec les composants. D'où le non de l'exploit : "Go fetch" ou "Va chercher"...

Ainsi, du moment que la donnée peut être localisée et en parallèle identifier quand elle sera utilisée, il y a un risque de corruption. Toute forme d'architecture retenue. Toute génération de microprocesseurs connue.

Bref, l'exploit identifie les limites de l'architecture des microprocesseurs actuels, même si cela reste un bel exploit qui devrait permettre de faire de nouvelles optimisation des architectures. Jusqu'à la prochaine limite à aller chercher...

[Paul Emploi]

L'architecture des processeurs actuels amplifie les risques d'attaques sur les caches, simplement par le nombre actif et les accès faits.

Toujours faux.

Les caches en lecture ont toujours un side-channel temporel, que ça soit un cache-disque, le cache d'un navigateur, ou les niveaux de cache dans une CPU ou un sous-système mémoire. Même ma bibliothèque a ce problème, puisque le livre que je lis actuellement est posé sur mon bureau pour que j'y accède plus rapidement...
Pas besoin de grands mots sur les "multiprocesseurs" ou "multi-cœurs" qui n'ont rien à voir, de parler de "parallélisme" qui n'a aucun sens pour GoFetch, ni même de "corruption".

Un cache en lecture génère forcément des différences de temps d'accès, c'est même son but premier, permettre d'accéder plus rapidement aux données dont on a besoin, et dans ce cas d'accéder plus vite aux données dont on pourrait avoir besoin (prefetching). Le side-channel est inévitable, il correspond au but des caches.
Comme poser des jeux vidéos ou des jeux traditionnels sur sa table de salon avant de recevoir des amis ou de la famille pour une soirée, du prefetching, pour gagner du temps.
Ou une bouteille ou deux.

Si on connait mes amis et ma famille, quelqu'un passant chez moi saurait qui je vais probablement recevoir à cause de ce prefetching, cette anticipation.
Pas besoin de vocabulaire technique non-maîtrisé, de grands mots, ni d'accuser "l'architecture des processeurs actuels", factuellement ce type d'attaque informatique existe depuis qu'on utilise des caches, et même avant puisqu'elles ne sont pas liées à l'informatique, c'est juste essayer d'anticiper qui est mesurable, et qui doit l'être...

Cette attaque est de toute façon très théorique et ne pose aucun problème en pratique, le code attaqué étant spécifiquement conçu pour permettre ce type d'attaque, qui reste un bel exploit, mais ne correspondant à rien de réel. Comme toujours, utilisez CryptoKit!

[Benzebut]

Si on connait mes amis et ma famille, quelqu'un passant chez moi saurait qui je vais probablement recevoir à cause de ce prefetching, cette anticipation.
Pas besoin de vocabulaire technique non-maîtrisé, de grands mots, ni d'accuser "l'architecture des processeurs actuels", factuellement ce type d'attaque informatique existe depuis qu'on utilise des caches, et même avant puisqu'elles ne sont pas liées à l'informatique, c'est juste essayer d'anticiper qui est mesurable, et qui doit l'être...

Et rebelote, même si cette discussion s'éloigne de plus en plus de la raison initiale sur cette "faille"...

Pour reprendre l'exemple cité sans grands mots, si votre bibliothèque n'avait qu'un seul livre dans ses étagères, il serait aisé d'y accéder pour retrouver le chapitre commencé. Si plusieurs volumes sont disponibles et que vous ayez rangé les livres commencés dans ces mêmes étagères, il faudrait plus de repères pour les trouver. La quantité de données amplifie donc la démarche de recherche par multiplication des repères (ce qui est une Lapalissade).
Ensuite, si vous avez des ouvrages prédisposés devant votre bibliothèque, cela indique à un tiers vos lectures du moment. Avec le même phénomène, un seul ouvrage permet d'identifier une histoire en cours de lecture. Plusieurs ouvrages le genre, l'auteur, la série, le héro et consorts. La multiplicité de la sélection permet de prédire finement la lecture choisie (ce qui est un profilage).

Bref, comme indiqué précédemment, cet exploit identifie les limites de l'architecture des microprocesseurs actuels, comme cela fut le cas avec plein de contraintes en informatique avant, voire des techniques d'une manière générale. Ce qui remet bien au gout du jour le principe de Vauban où toute citadelle est prenable, ce n'est qu'une question de temps et de ressources (avec ou sans CryptoKit) ...