[HFR] Actu : Microsoft désactive la protection Spectre v2

Actu : Microsoft désactive la protection Spectre v2 [HFR] - HFR - Hardware

Marsh Posté le 30-01-2018 à 16:59:59   0  

Après de nombreux OEM, Microsoft s'est également décidé a désactiver son patch pour la faille Spectre (Variante 2) suite aux problèmes de plantages notés avec ...
Lire la suite ...

Reply

Marsh Posté le 30-01-2018 à 16:59:59   

Reply

Marsh Posté le 30-01-2018 à 17:00:00   2  

on a pas fini d'entendre parle de ces failles qui touchent à la conception même des processeurs x86.

Reply

Marsh Posté le 30-01-2018 à 17:04:51   4  

Et après on me jette des pierres quand je dis qu'Intel ne dispose plus des "sachants" ....  
[:spamafote]


---------------
"Mieux vaut demander à un qui sait plutôt qu'à deux qui cherchent." ... "Le plus dur, c'est de faire simple.", TNZ
Reply

Marsh Posté le 30-01-2018 à 17:14:55   4  

quel bazar ! dans le genre super mauvaise gestion de crise j'ai demandé Intel !..... je trouve ca ahurissant de nullité leur facon de gérer toute cette affaire.... franchement, ils sont vraiment en dessous de ce que l'on peut attendre d'eux.

Reply

Marsh Posté le 30-01-2018 à 17:25:24   1  

Pour ma part pas de soucis avec un i7-6700K avec Bios à jour (Asus Z170 Deluxe - 3703) et Win 10 à jour.
 
Quelqu'un a eu des soucis de stabilité parmi les lecteurs de Hardware.fr ?

Reply

Marsh Posté le 30-01-2018 à 17:26:47   0  

Citation :

les processeurs Skylake (et dérivés) qui ont un mode de fonctionnement différent dans leur spéculation d'exécution par rapport aux architectures Intel précédentes..


Quelqu'un pourrait nous éclairer sur cette partie ?
Et par dérivés, ils parlent de tous les processeurs sorties depuis Skylake ? Coffee Lake est donc aussi touché ?

Reply

Marsh Posté le 30-01-2018 à 18:03:47   0  

pkoka a écrit :


Quelqu'un pourrait nous éclairer sur cette partie ?
Et par dérivés, ils parlent de tous les processeurs sorties depuis Skylake ? Coffee Lake est donc aussi touché ?


 
On en a parlé sur d'autres threads il me semble, pour faire simple, Spectre V2 repose sur la manière dont les processeurs spéculent dans leur exécution d'instruction. Plus précisément, Spectre V2 joue sur la manière dont les processeurs spéculent sur le retour des fonctions.
 
