Des chercheurs semblent avoir détecté une vulnérabilité assez importante dans les CPU modernes, qui ne concernerait, c'est encore spéculatif, que les ...
Lire la suite ...

Si je comprends bien le patch est software mais le bug est soft ou hardware?

Merci C_Wiz pour cet article, c'est très clair

Le bug est hardware. Cela dit, il semble que ce n'est pas vraiment un bug mais une vulnérabilité non anticipée.

Si AMD passe au travers leur cpu vont prendre un boost de compétitivité intéressant sur serveur.
 
Sympa comme nouvelle de début d'année pour AMD mais beaucoup moins sympa pour les gens qui gèrent un parc de bécanes Intel...

Article qui vient tôt et avec de la substance. Bravo.

[EDIT commentaire incorrect] Pour le coût du correctif, cf. le bug TLB chez AMD il y a quelques années.
 
Un mauvais point par contre pour la réutilisation directe du subscriber link de LWN, qui est certes reposté tel quel à travers tous les media. Mais sans en citer la source initiale (que je ne retrouve vraiment pas /o\).

merci pour cet article très intéressant. Je rejoins h3bus, je pense qu'il s'agit d'une vulnérabilité non anticipée plutôt qu'un bug

On sait si un patch est prévu pour Windows7, et pour quand?

Merci pour ce point sur la situation

Je suis probablement tombé sur ce lien dans les commentaires de Hacker News. Je vais le retirer du coup thx.

Dans l'article de the register, à la fin ils suggèrent que le même genre de patch serait appliqué à l'architecture ARM 64 bits.
 
EDIT: https://www.theregister.co.uk/2018/ [...] sign_flaw/

Ah donc du coup c'est déjà appliqué sur W10 ?

 
D’après la page Linux, la même approche est utilisée pour les architectures ARM-64:
http://lists.infradead.org/piperma [...] 42751.html

C'est juste un patch proposé de novembre qu'ils linkent, seuls les x86 ont le flag cpu_insecure actuellement il me semble avec le patch modifié et mergé ces derniers jours : https://git.kernel.org/pub/scm/linu [...] 7c8080a9bf

Je copie-colle mon précédent commentaire ici, vu que sa place y est davantage appropriée.
 
Bonne année !    
 
Une année qui s'annonce très mal pour Intel d'ailleurs, mais surtout pour les possesseurs de leurs processeurs, car en raison d'un correctif de sécurité imposé (pour une faille majeure présente dans les processeurs Intel sortis depuis plus de 10 ans), il va falloir s'attendre à d'importantes baisses de performances, ça va faire mal !  
 
Le noyau Linux a d'ores et déjà intégré le patch de sécurité, Microsoft est en train de l'intégrer à Windows. Dans le meilleur des cas, la perte de performances ne serait que de 17% sur une requête SQL SELECT. La baisse de performances attendue se situerait entre 5% et 30%, selon les usages.
 
Et comme par hasard, le PDG d'Intel vient de vendre plein de stock options.    
 
Les processeurs AMD ne seraient pas concernés (et le patch de sécurité à été adapté pour que leurs performances n'en souffrent pas).    
 

Tu auras la possibilité d'en rajouter un "respectueux" dans une semaine quand l'édition actuelle sera publique :-)
 
Et j'aurais pu envoyer un PM aussi.

Cf mon edit avec le commit en question (pour la question du patch ARM, sinon pour l'histoire de LWN oui ).

Il faut pas trop s’inquiéter, l'impact sur les perfs va être négligeable pour la plupart des utilisateurs.
La grande majorité des applications effectuent trop peu de syscall pour que cela ait un impact significatif sur les perfs.  
Les syscall étaient déjà une opération très couteuse en perf avant le patch, la plupart des applications (ainsi que les compilateurs) s'arrangent pour en faire le moins possible, et aux moments où cela impact le moins les perfs.
Phoronix a fait quelques tests sur des jeux, et l'impact sur les perfs est nul.
https://www.phoronix.com/scan.php?p [...] ming-Tests  
 
Cependant, comme mentionné dans l'article, sur les applications serveurs (virtualisation, SQL...) l'impact peut être important.  
Si AMD arrive à faire whiteliste ses processeurs, cela va certainement rendre les EPYC encore plus attractif pour le monde serveurs.

Je vous remercie vous HFR pour cet article superbement qualitatif. merci de ne pas avoir fait la même chose que les autres -"intel, un bug qui casse le perfs de 30%" sans explication.
 
Encore et toujours les meilleurs !

Et l'autre qui vient de vendre ses actions =)

 
+1 là on comprend déjà mieux même si ça reste compliqué vu la complexité de l'histoire en elle même quand on a des connaissances limités ^^

+1... c'est pas plus un bug que le soucis de sécurité WiFi d'il y a quelques semaines...

Bah d'ici en ARM 64, je pense que certaines implémentations pourraient être impactées... mais à voir si l'intérêt est là d'appliquer ça dans le noyaux Linux dans ces architectures sont quasi exploité que dans Android ou même iOS (car l'architecture la plus proche d'un CPU Desktop x86 reste celle d'Apple).

 
 
et concernant le problème de SGX même si en gros il n'y que POWERDVD en Bluray UHD qui s'en sert  et peut être d'autres logiciel:
 
https://www.theregister.co.uk/2017/ [...] ypto_keys/
 

bon le bug SGX à très certainement une porté extrêmement limité m'enfin ça commence à faire un beaucoup.
 
sans compté la désactivation de TSX, intel à énormément de bug Hardware dont beaucoup ne sont même pas patchable via mise à jour du micro-code.
 

 
il voulait peut être simplement acheter du bitcoin

lol

 
TSX est pas censé être fonctionnel sur les stepping plus récent de SKL ?
 
Après là le SGX c'est ballot comme soucis. Mais d'un côté, je pense qu'ils ne se sont jamais dit chez Intel que des mecs produiraient du code super spécifique pour péter le SGX comme il est implémenté dans SKL.
 
Le pb, je crois, de pas mal de système de protection, c'est de présumer qu'on est dans le cas idéal ou le code est malicieux mais ne sait pas sur quoi il est exécuté, et n'a donc pas d'attaquer spécifique au système.
 
C'est un peu comme quand le gouvernement fait un loi. Bah c'est comme-ci on pensait que de voter une loi suffisait à la faire appliquer dans son esprit sans que des petits malins trouve les failles pour la contourner.

Oui oui    
 
N'empêche sans blaguer, ça peut-être un putain de délit d'initié.

Encore faut il qu'il y ait un impact matériel sur le cours de l'action et qu'il ne puisse pas justifier pourquoi il a vendu.  
 
La SEC est excessivement pinailleuse sur le sujet aux Etats Unis, et la définition de l'insider trading est applicable a a peu près tout (cf la newsletter de Matt Levine). Mais les CEO à ce niveau sont aussi excessivement bien conseillés sur ce qu'ils peuvent faire et ne pas faire.

 
C'est un peu normal si c'est un bug qui touche le système mémoire. x264 tel qu'il est utilisé dans les bench est très peu dépendant des performances du système mémoire: il est souvent utilisé au minimum avec un profil "slow" qui implique donc une très grande profondeur de recherche et souvent avec une source déjà compressée. Mais avec un profil "ultrafast" avec une source raw non compressée, c'est plus la même chose. Là les performances du système mémoire dans son ensemble sont très importantes et même largement prépondérantes. Et d'ailleurs Intel prenait historiquement toujours un avantage très important pour ce type d'encodage face à AMD (cela correspond un peu par exemple à une première passe dans un encodage x264 en 2 passes).
 
Dans votre panel de test, s'il doit y avoir un impact, il sera peut-être plutôt sur 7zip ou WinRar.

 
x264 ou 7-Zip peuvent être très dépendant des perfs mémoires, mais je ne crois pas qu'ils font beaucoup de syscal (hormis pour les IO disques sans doute), du coup les perfs ne devrais pas être au niveau de Postgres avec entre 15 et 25% de pertes...

P*tain mais Intel les collectionne là, c'est pas possible !
Après les x failles touchant le ME, maintenant ça !
Tu m'étonnes que le PDG ait vendu un max d'actions...
 
En attendant vivement les benchs sur Windows (7), histoire de savoir à quelle sauce on va être mangé...

sauf que depuis trump, les agences federales sont décapitées et rien ne dit que la SEC fonctionne encore, le mec d'intel est ptet dans la confidence justement

 
Alors dans le cas de SGX, il ne s'agit effectivement pas d'un bug.
Intel indique explicitement que les 'side channels attacks' (comme les attaques par le cache ici décrites) ne font pas partie du 'threat model' de SGX et il s'agit du boulot du dev de s'assure que des informations ne leakent pas de la sorte (il faut utiliser de la crypto en temps constant, par exemple).
SGX ne souffre pas d'une faille de sécurité, il s'agit plus d'une déficience inhérente à ce genre de technologies, due a l'absence de séparation physique des composants (RAM, caches CPUs) utilisés pour les applis 'sécurisées' et pour les applis 'classiques'.
Je vous invite à consulter cette vidéo: https://media.ccc.de/v/34c3-8950-mi [...] vironments pour en savoir plus.
 

Bon bah, faudra refaire tous les benchamrks sur CPU Intel des dernières années.  
Bon courage Guillaume !

 
J'aimerai trop que AMD repasse devant pour les 10 dernières années  .
En fait on était supérieurs ... mais personne ne le savait .

SGX... Est-ce que c'est ça qu'Apple appelle la "secure enclave" (la puce / l'emplacement où sont stockées les empreintes digitales ou faciales) ? Y a-t-il une relation, même lointaine, entre les deux ?

ça changerai pas grand chose question chiffre d'affaire pas contre et ça c'est moinds drôle

N'empêche, si c'est long et dur à patcher pour des projets bien staffés comme Linux, MacOs X et Windows qu'est ce que ça doit être pour des trucs plus confidentiels comme HURD ou Haiku.