Reprise du message précédent :

Regarde mon message plus haut. ARM est impacté par Meltdown également sur certains CPU... dont la variante originale de celui qui se trouve dans mon smartphone malheureusement

Jusqu'à présent le user voulais des perfs et à faible coût (W, mm², €).
 
Du coup là peut-être que oui les design vont un peu changer, et vu qu'on a pas mal de reserve de perfs par rapport à l'usage moyen des utilisateurs, ça ne sera sans doute pas si grave.
 
Après comme dit, là, la faille on savait (enfin "on" = designer de CPU et tout le microcosme autour) qu'elle était potentiellement là. Donc ça ne change pas grand chose à part dire " oh putain là faudrait quand même faire quelque chose, parce qu'on a réussi à la faire ! " ... après j'emet quand même le doute sur la faisabilité d'exploiter cette faille pour réellement accéder à des infos sensible d'un utilisateur en fait...

là vous avez un bon résumé si ce n'est déjà posté
https://spectreattack.com/
 
et l'avis tranché de Linus
https://lkml.org/lkml/2018/1/3/797

En attendant, perte de perf ou pas, je viens de mettre a jour l'esxi 6.5 de mon nas avec le patch qui va bien (esxi-6.5.0-20171201001s-standard).  
Je verrais rapidement sur centreon si grosse perte de perf il y a...

C'est même pas tellement étonnant ... l'OOO, la prédiction de branchement & co, ça a toujours été pensé pour maximiser les perfs, donc quitte à implémenter ça, autant le faire de la manière la plus efficiente possible.

Ouais c'est les chinois qui vont le faire

Du coté des connexions 2G/3G, il y a le même genre d'exemple. On sait depuis 2005 via une POC que l'algo Kasumi (A5/3) qui est massivement utilisé par les fabricants/opérateurs est contournable moyennant une puissance de calcul considérable et qu'à terme cela arrivera (via optimisation du calcul ou augmentation de la puissance de calcul brute)

Tout cela reste des risques "calculés" si on peut dire...

Ok merci, donc l'info initiale qui circulait avec le "à partir de 2008" n'était pas correcte
 
Tout le monde dans le même panier

normalement avec leur sme amd devrait être quasi immunisé, non ?
tu peux avoir accès aux données certes mais des données cryptées, donc à moins d'avoir les clés, tu peux rien en faire
bon maintenant faut déployer ce sme et sur une infra cloud ça peut coûter bonbon

