GoFetch, une nouvelle faille matérielle qui touche les puces Apple Silicon
Une nouvelle attaque vient d'être présentée par des chercheurs, GoFetch. Elle a deux particularités : elle vise les puces Apple et ne peut pas être corrigée facilement, car elle se base sur des fonctions matérielles des processeurs. Les solutions pour s'en protéger impliquent donc de grosses pertes de performances, car la faille ne peut pas être comblée directement.
GoFetch, donc, se base sur une des fonctions des puces M d'Apple, le DMP (Data Memory-dependent Prefetcher). Nous allons essayer de faire simple : les processeurs, depuis de nombreuses années, tentent de deviner ce qu'un programme va exécuter. L'idée (efficace) consiste à analyser les flux pour déterminer les prochaines instructions et les prochaines données à charger. Le cas du prefetch classique est assez simple : les algorithmes essayent de charger les données en mémoire cache (très rapide) avant que le programme en ait besoin et pendant que le CPU effectue une autre tâche. S'ils ont raison, les accès sont plus rapides, tout comme le programme.
Dans un CPU classique, les algorithmes travaillent sur des adresses, qui déterminent la position des données dans la mémoire, sans avoir aucune idée du contenu des données. Avec le DMP, présent aussi dans les derniers CPU Intel, les algorithmes analysent les données pour trouver ce qu'ils pensent être des pointeurs. De façon très simplifiée, un pointeur est l'équivalent d'une adresse stockée dans les données, et donc si l'algorithme en trouve un, il peut précharger les données qu'il pointe pour accélérer les chargements.
Un problème de détection
Le principe de la faille, c'est que l'algorithme ne peut pas déterminer s'il s'agit réellement d'un pointeur, mais seulement si les données ressemblent à un pointeur. Le principe de l'attaque consiste donc à créer des données qui ressemblent à des pointeurs pour tenter de récupérer des données qui ne devraient pas se trouver dans la mémoire cache. L'ensemble est compliqué — vous pouvez aller lire le papier dédié si le cœur vous en dit — mais les chercheurs indiquent que leur application peut récupérer une clé RSA-2048 en moins d'une heure avec un programme qui n'a pas besoin de droits particuliers. Il y a quelques limites pratiques tout de même : l'application attaquée (qui peut par exemple être OpenSSL)doit être exécutée sur le même cluster dans une puce M, c'est-à-dire un groupe de cœurs au niveau de la puce. L'attaque est efficace contre différents types de chiffrements, mais le temps nécessaire peut être plus élevé.
Pour les chercheurs, les solutions sont peu nombreuses. La première consiste à n'effectuer les calculs cryptographiques que sur les cœurs basse consommation (cœurs E). Ils ne bénéficient pas du DMP mais sont malheureusement plus lents. La seconde consiste à adapter les programmes pour éviter les fuites de données, mais ils indiquent que la perte de performances peut être élevée, en fonction des algorithmes. Enfin, il est possible de désactiver le DMP sur les puces M3 pour un programme précis, mais les chercheurs n'indiquent pas les éventuelles pertes de performances.
Cette faille montre surtout que même avec un matériel parfaitement maîtrisé, il reste possible d'avoir des problèmes de sécurité. Et dans le cas précis, il est visiblement impossible pour Apple de corriger la faille dans les puces M1 et M2. Enfin, notons qu'Apple a été prévenu de la faille en décembre 2023.
Et même problème sur les iPhone ?
Comment l'attaque est-elle mise en oeuvre ? Y a-t-il besoin d'un accès physique à la cible, un simple programme dans MacOS suffit-il ?
Si un accès physique est nécessaire avec des accès au noyau du système, le système doit être assez bien protégé pour la plupart des utilisateurs.
@Marius_K :
merci de poser la question essentielle sur la mise en œuvre, car la dangerosité en dépend grandement.
@Marius_K
Il faut au moins une application qui tourne en local. Pas de droits d'administration en revanche.
Ça veut dire que ça ne devrait pas fonctionner depuis un site web, ce qui est déjà un début...
@Link1993
Via WebAssembly peut être :(
@Link1993
Les navigateurs web compilent les applis web et là l'assembleur à obtenir est assez simple
@Marius_K,
« Comment l'attaque est-elle mise en oeuvre ? »
C'est une faille de type Spectre ou Meltdown. Elle est liée au mécanisme de prefetch qui peut être abusé pour extraire des informations, par exemple une clé de cryptographie.
Il n'y a pas besoin d'élévation de privilèges. Autrement dit, les droits administration ne sont pas nécessaires.
« Y a-t-il besoin d'un accès physique à la cible, un simple programme dans MacOS suffit-il ? »
Tout programme fonctionnant dans le même cluster de cœurs P peut accéder illégalement à des données en trompant le prefetch au moyen de faux pointeurs.
Il n'est pas nécessaire d'avoir un accès physique. Tout programme ou extension ou code JIT avec cet exploit semble pouvoir utiliser cette faille, même sans droit d'administration.
« Si un accès physique est nécessaire avec des accès au noyau du système, le système doit être assez bien protégé pour la plupart des utilisateurs. »
Ce n'est pas le cas.
Pour les processeurs M1 et M2, seul un patch logiciel au niveau de macOS pourrait neutraliser l'exploit en désactivant de manière logicielle le prefetch mais au détriment d'une chute des performances.
Pour les processeurs M3, la faille est exactement la même !
Seule différence “notable”, il existe un interrupteur matériel au niveau de la gestion des cœurs P qui peut stopper cet exploit en arrêtant la fonction de prefetch !
Par contre, la chute des performances sera logiquement la même qu'avec une solution logicielle comme pour les M1 et M2 car la fonction de prefetch est neutralisée dans tous les cas !
Plus d'informations :
https://www.tomshardware.com/pc-components/cpus/new-chip-flaw-hits-apple-silicon-and-steals-cryptographic-keys-from-system-cache-gofetch-vulnerability-attacks-apple-m1-m2-m3-processors-cant-be-fixed-in-hardware
👌
@Scooby-Doo
Merci pour ton explication ;)
@YuYu,
Merci ! Bonne journée…
😉
Je n'y comprends rien mais je suis admiratif de la capacité de certains à trouver ce genre de truc. Il faut être sacrément au point...
@smog
Idem.
Mais j’aimerais quand même savoir, concrètement, comment peut se déployer cette faille?
Grâce à un site web? Un logiciel malveillant? Du phishing? En accès physique seulement?
Plus d’éclaircissements, svp. Merci.
@smog, Artefact3000,
« Je n'y comprends rien mais je suis admiratif de la capacité de certains à trouver ce genre de truc. Il faut être sacrément au point... »
Ils n'ont rien trouvé de nouveau !
C'est une énième faille de type Spectre ou Meltdown à l'origine assez ancienne et fort bien connue chez Intel depuis 2018.
D'ailleurs elle fonctionne aussi sur Intel Raptor Lake !
Attention donc si vous utilisez un ordinateur avec ces processeurs :
Core i9-13900K, Core i7-13700K et Core i5-13600K par exemple.
https://www.tomshardware.com/news/intel-13th-gen-raptor-lake-release-date-specifications-pricing-benchmarks-all-we-know-specs
Ce qui est juste incroyable, c'est que les ingénieurs d'Apple n'en ont pas tenu compte lors de la conception du M1 !
Une explication de comment Microsoft a “patché” ce type de failles :
https://www.zdnet.fr/actualites/spectre-meltdown-microsoft-evoque-l-impact-de-son-patch-sur-les-performances-39862492.htm
Comment ce type de failles fonctionne :
Tout commence en janvier 2018. C'est à cette date que sont révélées au grand jour les failles de sécurité Spectre et Meltdown : deux vulnérabilités matérielles affectant presque tous les processeurs récents Intel et ARM. Ces failles peuvent être exploitées par les cybercriminels pour dérober des données sur presque n'importe quel ordinateur ou appareil mobile.
https://www.lebigdata.fr/explications-attaques-meltdown-spectre#:~:text=C%27est%20%C3%A0%20cette%20date%20que%20sont%20r%C3%A9v%C3%A9l%C3%A9es%20au,sur%20presque%20n%27importe%20quel%20ordinateur%20ou%20appareil%20mobile.
👌
@Scooby-Doo
"Ce qui est juste incroyable, c'est que les ingénieurs d'Apple n'en ont pas tenu compte lors de la conception du M1 !"
Parfaitement compréhensible : Apple ne conçoit pas ses processeurs. Apple personnalise des designs conçus par arm.
Alors on pourrait argumenter unité par unité, GPU ou IA ou crypto ou… n’empêche. Les cœurs et leurs caches, et c’est ce dont on parle ici, sont personnalisés sur une base arm.
@fte
« Parfaitement compréhensible : Apple ne conçoit pas ses processeurs. Apple personnalise des designs conçus par arm. »
Dans le cas d’Apple, non. Tout comme Qualcomm à une certaine époque (aujourd’hui révolue), Apple utilise une licence lui permettant d’exploiter le jeu d’instructions ARM , et conçoit ses propres design compatibles ARM v8 de A à Z.
Cependant la plupart des autres acteur (Mediatek, Qualcomm depuis de nombreuses années etc) utilisent en effet en l’état des cores designés par ARM, ou les modifient plus ou moins à la marge.
Mais de nouveau, ce n’est pas le cas d’Apple, tant pour ses Mx que pour ses Ax , qui sont de pures créations.
@benspx
"qui sont de pures créations."
C’est erroné, ça a été démontré par chips architects sauf erreur de ma part.
@fte
Je suis curieux d’avoir la source.
A ma connaissance, les designs Apple ne se basent absolument pas sur les core ARM, dont ils diffèrent même fortement dans leur logique.
Ce qui d’ailleurs est la raison pour laquelle Apple est l’un des très rares acteurs à avoir une licence pour le jeu d’instruction au global, l’autorisant à faire ce que bon lui semble en termes de design au lieu d’utiliser tel quel des cores ARM et/ou les modifier à la marge.
Cela étant, n’étant pas ingénieur spécialisé, je serais ravi de pouvoir en apprendre plus via l’article que tu évoques s’il était avéré que j’ai tort :)
@fte
D’ailleurs, MacG semble également de mon avis ;-)
« Troisième et dernière possibilité, la licence architecture. Dans ce cas, Arm permet de créer un CPU compatible avec le jeu d'instructions ARM, à partir de zéro. C'est la façon de faire d'Apple depuis l'A6 »
https://www.macg.co/mac/2020/04/en-route-vers-les-mac-arm-12-lexpertise-dapple-113663
@fte,
« Parfaitement compréhensible : Apple ne conçoit pas ses processeurs. Apple personnalise des designs conçus par arm. »
Edge Copilot :
Apple a développé ses propres cœurs de processeur, tels que les cœurs Firestorm et Icestorm.
Ces cœurs sont optimisés pour les appareils Apple et sont utilisés dans les SoC Apple Silicon.
Ils ne sont pas simplement des cœurs ARM génériques, mais plutôt des versions améliorées et adaptées.
👌
Si vous avez des sources contredisant Edge Copilot, je suis preneur !
😁
@Scooby-Doo
"mais plutôt des versions améliorées et adaptées."
C’est ça. Des versions améliorées et adaptées. Personnalisées pour les profiles d’usages particuliers des iPhone. Les IO Flash par exemple, qu’Apple a été le premier à amener au niveau des ordinateurs portables en multipliant la vitesse de transferts par 5 ou je ne sais quel gros chiffre. 6s ? Whatever.
C’est exactement ce que je disais hein. Améliorées, adaptées. Personnalisées.
Mais qu’importe, l’architecture de base est d’arm, et ces failles se retrouvent dans l’ensemble des processeurs arm, à des variations près, dépendantes des variations d’implémentation.
Coller cela sur le dos d’Apple ne me dérange pas. Go. Mais ce n’est pas exact. Le design de base est d’arm et ces failles découlent du design de base arm que non Apple n’a pas créé de toutes pièces.
@fte,
« C’est exactement ce que je disais hein. Améliorées, adaptées. Personnalisées.
Mais qu’importe, l’architecture de base est d’arm, et ces failles se retrouvent dans l’ensemble des processeurs arm, à des variations près, dépendantes des variations d’implémentation.
Coller cela sur le dos d’Apple ne me dérange pas. Go. Mais ce n’est pas exact. Le design de base est d’arm et ces failles découlent du design de base arm que non Apple n’a pas créé de toutes pièces. »
👍
Effectivement, ARM et Intel ont été gravement impacté par ces failles et dans une moindre mesure AMD.
Wikipédia :
À compter de 2018, presque tous les systèmes informatiques sont affectés par Spectre, y compris les ordinateurs de bureau, portables et appareils mobiles. Plus précisément, Spectre a été déclaré fonctionnel sur des processeurs Intel, AMD, et ARM. Intel a répondu aux vulnérabilités de sécurité avec une déclaration officielle.
Selon une déclaration faite par AMD, la vulnérabilité à la seconde variante de Spectre n'a pas été montrée sur les processeurs AMD et le « risque d'exploitation [serait] quasi nul » en raison de différences dans l'architecture AMD.
👌
Comme quoi j'ai bien fait de vous poser cette question !
🧐
@fte
"C’est ça. Des versions améliorées et adaptées. Personnalisées pour les profiles d’usages particuliers des iPhone"
De nouveau, et jusqu'à preuve du contraire, je suis toujours en désaccord avec ce propos.
Comme également évoqué par MacG, les coeur Apple ne sont PAS dérivés de coeurs ARM existants.
Les coeurs Apple sont compatibles avec le jeu d'instruction d'ARM (c'est pour cela qu'Apple paye une licence à ce dernier), au même titre qu'un Ryzen est compatible avec le jeu d'instruction X86, mais ils ne sont pas plus dérivés des coeurs ARM qu'un Ryzen n'est dérivé des coeurs d'un i5 ou d'un i7.
C'est d'ailleurs ce qui explique l'énorme différence de performance et d'efficacité entre la plupart des coeurs Apple et les coeurs ARM correspondants au fil des années (Cortex X1 , X2, X3, A510, A710, A520, A510 etc etc).
Les coeurs d'Apple ne sont pas dérivés des coeurs d'ARM.
Apple développe ses propres coeurs avec une seule contrainte : ils doivent exécuter les instructions ARM standardisées. Mais la structure elle-même est totalement développée en interne depuis l'A6. Ils ne sont ni dérivés ni adapté ni personnalisés.
La faille présentée ici, elle ne touche pas les autres puces ARM, parce que le type de préchargement mis en oeuvre n'est pas utilisé dans les puces issues de chez ARM.
Après, faut bien comprendre que du prefetch, c'est un truc standard : Apple et Intel le font, parce que c'est une voie intéressante, mais en interne c'est fait différemment.
@Pierre Dandumont,
« La faille présentée ici, elle ne touche pas les autres puces ARM, parce que le type de préchargement mis en oeuvre n'est pas utilisé dans les puces issues de chez ARM. »
Je le note, mais pourquoi la série Intel Raptor Lake qui ne partage pas son jeu d'instructions est impactée par la même faille ?
Est-ce le mécanisme de l'attaque qui est identique parce que dans les deux implémentations, le prefetch peut être abusé par des pointeurs frauduleux ?
« Après, faut bien comprendre que du prefetch, c'est un truc standard : Apple et Intel le font, parce que c'est une voie intéressante, mais en interne c'est fait différemment. »
Différemment ? Pourtant Apple Mx et Intel Raptor Lake, même combat !
Un article expliquant ces subtilités ne serait point de trop il me semble…
😉
@Scooby-Doo
« Je le note, mais pourquoi la série Intel Raptor Lake qui ne partage pas son jeu d'instructions est impactée par la même faille ? »
Car depuis Spectre et Meltdown, les chercheurs « s’attaquent » à toutes les puces faisant de la prédiction de branchement et / ou du prefresh , en appliquant la même logique générale, car l’existence de risques et faiblesses lié à ces mécanismes est connue… indépendamment du jeu d’instruction.
En effet, on peut dire que depuis quelques années, une bonne part des failles touchant les mécanismes de prédiction de branchement et / ou du prefresh sont des dérivés / descendants spirituels de Spectre et Meltdown.
@benspx
A lire tout ce fil, on a l’impression que de toute façon, là où il y a de la prediction de branchements, il y aura tot ou tard une faille, non ?
@Bigdidou
C’est un mécanisme présent sur toutes les puces modernes ou presque, dont on sait maintenant qu’il est détournable, à minima sur les implémentations architecturales déjà en circulation.
Partant de là…
Par ailleurs, et de manière générale, tout est faillible, matériel comme logiciel. Rien ni personne ne peut se prétendre à l’abri d’une faille.
Partant de là…
;-)
@benspx
Partant de la, on se dit que la distinction machine perso/machine pro a enfin du sens ;)
À terme, il faudrait peut être bannir certaines options des processeurs/certains processeurs des serveurs en général et des machines dont les utilisateurs détiennent et utilisent des infos « sensibles » et peuvent être ciblés…. ?
Je comprends aussi mieux pourquoi des secteurs où la sécurité et la fiabilité sont essentielles utilisent des vieux machins alors qu’ils ont les moyens…
En tout cas, merci à tous ici pour vos commentaires aussi érudits que passionnants !
Comme quoi on peut sortir du clivage bas de gamme.
@Scooby-Doo
> "Ce qui est juste incroyable, c'est que les ingénieurs d'Apple n'en ont pas tenu compte lors de la conception du M1 !"
Incroyable ? Pourquoi ?
Il n’y a pas 36k solutions, et je trouve plutôt rassurant de savoir qu’Apple Silicon n’a pas inventé la panacée. Sinon, tout le reste de l’industrie serait mené par des incapables. Or, ce n’est pas le cas.
Malgré ce que les marketeux veulent faire croire, le développement a lieu dans une continuité conceptuelle. Continuité d’horizon, continuité de culture. Les paliers marquants du progrès technique ne correspondent pas nécessairement à l’étiquetage commercial.
Sur le fond, l’article de Chen et al. sur GoFetch se termine par une note assez réfrigérante : DMP présente un risque réel, il faudrait pouvoir le désactiver en soft, à la manière préfigurée par les extensions DOIT d’Intel.
Or, les risques liés à de nombreuses formes de prefetching ont été anticipés de longue date. J’ai souvenir d’un workshop d’il y a plus de 30 ans où Michael J. Flynn, qui dirigeait alors le Stanford Architecture and Arithmetic Group après son passage chez IBM, les désignait comme un fact of life, dont il faudrait peser le pour et le contre pour chaque catégorie d’application. Je ne sais pas s’il existe un compte-rendu, et je n’ai pas le temps de chercher, mais j’ai retrouvé un papier plus récent de son équipe, qui démontrait, pour une tâche beaucoup moins complexe mais plus courante — le traitement de MPEG — la viabilité du software prefetching par opposition au prefetch dédié en hardware, sur le processeur. Peut-être qu’il faudra un jour privilégier l’élégance conceptuelle et la réversibilité d’une solution en soft, même si beaucoup plus lente, par rapport à une course aux GHz qui entraîne des failles etched in stone.
https://citeseerx.ist.psu.edu/document?repid=rep1&type=pdf&doi=4831977f158c3627b66a2b736b6ea60e9267f1a3#:~:text=The%20earliest%20hardware%2Dprefetching%20work,his%20proposal%20for%20stream%20buffers.
@occam
"J’ai souvenir d’un workshop d’il y a plus de 30 ans où Michael J. Flynn, qui dirigeait alors le Stanford Architecture and Arithmetic Group"
————-
C’était avant ou après qu’il ait ouvert sa salle d’arcade ?
@MarcMame
😂 Flynn… 😂
Ou Clu 😏
@FrDakota,
Je vois que nous avons des connaisseurs de Tron sur ce forum !
👍
@occam,
« Incroyable ? Pourquoi ? Il n’y a pas 36k solutions, et je trouve plutôt rassurant de savoir qu’Apple Silicon n’a pas inventé la panacée. Sinon, tout le reste de l’industrie serait mené par des incapables. Or, ce n’est pas le cas. »
🙃
Négatif ! Obligé de vous contredire…
AMD a été peu impacté par les failles Spectre et Meltdown !
Seuls Intel et ARM l'ont été lourdement !
Comment expliquez-vous celà ?
😁
@Scooby-Doo
> "AMD a été peu impacté par les failles Spectre et Meltdown ! …
Comment expliquez-vous celà ?"
Je n’ai pas à l’expliquer, car c’est en grande partie inexact.
Les architectures AMD à partir de Athlon 64 et au moins jusqu’à Zen+ sont vulnérables à Spectre.
Seules exceptions à ma connaissance : Spectre-BTB-SA-OP et Spectre-BTB-CA-OP.
L’absence de vulnérabilité à Meltdown initialement rapportée a été infirmée : AMD est vulnérable au moins à Meltdown-BR ; fait connu depuis fin 2018.
Pour référence : le rapport de synthèse des équipes ayant dépisté ces failles, cf. Table 2 (Spectre), Table 5 (Meltdown), Table 6 (classification par attack flow) : https://arxiv.org/pdf/1811.05441.pdf
Fait notable, la microarchitecture Itanium 64 (Intel) n’est pas affectée par Meltdown ni Spectre, et ne peut en principe pas l’être, faute d’exécution spéculative. L’abandon d’Itanium est regrettable, et pas uniquement en raison de son immunité envers ce type d’attaque.
@occam,
👍
Merci pour avoir pris le temps de me répondre !
Donc à vous lire cette citation dans Wikipédia est fausse :
Selon une déclaration faite par AMD, la vulnérabilité à la seconde variante de Spectre n'a pas été montrée sur les processeurs AMD et le « risque d'exploitation [serait] quasi nul » en raison de différences dans l'architecture AMD.
Merci je le note !
Avec une quinzaine de variantes pour Spectre et pour Meltdown, j'ai parfois du mal suivre…
Mille excuses !
😉
« Fait notable, la microarchitecture Itanium 64 (Intel) n’est pas affectée par Meltdown ni Spectre, et ne peut en principe pas l’être, faute d’exécution spéculative. L’abandon d’Itanium est regrettable, et pas uniquement en raison de son immunité envers ce type d’attaque. »
Itanium c'était trop bien pour que cela prenne !
Le x86 avait la peau dure type crocodile ! C'est toujours le cas.
🤪
@Scooby-Doo
> "Avec une quinzaine de variantes pour Spectre et pour Meltdown, j'ai parfois du mal suivre…
Mille excuses !"
🤗 No problem !
C’est précisément la raison qui me fait garder en une base de données les publications d’origine sur ces sujets, les sources secondaires étant moins fiables. Quant à la déclaration d’AMD citée sur Wikipedia promettant un « risque (quasi) nul » en raison de l’architecture, c’est le type de situation où, très naïvement et sans mettre en cause leur bonne foi, je demande à voir. Toutes les fois qu’un acteur majeur a cru bon d’argumenter de cette façon, depuis plus de 40 ans que j’observe la scène, il s’est pris les pieds dans le tapis et le poing dans la gueule.
Un ingénieur bien plus chevronné que moi m’a appris à toujours garder à l’esprit cette scène de l’enquête sur l’explosion du Challenger, où une grosse pointure de la NASA explique devant la commission que la fiabilité du Shuttle est « necessarily 100%… minus ε… ».
« Sure sign of weaseling, » m’a dit mon mentor. « How big is ε ? If it’s measurable, they’re lying. And if they’re lying, it means they know. If they know, it’s bound to get out. It either pops up, or blows up. Who are they kidding ?»
Leçon jamais démentie.
C’est aussi pourquoi je suis de plus en plus sceptique face à ChatGPT, Gemini etc. en tant que source d’informations : dans les très rares et très étroits domaines que je connais à fond, et dans ceux encore plus minces où j’ai travaillé sur le fond, je peux en partie reconstruire le training set. Et sa qualité varie de médiocre à minable, avec une moyenne insuffisante. Les algorithmes ne me semblent pas en cause (pour autant que je puisse en juger, ce qui est peu dire), mais la qualité d’encadrement humain dans la supervision des training sets me paraît largement insuffisante, concernant la minuscule parcelle où je peux juger sur pièce.
@occam,
« Les algorithmes ne me semblent pas en cause (pour autant que je puisse en juger, ce qui est peu dire), mais la qualité d’encadrement humain dans la supervision des training sets me paraît largement insuffisante, concernant la minuscule parcelle où je peux juger sur pièce. »
👍
Ah mais j'approuve totalement ce que vous écrivez !
Le data set — ou training set comme vous dites — est primordial.
Les RNA fonctionnent plutôt bien ! Le problème c'est la ML et son data set qui font défaut !
Exemple qui me vient à l'esprit : Wikipédia qui a un nombre astronomique de contradictions intra-langue et inter-langue !
Une ML sur ce type de data set devient rapidement schizophréne il me semble !
👌
Exemple croustillant qui me vient à l'esprit :
Star wars > Genre !
En fonction de l'article sur Star wars, le genre sera soit :
- Science-fiction > Space opera (majoritaire)
Star wars épisode I et aussi pour les autres opus de la saga.
- Science-fiction > Space fantasy (minoritaire)
https://fr.m.wikipedia.org/wiki/Space_fantasy
https://fr.m.wikipedia.org/wiki/Star_Wars
On y perd son latin. Alors une pauvre IA innocente et décervelée j'ose même pas imaginer la situation !
🤪
A scooby :
Ah ouais …
Encore cette fameuse faille.
Merci de ton explication ! c’est fou que ça continue malgré le design, l’architecture etc
C’est à cause du DMA et de l’Europe.
@Teodorico
Exactement. Ça commence déjà !
@Teodorico
effectivement, les failles d’Apple sont de la faute de l’Europe et de sa réglementation sur le sexe des crevettes roses qui s’envolent comme des anges sous la forme de flamands.
@Patrick_C,
« effectivement, les failles d’Apple sont de la faute de l’Europe et de sa réglementation sur le sexe des crevettes roses qui s’envolent comme des anges sous la forme de flamands. »
👍
Une citation qui sera reprise par Tim Cook lors de sa prochaine keynote à n'en point douter !
😁
Cela devait arriver... Apple s'improvise concepteur de processeurs et se plante. En plus ce genre d'attaque sur les prédictions étaient déjà connues avec meltdown et spectre. Je peux mettre mon M1 à la poubelle.
@koko256
> "Je peux mettre mon M1 à la poubelle."
Recycle bin, vous voulez dire ?
@koko256
je suis preneur de l’adresse de votre poubelle.😏
@Patrick_C
Ma poubelle sera ma fille 😉
@koko256,
« Ma poubelle sera ma fille 😉 »
😁
Le commentaire le plus abominable lu depuis fort longtemps !
😂
@koko256
« ma plou belle sera ma fille » tu voulais dire?
@Patrick_C
Oui oui. C'est l'iPhone qui mal a corrigé.
@Patrick_C
Mon PC est aussi de la partie... je savais bien que j'avais une bonne raison de préférer AMD.
@koko256,
« Cela devait arriver... Apple s'improvise concepteur de processeurs et se plante. En plus ce genre d'attaque sur les prédictions étaient déjà connues avec meltdown et spectre. Je peux mettre mon M1 à la poubelle. »
🙃
Je peux vous prêter ma poubelle si vous le voulez !
Plus sérieusement, Apple va publier une mitigation.
Votre M1 fonctionnera toujours, moins rapidement certes, mais en toute sécurité !
Soyez juste un peu patient.
👌
Pages