retpoline (voir là https://support.google.com/faqs/answer/7625886 ) est un mécanisme (return trampoline) qui tente d'isoler les endroits exploitables au niveau du compilateur pour faire court.
 
Le problème de Skylake est qu'ils spéculent différemment sur les retours de fonction avec des mécanismes plus "évolués", qui font que retpoline semble exploitable sur Skylake. C'est le consensus dans le monde Linux (qui est le seul ou cela parle vraiment parler ouvertement, c'est les employés d'Intel qui ont indiqué dès le début que retpoline ne suffirait pas pour Skylake+) : https://lkml.org/lkml/2018/1/4/708  
 
Il y a des messages plus récents ou ils expliquent plus en détail pourquoi retpoline est insuffisant sur Skylake mais je ne les ai pas sous le coude.  
 
Et oui tous les dérivés de Skylake sont concernés, c'est la même architecture (donc Kaby Lake et Coffee Lake, et probablement les -X aussi même si pas vu de confirmation).


Message édité par C_Wiz le 30-01-2018 à 18:20:17
Reply

Marsh Posté le 30-01-2018 à 23:24:41   0  

worm'skiller a écrit :

on a pas fini d'entendre parle de ces failles qui touchent à la conception même des processeurs x86.


Pas que, des CPUs avec d'autres archis que x86 (arm par exemple) sont également touchés.

Reply

Marsh Posté le 31-01-2018 à 01:21:23   0  

Je suis pas prêt d'avoir un BIOS pour mon vieux i7-3770K "Ivy Bridge"... et pourtant j'utilise une carte mère Intel, modèle DZ77GA-70K. C'est la poisse...
Intel pouvait exceptionnellement, et malgré la période de support technique dépassée, pousser un BIOS corrigé. Même avec les fameuses failles du Management Engine dévoilées les années précédentes ils n'avaient pas bougé. Première et dernière fois en carte mère Intel.

Reply

Marsh Posté le 31-01-2018 à 08:12:20   0  


Ce n'est pas limité aux cartes intel. Hélas...

Reply

Marsh Posté le 31-01-2018 à 08:12:20   

Reply

Marsh Posté le 31-01-2018 à 08:29:20   0  

Qu'en est-il des microcodes AMD? Ils parlaient de mi-janvier mais je n'ai pas vu de nouvelles depuis. Ils ont été mis en place chez des partenaires ?


---------------
CPU: 5960X 4.4Ghz (Uncore: 4.0Ghz) WC HM -- Mem: 4x4Go 3200Mhz 15-16-16-32-2T -- Mobo: Asus X99 Deluxe -- GPU: 1080Ti (GPU: 2000Mhz, VRAM: 5900Mhz) -- Carte Son: X-Fi Titanium Fatal1ty Professional -- SSD: M.2 PCIE XP941 -- Ecran: Asus ROG Swift PG278Q
Reply

Marsh Posté le 31-01-2018 à 09:20:08   1  

La mise à jour se contente de créer deux clés de registre qui remettent Spectre à "no" pour les tests Steve Gibson et AShampoo. Discipliné, bien que n'ayant aucun problème de stabilité avec mon i7-6700K/Asus Z170 deluxe j'ai effectué cette MAJ Microsoft. Je me contenterai de dire "quel bordel !"

Reply

Marsh Posté le 31-01-2018 à 09:42:13   0  

On peut apprécier le professionnalisme de Intel et Microsoft qui ont pour le premier fourni un Microcode totalement buggé et qui finalement ne sert à rien et pour le second fourni une mise à jour qu'il doit désactiver en catastrophe via une énième mise à jour ....
 
Une pensée pour ceux qui ont fait la mise à jour du bios de la carte mère et dont le PC plante sans arrêt après ça ...

Reply

Marsh Posté le 31-01-2018 à 09:52:29   0  

S'il y avait que les PC perso ... en ce moment, c'est la panique dans les datacenters.


---------------
"Mieux vaut demander à un qui sait plutôt qu'à deux qui cherchent." ... "Le plus dur, c'est de faire simple.", TNZ
Reply

Marsh Posté le 31-01-2018 à 09:53:02   0  

djayse a écrit :

On peut apprécier le professionnalisme de Intel et Microsoft qui ont pour le premier fourni un Microcode totalement buggé et qui finalement ne sert à rien et pour le second fourni une mise à jour qu'il doit désactiver en catastrophe via une énième mise à jour ....
 
Une pensée pour ceux qui ont fait la mise à jour du bios de la carte mère et dont le PC plante sans arrêt après ça ...


vu la merde que c'est j'ai juste fait le KB pour meltdown sur le fixe est le portable est c'est tout le reste wait and see, pas envie justement de me trouvé avec 2 PC plein de bug à devoir reinstall
le bios du fixe pas concerné y à plus de mise à jour dessus depuis fin 2015 du côté de gigabyte (à part des versions support pour broadwell mais je m'en cogne)   :sarcastic:  
 


---------------
"Toute voiture restant en un morceau pendant plus d'une course est trop lourde"  
Reply

Marsh Posté le 31-01-2018 à 10:18:05   0  

bidonSystem a écrit :

Je suis pas prêt d'avoir un BIOS pour mon vieux i7-3770K "Ivy Bridge"... et pourtant j'utilise une carte mère Intel, modèle DZ77GA-70K. C'est la poisse...
Intel pouvait exceptionnellement, et malgré la période de support technique dépassée, pousser un BIOS corrigé. Même avec les fameuses failles du Management Engine dévoilées les années précédentes ils n'avaient pas bougé. Première et dernière fois en carte mère Intel.


 
donc en proc intel aussi alors?

Reply

Marsh Posté le 31-01-2018 à 10:19:39   1  

icetdrinker a écrit :

Pour ma part pas de soucis avec un i7-6700K avec Bios à jour (Asus Z170 Deluxe - 3703) et Win 10 à jour.
 
Quelqu'un a eu des soucis de stabilité parmi les lecteurs de Hardware.fr ?

Rien qu'un BSOD environ toutes les 48h, et ce depuis les dernières mises à jour...  :fou:  
Alors que je n'en avais eu qu'un ou deux sur les 4 ans de mon laptop.

Reply

Marsh Posté le 31-01-2018 à 10:51:45   0  

pas de bol a écrit :

Rien qu'un BSOD environ toutes les 48h, et ce depuis les dernières mises à jour...  :fou:  
Alors que je n'en avais eu qu'un ou deux sur les 4 ans de mon laptop.


 
Je suis dans le même cas qu'Icetdrinker. En presque trois semaines d'utilisation pas un crash ou BSOD...
Cela dépend vraiment des systèmes visiblement...


---------------
CPU: 5960X 4.4Ghz (Uncore: 4.0Ghz) WC HM -- Mem: 4x4Go 3200Mhz 15-16-16-32-2T -- Mobo: Asus X99 Deluxe -- GPU: 1080Ti (GPU: 2000Mhz, VRAM: 5900Mhz) -- Carte Son: X-Fi Titanium Fatal1ty Professional -- SSD: M.2 PCIE XP941 -- Ecran: Asus ROG Swift PG278Q
Reply

Marsh Posté le 31-01-2018 à 11:18:57   0  

Aucun soucis sur le fixe (haswell) mais problème d'exctinction et d'allumage de temps en temps (1 fois sur 2/3) depuis la maj sur le portable (broadwell) 'fin rien de dramatique par rapport a certains  
Les deux en w10 64 mais le fixe en version pro le portable famille (écran tactille pivotable et mode tablette)  


---------------
"Toute voiture restant en un morceau pendant plus d'une course est trop lourde"  
Reply

Marsh Posté le 31-01-2018 à 11:54:37   0  

Rien à signaler sur un i7 8700K et une MSI Krait. Ca a l'air assez random comme truc, ce qui me semble complètement incompréhensible.

Reply

Marsh Posté le 31-01-2018 à 12:44:25   0  

Mon avis est simple : côté intel, il n'y a pas de solution si ce n'est proposer du nouveau matériel.
En vérité, il y a tant de failles, hormis ces deux là, qui peuvent impacter les utilisateurs (dont de plus en plus d'arnaques aux boites courriels), que franchement c'est en effet surtout au utilisateurs et revendeurs de logiciels de faire attention. Est ce la faut à Intel si on exécute un virus sur son ordinateur capable de faire griller le processeur ?
Si c'était le cas, on aurait plus de processeurs overclockable à la vente et cela ferait des malheureux. (dont l'impression de "peut être" avoir un peu plus que ce pour quoi on a payé)
Le mieux reste, dans cette affaire, de faire comme microsoft le propose : de bloquer les possibilité de façon logicielle.
Certains se rappellent sans doute d'une époque où, avec microsoft office, on pouvait avoir des powerpoint ou fichier excel ayant du code VB malicieux s'exécutant automatiquement et pouvant endommager certaines choses ?
Résultat, microsoft propose depuis 2003 il me semble une version d'office qui bloque automatiquement les code automatique, sauf si l'utilisateur l'autorise spécifiquement.

Reply

Marsh Posté le 31-01-2018 à 12:45:12   0  

Pareille pas de problème jusqu'ici avec la dernière MAJ Gygabite (alpha). j'ai vue qu'il avais sortie la MAJ en beta mais en attendant qu'ils soient un peu plus sur cher Intel je vais en rester à ces MAJ.

Reply

Marsh Posté le 31-01-2018 à 12:55:01   0  

Heureusement qu'ils ont eu 6 mois pour bosser sur les patchs.... :d


---------------
Sympathy for the devil
Reply

Marsh Posté le 31-01-2018 à 12:56:17   0  

Noim a écrit :

Rien à signaler sur un i7 8700K et une MSI Krait. Ca a l'air assez random comme truc, ce qui me semble complètement incompréhensible.


c'est random comme le mode de fonctionnement des procs, ont peut pensé que comme chaque procs fait ces propres spéculation forcement les résultats sont pas toujours strictement identiques car chaque machine n'a pas exactement les mêmes ressources à exloiotées ni les mêmes choses à exécutés à l'instant T, sans compter les divers modification du registre du moins je le conçoit comme ça, j'ai bon ou pas  :??:  
peut être aussi pour ça que c'est autant la merde à gérer ce genre de souci, pour un peu que ce soit lié au prefecht pour être encore plus précis ou une autre connerie du genre ça te fait autant de disparitées que de personnes qui utilise un ordi  :pt1cable:


---------------
"Toute voiture restant en un morceau pendant plus d'une course est trop lourde"  
Reply

Marsh Posté le 31-01-2018 à 13:26:59   0  

pas de bol a écrit :

Rien qu'un BSOD environ toutes les 48h, et ce depuis les dernières mises à jour...  :fou:  
Alors que je n'en avais eu qu'un ou deux sur les 4 ans de mon laptop.


 
Pas de chance :/ J'ai un OC léger qui tourne peut-être que des OCs plus violents jouent ? La RAM etc...
 
Vivement que l'industrie décide de mettre la sécurité au coeur de leur design plutôt que d'économiser en transistor pour avoir ce genre de merdes...
 
Peut-être une nouvelle archi ?

Reply

Marsh Posté le 31-01-2018 à 13:50:58   0  

drynek a écrit :


c'est random comme le mode de fonctionnement des procs, ont peut pensé que comme chaque procs fait ces propres spéculation forcement les résultats sont pas toujours strictement identiques car chaque machine n'a pas exactement les mêmes ressources à exloiotées ni les mêmes choses à exécutés à l'instant T, sans compter les divers modification du registre du moins je le conçoit comme ça, j'ai bon ou pas  :??:  
peut être aussi pour ça que c'est autant la merde à gérer ce genre de souci, pour un peu que ce soit lié au prefecht pour être encore plus précis ou une autre connerie du genre ça te fait autant de disparitées que de personnes qui utilise un ordi  :pt1cable:


Non.

Reply

Marsh Posté le 31-01-2018 à 13:55:47   0  

pas de bol a écrit :

Rien qu'un BSOD environ toutes les 48h, et ce depuis les dernières mises à jour...  :fou:  
Alors que je n'en avais eu qu'un ou deux sur les 4 ans de mon laptop.


 
faire des sauvegardes de son système régulièrement
une image disque ou un clonage, et fini les problèmes!

Reply

Marsh Posté le 31-01-2018 à 14:52:11   1  

C_Wiz a écrit :

Plus précisément, Spectre V2 joue sur la manière dont les processeurs spéculent sur le retour des fonctions.


Non, dont les processeurs spéculent sur les *appels* de fonction, et les retours en plus pour Skylake+.
 

C_Wiz a écrit :

retpoline (voir là https://support.google.com/faqs/answer/7625886 ) est un mécanisme (return trampoline) qui tente d'isoler les endroits exploitables au niveau du compilateur pour faire court.


Car avant Skylake, les retours n'étaient pas spéculés, empêchant la fuite d'information et donc la faille spectre. En gros, retpoline transforme les appels à des fonctions privilégiées en retour de fonction (en faisant un faux appel, en changeant l'adresse de retour, puis en faisant un retour), qui ne seront pas spéculés.
 
Pour faire simple, car en plus un trampoline c'est un appel dont la destination n'est pas connue au chargement du programme, mais seulement résolu lors du premier appel, qui patch le trampoline une fois exécuté la première fois pour le transformer en appel simple.
 

C_Wiz a écrit :

Le problème de Skylake est qu'ils spéculent différemment sur les retours de fonction avec des mécanismes plus "évolués", qui font que retpoline semble exploitable sur Skylake.


Oui, Skylake et suivants sont plus évolués et savent spéculer les retours, d'où le contournement par retpoline qui ne sert à rien car le CPU sait spéculer, et donc potentiellement révéler de l'information privilégiée.
 
Bref, Skylake étant encore plus « intelligent », il est encore plus sensible à la faille spectre. Seuls évitent la faille les CPU « bêtes », et donc moins rapides, et c'est assez emmerdant à résoudre du coup…

Reply

Marsh Posté le 31-01-2018 à 15:28:50   1  


c'est un peu short je suis pas mieux avancé  :o  


---------------
"Toute voiture restant en un morceau pendant plus d'une course est trop lourde"  
Reply

Marsh Posté le 31-01-2018 à 15:34:34   0  

L'informatique c'est déterministe, si ça se comporte d'une façon dans une machine, ça fera pareil dans une autre. Un processeur a un microcode précis, il ne fait pas (encore ?) d'intelligence artificielle à sa sauce qui pourrait varier d'une machine à l'autre. (même si certains commencent à parler de "réseaux de neurone" dans le CPU)

Message cité 1 fois
Message édité par Flyman81 le 31-01-2018 à 15:34:51
Reply

Marsh Posté le 31-01-2018 à 15:57:38   0  

Flyman81 a écrit :

L'informatique c'est déterministe, si ça se comporte d'une façon dans une machine, ça fera pareil dans une autre. Un processeur a un microcode précis, il ne fait pas (encore ?) d'intelligence artificielle à sa sauce qui pourrait varier d'une machine à l'autre. (même si certains commencent à parler de "réseaux de neurone" dans le CPU)


et pourtant 2 ordis a priori identiques n'utiliserons pas les mêmes ressources au même moment suivant l'utilisateur ça ont le sait depuis le prefetch si c'est pas de l'apprentissage faut redéfinir le terme
donc les procs tournent tous pareil et sont "con" mais pas avec la mêmes choses à manger donc le soucis vient de l'OS pour les soucis random si je suis le raisonnement qui lui devient de plus en plus intrusif et intelligent à mesure des évolutions
 


---------------
"Toute voiture restant en un morceau pendant plus d'une course est trop lourde"  
Reply

Marsh Posté le 31-01-2018 à 16:02:58   0  

Le random ça reste statistique, si ça arrive sur une conf, il est très probable que ça finisse par arriver sur une autre.  
 
Bref c'est une piste intéressante mais à mon avis les différences sont à chercher ailleurs ;) (modèle de CPU, version de microcode, etc.)

Reply

Marsh Posté le 31-01-2018 à 16:06:36   0  

benoar a écrit :


Non, dont les processeurs spéculent sur les *appels* de fonction, et les retours en plus pour Skylake+.
 


 
C'est très intéressant, merci pour tous ces détails et explications  :jap:
 
Mais je n'arrive pas à comprendre la subtilité entre la spéculation sur les appels de fonctions et celle sur les retours de celles-ci.
 
Parce que l'objet d'une fonction sera (grossièrement) de faire un traitement, le résultat de celui-ci étant ce qui nous importe et sujet à stockage (criticité potentielle de l'information en résultant).
 
On pourrait ainsi très naïvement résumer un "appel" de fonction à son "retour" (même si les adresses ne sont pas les mêmes en mémoire) : quelle différence y-a-t'il entre ces deux types de spéculations, donc ?
 
BONUS : la seconde (spéculation sur les retours de fonctions) est-elle possible et / ou pertinente sans la première (spéculation sur l'appel de fonctions) ?
 
Si l'on pouvait m'éclairer, ça m'intrigue vraiment.
 
Merci  ;)

Reply

Marsh Posté le 31-01-2018 à 17:08:57   0  

dextrogyre a écrit :

le résultat de celui-ci étant ce qui nous importe et sujet à stockage (criticité potentielle de l'information en résultant).


Non, justement, dans le cas de Spectre la fonction n'est jamais exécutée du point de vue du processus appelant, puisqu'il n'a pas les privilèges nécessaires (dans le cas d'appels qui veulent exploiter la faille). Donc aucune influence du « retour » potentiel de cette fonction.
 

dextrogyre a écrit :

BONUS : la seconde (spéculation sur les retours de fonctions) est-elle possible et / ou pertinente sans la première (spéculation sur l'appel de fonctions) ?


Spéculer sur les retours, c'est juste une optimisation pour aller plus vite. Avec ou sans optimisation de l'appel, on s'en fout un peu, à la base ces mécanismes sont simplement pour aller plus vite globalement.
 
C'est juste qu'un contournement « simple » de Spectre niveau soft pour mettre tout le monde au même niveau (= pas optimisé) était d'utiliser un retpoline, mais que sur Skylake bah ça ne permet pas d'éviter la faille.

Reply

Marsh Posté le 31-01-2018 à 17:48:07   1  

C'est bien la prédiction des retours, précisément de l'instruction x86 RET, et la manière dont ça diffère qui joue, oui.  
 
L'explication de retpoline ( https://support.google.com/faqs/answer/7625886 ) donne pas mal de détails, si je découpe :
 
Dixit Google :

Citation :

It is predicated on the fact that many CPUs implement a separate predictor for function returns.  When available, this predictor is used with high priority, allowing for the construction of an indirect branch which is safe from speculation-based attacks.


 
La doc d'Intel précise un peu la manière dont ils l'implémente (c'est différent chez AMD en passant) et la ou ça coince :  
 

Citation :

2.4.2.1 Branch Prediction Unit
Branch prediction enables the processor to begin executing instructions long before the branch outcome
is decided. All branches utilize the BPU for prediction. The BPU contains the following features:
16-entry Return Stack Buffer (RSB). It enables the BPU to accurately predict RET instructions.


 
Le RSB est un buffer (avec 16 entrées, high priority tout ça) rempli par le prédicteur.  
 
Google :

Citation :

On x86 architectures, function call and return is implemented using the call and ret instructions.  call accepts a target (which may be direct or indirect) and branches execution to that target, while ret returns (to the instruction following) the last call.  (This is implemented by call pushing the return target to the stack, prior to branching.)  The key property here is that the hardware’s cache for the return target (the RSB) and the actual destination which is maintained on stack are distinct.  The RSB entry is a hardware detail and invisible to the underlying application. However, we may manipulate its generation to control speculative execution while modifying the visible, on-stack value to direct how the branch is actually retired.


 
L'idée de retpoline c'est manipuler le RSB pour qu'il contienne toujours la bonne valeur et éviter toute spéculation :  
 

Citation :


    Make a direct call to set_up_target; this is known at compile time and will not trigger speculative target resolution.  This generates distinct stack and RSB entries with a return target of capture_spec.
    Modify the on-stack entry generated by (1), to instead direct to %r11.  Note that this does not affect the RSB entry generated above, which will still target capture_spec.
    Return against our original call
        Speculative execution consumes the RSB entry generated by (1), and is captured within the pause loop at (4).  These instructions are only executed by the speculative path.
        Our return is ultimately retired, the on-stack value is used to locate the actual new instruction pointer and the benign results of any speculative execution in the loop at (4) are discarded
 
Importantly, in the execution above there was no point at which speculative execution could be controlled by an external attacker, while accomplishing our goal of branching to an indirect target.


 
Pour le problème de Skylake+, y'en a plusieurs, le premier est expliqué par Google :
 

Citation :


Return stack underflow
 
Function return is itself an indirect branch.  Specifically here, we do not refer to the return gadgets constructed above, but rather the natural function returns which will still exist protected application.  While the transformation above may be used to protect other indirect branches, we must also guarantee that returns do not lead to speculation.
 
For example, on x86 the RSB define fixed capacities.  Behavior with exhausted return stack predictors is not well-specified, which means we must potentially avoid underflow.  For example, in the case that the hardware chose to instead turn to another predictor.  To prevent this, in some cases it may be necessary to “refill” the return stack to guarantee that underflow cannot occur.  (See the appendix for an example.)


 
Il y a un problème potentiel de "vider" le cache, par exemple avec des tas de fonctions imbriquées. Si le cache est vide, on ne sait pas ce qui se passe (indice, il ne se passe pas la même chose sur Skylake+ que sur les archis précédentes). Des cas concrets ou on peut vider le cache :
 

Citation :

Cases which this applies to include:
 
    When we transfer control into protected execution (so that we do not perturb the steps that it may have taken to preserve the integrity of their hardware return prediction).
        Guest to hypervisor transitions, context-switches into a protected process, interrupt delivery (and return).
    When we resume from from a hardware sleep state which may not have preserved this cache (e.g., mwait).
    When natural execution potentially exhausts the return stack in a protected application.  (Note that this is a particular corner case, with more limited exploitability -- we expect that most binaries deploying retpoline protections will not require this specific mitigation.)


 
Solution proposée par Google, s'assurer qu'il ne soit jamais vide (RSB stuffing) pour éviter le "comportement non défini".
 
lkml ( https://lkml.org/lkml/2018/1/26/606 ) pour faire le lien avec Skylake :

Citation :

The RSB-stuffing on context switch (or kernel entry) is one of a
*litany* of additional hacks we need on Skylake to make retpolines
safe.


 
Le problème c'est qu'il y a un tas de cas ou le RSB peut être bypassé ( http://lkml.iu.edu/hypermail/linux [...] 07190.html ) et que l'on se retrouve dans le "cas non précisément défini" (et donc exploitable via Spectre V2) :  
 

Citation :

Refill or not, you are aware that a correctly timed SMI in a leaf function will cause the next ret to speculate into userspace, because there is guaranteed peturbance in the RSB? (On the expectation that the SMM handler isn't entirely devoid of function calls).


 
(SMI, System Management Interrupt) https://en.wikipedia.org/wiki/Syste [...] tering_SMM
 
Bref, c'est compliqué sur Skylake !


Message édité par C_Wiz le 31-01-2018 à 18:00:56
Reply

Marsh Posté le 31-01-2018 à 20:36:29   0  

Chez hp y a des nouveaux firmware depuis fin de semaine derniere
La secu nous a fait chier d appliqué de suite les nouveau bios et fameux patch
Et maintenant tu te retrouve avec plusieurs dizaine de becane super instable
Sauf qu appliquer des patch merdique et bios merdique sur une machine stable est une chose
Appliqué des pat h/bios stable sur des machine devenu instable à cause de leur gestion merdique dans la pricipitation de la chose c est une autre paire de manche
 
Comme d hab faut surtout pas ecouter les gars qui le vive sur le. Terrain, faut insister dans l ordre debile "rien a foutre applique quand meme alors que suite à ça les machine deconne"
 
Puré ce monde marche vraiment sur la tete

Message cité 1 fois
Message édité par Activation le 31-01-2018 à 20:39:15
Reply

Marsh Posté le 01-02-2018 à 08:48:34   0  

Activation a écrit :

Chez hp y a des nouveaux firmware depuis fin de semaine derniere
La secu nous a fait chier d appliqué de suite les nouveau bios et fameux patch
Et maintenant tu te retrouve avec plusieurs dizaine de becane super instable
Sauf qu appliquer des patch merdique et bios merdique sur une machine stable est une chose
Appliqué des pat h/bios stable sur des machine devenu instable à cause de leur gestion merdique dans la pricipitation de la chose c est une autre paire de manche
 
Comme d hab faut surtout pas ecouter les gars qui le vive sur le. Terrain, faut insister dans l ordre debile "rien a foutre applique quand meme alors que suite à ça les machine deconne"
 
Puré ce monde marche vraiment sur la tete


Et alors ? Tu décris l'exemple typique de décisionnaires qui n'ont aucune culture technique et encore moins de sensibilité sur le contexte. Ils le savent qu'il y a des risques d'instabilité, mais le fait de se rendre conforme est plus important que la stabilité des bécanes.
C'est après la bataille, au moment de compter les points Benco, qu'on mesurera les mauvaises décisions prises dans la précipitation. L'indisponibilité générée par ces incidents vont avoir des répercussions économiques sur la boîte. Il faudra trouver des responsables ... et il est fort à parier que ces fameux décisionnaires vont avoir chaud aux fesses.


---------------
"Mieux vaut demander à un qui sait plutôt qu'à deux qui cherchent." ... "Le plus dur, c'est de faire simple.", TNZ
Reply

Marsh Posté le 01-02-2018 à 09:23:45   0  

Surment pas les décisionnaires comme tu dit j'ai les mêmes dans ma boite (pas du tout le même secteur) ce sont des gestionnaires purement financier il n'ont aucune connaissances du secteur, si ça merde, les répercussions redescendes gentillement les échelons jusqu'en bas et t'en prend plein la tête, quand bien meme t'a prévenus que tu fesait de la merde, car toi t'a forcément fait une erreur d'une façon ou d'une autre  [:piranhas1]  


---------------
"Toute voiture restant en un morceau pendant plus d'une course est trop lourde"  
Reply

Marsh Posté le 01-02-2018 à 11:39:18   1  

C_Wiz a écrit :

C'est bien la prédiction des retours, précisément de l'instruction x86 RET, et la manière dont ça diffère qui joue, oui.


Des retours utilisés pour faire des jump/call de manière à tromper le prédicteur, pour être clair (j'espère). Mais oui, on doit être d'accord.
 

Citation :

L'idée de retpoline c'est manipuler le RSB pour qu'il contienne toujours la bonne valeur et éviter toute spéculation


Pour qu'il contienne une valeur bidon qui va tromper le prédicteur. Par contre merci beaucoup des références détaillées, je n'avais lu qu'en diagonale le papier de Google, et donc je corrige ce que j'ai dit : les retours sont apparemment également prédits sur beaucoup de CPU, mais on peut manipuler le prédicteur de manière à ce qu'il n'exécute pas spéculativement d'instruction sensible, contrairement au jump/call indirects qu'on ne peut pas manipuler.
 

Citation :

Bref, c'est compliqué sur Skylake !


Effectivement, merci pour la réponse détaillée, c'est très instructif. Je vois pas trop comment Intel va se démerder avec Skylake+...

Reply

Marsh Posté le 01-02-2018 à 13:35:35   0  

J'ai un i7 8700k, j'ai fait strictement zero mise a jour et je vois aucun probléme par rapport a avant...
 
je suis un gros gamer et si différence en jeu il y avait je l'aurai senti a moins que cela soit vraiment trop faible a constater
 
beaucoup de gens jouent le ton de la catastrophe ou je rêve ?

Reply

Marsh Posté le    

Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed