IPB

Bienvenue invité ( Connexion | Inscription )

> Une faille matérielle touche les puces M1, M2 et M3, Réactions à la publication du 22/03/2024
Options
Lionel
posté 22 Mar 2024, 13:18
Message #1


BIDOUILLE Guru
*****

Groupe : Admin
Messages : 55 354
Inscrit : 14 Jan 2001
Lieu : Paris
Membre no 3



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



--------------------
C'est parce que la vitesse de la lumière est plus grande que celle du son que tant de gens paraissent brillants avant d'avoir l'air con
Go to the top of the page
 
+Quote Post
 
Start new topic
Réponse(s)
Paul Emploi
posté 23 Mar 2024, 20:00
Message #2


Macbidouilleur de bronze !
**

Groupe : Rédacteurs
Messages : 416
Inscrit : 19 Nov 2020
Membre no 212 895



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.
Go to the top of the page
 
+Quote Post

Les messages de ce sujet


Reply to this topicStart new topic
1 utilisateur(s) sur ce sujet (1 invité(s) et 0 utilisateur(s) anonyme(s))
0 membre(s) :

 



Nous sommes le : 31st May 2024 - 06:55