un test pour détecter certains cas (ou tous, j'ai la flemme de tout lire ) du bug

https://www.reddit.com/r/Amd/commen [...] t_whether/

sur mon 1950x

Speculation control settings for CVE-2017-5715 [branch target injection]

Hardware support for branch target injection mitigation is present: False
Windows OS support for branch target injection mitigation is present: False
Windows OS support for branch target injection mitigation is enabled: False

Speculation control settings for CVE-2017-5754 [rogue data cache load]

Hardware requires kernel VA shadowing: False

BTIHardwarePresent             : False
BTIWindowsSupportPresent       : False
BTIWindowsSupportEnabled       : False
BTIDisabledBySystemPolicy      : False
BTIDisabledByNoHardwareSupport : False
KVAShadowRequired              : False
KVAShadowWindowsSupportPresent : False
KVAShadowWindowsSupportEnabled : False
KVAShadowPcidEnabled           : False

edit : commandes à taper si besoin
Set-ExecutionPolicy  -ExecutionPolicy RemoteSigned -scope Process (comme ça vous ne modifiez que pour la session)
Install-Module SpeculationControl
Import-Module SpeculationControl
Get-SpeculationControlSettings
Get-InstalledModule -Name SpeculationControl | Uninstall-Module (pour désinstaller le module si vous n'en voulez plus, comme moi)

Certes, mais chez AMD et ARM, il est plus facile de penser que les personnes compétentes soient encore en place et capables de proposer des vrais solutions propres à ces "failles".
 
Après, y'a Linus : https://lkml.org/lkml/2018/1/3/797

Super mogana, merci !
 
sur mon dell xps 15 du taf, processeur core I7 6700HQ type skylake sur windows 10 pro uptodate (mais pas avec le fameux patch) :
 
Speculation control settings for CVE-2017-5715 [branch target injection]
 
Hardware support for branch target injection mitigation is present: True
Windows OS support for branch target injection mitigation is present: True
Windows OS support for branch target injection mitigation is enabled: True
 
Speculation control settings for CVE-2017-5754 [rogue data cache load]
 
Hardware requires kernel VA shadowing: True
Windows OS support for kernel VA shadow is present: True
Windows OS support for kernel VA shadow is enabled: True
Windows OS support for PCID optimization is enabled: True
 
 
BTIHardwarePresent             : True
BTIWindowsSupportPresent       : True
BTIWindowsSupportEnabled       : True
BTIDisabledBySystemPolicy      : False
BTIDisabledByNoHardwareSupport : False
KVAShadowRequired              : True
KVAShadowWindowsSupportPresent : True
KVAShadowWindowsSupportEnabled : True
KVAShadowPcidEnabled           : True
 
je crois qu'on peut dire que c'est le caca

Ça ne colle pas du tout avec https://www.reddit.com/r/Amd/commen [...] r/ds6afki/
Pour avoir des "True" partout, il faut normalement :
 - avoir la mise à jour
 - un nouveau microcode Intel (à priori pas dans la mise à jour sinon Microsoft ne parlerait pas du besoin d'avoir des mises à jour de firmware) pour BTIHardwarePresent

En attendant, les "ARM64 people" ont fait la même erreur sur leurs derniers CPU... donc la lumière divine ne viendra pas de leur coté non plus...
A part faire du trolling, je ne vois pas en quoi un ingénieur Intel serait moins compétant qu'un ingé AMD ou ARM...

 
pour toi, moi ça va
je plaisante bien évidemment et je compatis, mais je pense pas que pour le desktop ce soit un problème mais qui sait

@HWTI : que veux tu que je te dise, j'ai suivi les instructions et exécuté le powershell en question, ce que j'ai mis n'est que le copié/collé du resultat d'exécution dans la fenêtre powershell....

 
vu que c'est connu depuis juin, n'est ce pas possible que ça ait été déployé depuis longtemps discrètement pour permettre une maj massive des os

heuuuu, regarde qui tu quotes ! TNZ aka l'homme le moins objectif du monde vis a vis d'intel et windows

Avec un Haswell et Windows 10 1709 a jour ça donne ça :

 
Mais pas forcement dernier uCode à jour car laptop chinois avec MAJ BIOS aléatoire, mais dernier ME 1,5M à jour.

je confirme que mon CPU est bien un I7 6700HQ type skylake avec un windows 10 entreprise (je pensais pro, mon mauvais) en version 1709, OS Build 16299.192 (patché hier), dernier bios Dell xps 15 à jour ....

 
Là ça serait plutôt, à partir de 1998  

 
C'est ce que j'ai sur un Sandy Bridge-E non à jour (Windows 10 1709 build 16299.125).
Normalement avec la mise à jour (build 16299.192), tu devrais avoir "Windows OS support for branch target injection mitigation is present", "Windows OS support for kernel VA shadow is present" et "Windows OS support for kernel VA shadow is enabled" à "True" quel que soit le microcode.
 

Donc il est à jour, que voulais-tu dire par "mais pas avec le fameux patch" ?
Tu peux regarder la version du microcode ? Avec cpu-z par exemple.

Le patch n'a été déployé que pour les abonnés au programme Windows Insider pour le moment, ne vous emballez pas

j'ai lu que les AMD FX n'étaient pas touché par la faille !!!!
 
mais qu'en est il de spectre !!!?

 
je pensais que le patch correctif n'etait distribué qu'a compter de mardi prochain....
 
oui, voilà le résultat ci-dessous :  
 
Processor 1   ID = 0
 Number of cores  4 (max 4)
 Number of threads 8 (max 8)
 Name   Intel Core i7 6700HQ
 Codename  Skylake
 Specification  Intel(R) Core(TM) i7-6700HQ CPU @ 2.60GHz
 Package (platform ID) Socket 1440 FCBGA (0x5)
 CPUID   6.E.3
 Extended CPUID  6.5E
 Core Stepping  R0
 Technology  14 nm
 TDP Limit  45.0 Watts
 Tjmax   100.0 °C
 Core Speed  3091.7 MHz
 Multiplier x Bus Speed 31.0 x 99.7 MHz
 Stock frequency  2600 MHz
 Instructions sets MMX, SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, EM64T, AES, AVX, AVX2, FMA3, TSX
 L1 Data cache  4 x 32 KBytes, 8-way set associative, 64-byte line size
 L1 Instruction cache 4 x 32 KBytes, 8-way set associative, 64-byte line size
 L2 cache  4 x 256 KBytes, 4-way set associative, 64-byte line size
 L3 cache  6 MBytes, 12-way set associative, 64-byte line size
 FID/VID Control  yes
        Microcode
 
Rev. 0x00000C2
 

Pour savoir si mes ID Youpr0n cat granny vont bientôt tourner sur la toile

Le powerscript cité plus haut est probablement peu fiable, non?    
 
Sinon, je viens de lire çà (commentaire 4):
https://www.phoronix.com/forums/for [...] e-meltdown

 
D'après ce que je comprends (cad pas grand chose) du schéma d'attaque, on risque plus sur Intel que sur AMD pour Spectre (AMD n'étant pas à priori pas affecté par Meltdown qui est adressé par KPTI); parce que sur AMD, on ne peut déchiffrer que la mémoire du process exécutant Spectre, alors que sur Intel, ça va plus loin...
 
Il me semble qu'il reste tout de même un risque énorme sur AMD; javascript exécuté par un browser par exemple, non ?
 
Je me demande vraiment si la sécurisation ne nécessitera pas 3 niveaux de patchs: microcode, kernel et compilateurs (binaires)  

voire 4 avec la MAJ des navigateurs pour les failles JS: Chrome et Firefox préparent des MAJ aussi.
 
la MAJ Windows est prévue pour le 9 janvier, mais requiert parfois des MAJ des AV au préalable.
https://support.microsoft.com/en-us [...] s-released
 

C'est vrai, les devs applicatifs devront tenir compte de çà à l'avenir    
 
javascript, la plaie du XXI°   (même si tous mes micros tournent sous fedora -> gnome-shell)

Bah non c'est typiquement le genre de faille qui ne concerne pas les développeurs d'application.
 
Ca ne concerne quasi exclusivement que les développeur des noyaux d'OS et de microprocesseurs.

Pas trop d'accord avec toi. C'est possible de restreindre au niveau appli ce que peut faire le JS. Amha, c'est l'un des plus gros vecteur d'attaque sur nos plate-formes privées... Si par dessus le marché le JS permet d'exploiter des failles HW via le software qui l'exécute (browser, par exemple), ben  
 
Edit: et franchement "Spectre" ne semble pas lié à un "bug" hardware: plutôt à une "faille" de l'architecture

Quelqu'un qui fait un environnement d’exécution pour les langages avec un bytecode non lié à l'architecture d’exécution, forcement aura les mêmes contraintes qu'un dev de noyau / CPU.

T'as pas lu l'article de CanardPC précédant la sortie des Ryzen ...

CQFD, donc

Il me semble que dans ce même CanardPC, DocTB indiquait en avant première les capacités d'OC de ryzen, 5GHz... on connaît la suite.

comme je le pensais, sur desktop, ras
 
https://www.youtube.com/watch?v=_qZ [...] e=youtu.be

sous Linux.
 
en pratique sous Windows on ne sait même pas si l'impact est autant marqué même en usage DBMS.

Concrètement:
-Suis-je concerné par ce probleme avec mes 4 i7 4770K un i7 2680qm et un ryzen 1800x?  
-Seul les Datacenter sont-ils impactés ou les personnes qui comme moi utilisent mes processeurs pour faire du rendu Vray par exemple et jouer à des triple A?
 
Les rares benchmarks ne m'éclairent pas la dessus. :-(
Merci d'avance pour vos réponses!

Tout le monde quasi est concerné (plus ou moins) par ce pb. Sauf qu'on a des correctifs que pour le pb qui concerne seulement Intel en x86.
 
L'impact sera là, mais relativement modéré voir nul. Parce que bon, même les benchmarks qui montre du Postgres Linux @ 25% moins perf, je pense qu'ils ne sont pas réaliste d'un usage normal d'un DBMS, puisque normalement tu fais le moins d'IO possible quand même hein...

 
C'est bien un nouveau microcode, le dernier était le 0xBA (2017-04-09), diffusé par Intel pour Linux dans le paquet "20170511".