Reprise du message précédent :

C'est AMD qui a poussé le patch qui indique qu'ils ne sont pas vulnérables. Il vaut mieux qu'ils soient surs d'eux sinon c'était une très grosse bêtise que d'avoir poussé ce patch !

http://www.tomshardware.fr/article [...] 66352.html
 
VIA va refaire des CPU x86, avec le concepteur chinois Zhaoxin
Un nouveau concurrent sérieux pour Intel et AMD ?
 
2018 commence vraiment mal pour Intel ...

MacOS a été patché depuis 10.13.2 sinon : https://twitter.com/aionescu/status/948609809540046849

 
 
 
Mon petit Snapdragon 625 (8xA53) est tranquille !    
 
Pour les couplés avec du Out of order il me semble que l'OS est plutôt exécuté sur les CPU les plus économiques en énergie qui sont justement les archi ARM in-order... de la à supposer que la faille ne les touches pas non plus... juste une idée lancée...

Une faille bien dangereuse, j'espère que les patch vont être publié rapidement.
 
Le cas d'AMD va devoir être suivi de près, des détails sur l'implémentation hardware des protections pour le changement de contexte serait appréciable.
 
Il sera aussi intéressant de quantifier l'impacte sur les performances dans les différents usages une fois le patch publié pour Windows.

En tout cas, AMD sera épargné par le patch sous linux...
 
https://www.phoronix.com/scan.php?p [...] le-x86-PTI

via a toujours fait des puces x86, ils n'ont jamais arrêté.
ils ont un partenaire qui a des sous et visent plus haut. Entre vouloir et pouvoir, il y a un gouffre que beaucoup n'ont jamais franchi et qui sont morts ou rachetés depuis. Via s'est foiré sur les gpus après le rachat d'S3. Idem pour les cpus après le rachat de cyrix. On peut dire aussi sur les chipset que la fin fut très peu engageante. Tu n'arrives pas à faire un cpu performant en claquant des doigts donc je doute que ça soit un concurrent sérieux avant longtemps si ça l'est un jour.

Des détails techniques :
https://googleprojectzero.blogspot. [...] -side.html

J'allais le poster  
 
Et d'après https://security.googleblog.com/201 [...] -need.html :

https://twitter.com/ryanshrout/stat [...] 7244018689
 

 
Long ago, Intel made a design mistake in its 64-bit chips -- and now, all Intel-based operating systems and their users must pay the price.
http://www.zdnet.com/article/secur [...] ulnerable/

Et d'après https://security.googleblog.com/201 [...] -need.html :

[/quotemsg]
 
En pratique il n'y a que le CVE-2017-5753 qui affecte AMD (et sans doute ARM). KIPT ne permet de corriger que les deux autres, CVE-2017-5715 et CVE-2017-5754.
 
CVE-2017-5753 affecte probablement tout CPU out-of-order car il n'y a forcemment traversée de privilège. L'astuce est de contrôler le code exécuté par le kernel via BPF.

Et ben sa craint

Y aura t'il moyen de ne pas installer ce patch sur nos w10 ou de le désinstaller ?

Vache, ça craint
 
https://spectreattack.com/
 
Question Altitude : pourquoi vouloir ne pas installer ce patch ?
Si j'ai bien compris : MS l'a déjà déployé, et je serais surpris qu'il soit possible de le désinstaller.

https://support.microsoft.com/en-us [...] -kb4056892

 
Donc l'activation du patch semble conditionnelle, à voir ce qui se passe sur les machines sans antivirus...

La question qui suit est: l'architecture Zen est-elle vulnérable ? Car le concept du problème repose sur une exécution out of order plus prononcée depuis Haswell. Et la vérification de la vulnérabilité semble plus empirique que formelle.
 
L'idée est qu'une donnee secrète va rendre une opération illégale, mais qui va être exécutée parmi d'autres, et le résultat invalidé après par levée d'une exception. Sauf qu'en ayant certaines de ces opérations chargeant de la mémoire, elle accessible, en fonction de la donnée secrète, on va pouvoir exploiter des résultats non-invalidés avant KPTI. Un résultat qui n'était pas invalidé est si le cache est "chaud", cad que l'adresse a déjà été vue et sera plus rapidement accessible.
 
Il suffit alors de charger des adresses dont les valeurs sont représentatives de la valeur secrète parmi ces opérations, laisser le code planter. Ensuite vérifier quelles adresses sont plus rapides à accéder pour découvrir lesquelles ont été accédées en fonction de la valeur secrète.
 
Pour éviter le bruit de mesure, plusieurs pages de mémoire sont en fait affectées par bit de la valeur secrète, et c'est le résultat moyen qui est utilisé.

Donc en gros c'est une vulnerabilite autour de l'optimisation des instructions donc visant a augmenter les perfs, et le patch visant a la corriger entraine une baisse de perfs... Ca donne l'impression de tourner en rond J'espere quand meme qu'une majorite d'applications peuvent continuer a profiter du OoO sans que ce patch nuise a leurs perfs.

 
Normalement, tant qu'il n'y a pas de "system call", cela ne va rien changer...

Je suis ça avec beaucoup d'intérêt...

 
C'est surtout que ça reste un effet de bord imprévu. Je pense que d'ici la génération n+2 maxi, on aura des CPU exempt de ce soucis chez Intel.

Tu rajoute un peu d'aléatoire dans les accès mémoire en cache ou un truc du genre...

Je vois

Reste à savoir si Intel dispose encore des personnes capable de le faire proprement

 
Question très pertinente que je pose aussi, si le système est vulnérable, ce serait quand même plus prudent de remédier à ce problème de sécurité bien plus grave qu'une perte de performance.

Et chez AMD, ARM et peut être d'autres fournisseurs pour le coté "Spectre".

Sur la page d'ARM, les cortex A-75 sont touchés par "Meltdown" également et les A-15, A-57 et A-72 par une variante de "Meltdown" non précisée:
https://developer.arm.com/support/security-update

Ce serait possible de fusionner l'autre topac avec celui-ci ?  
 

https://twitter.com/aionescu/status/948750715844898817
https://twitter.com/epakskape/status/948781605790695424
Les mises à jour de microcode ajouteraient des MSR pour contrôler la prédiction de branchement (désactiver temporairement, et/ou vider les buffers).

On parle des processeurs Intel à partir de 2008, on peut être un peu plus précis au niveau des architectures ? C'est à partir de Nehalem ?
 
Les Core 2 Duo/Quad (Penryn) ne sont pas touchés ?
(Un E8400 a tout hasard )
 
Du coup est-ce que le patch (windows et linux) s'appliquera à tous les CPU intel, même les vieux qui ne sont pas concernés ?
 
Merci d'avance si vous avez l'info

 
Oui faut désactiver les mise à jour en auto et les mettre en manuel  
 

 
Tout les CPU OOO, donc tout les CPU Intel à partir du Pentium Pro, donc tout les CPU Intel "i686"&+, seul les Atom ancien sont épargnés du coup...

Clair, maintenant le patch est officiel :
Linus Torvalds has now ended up pulling the latest PTI fixes that also include the change to disable page table isolation for now on all AMD CPUs. The commit is in mainline for Linux 4.15 along with a few basic fixes and ensuring PAGE_TABLE_ISOLATION is enabled by default.
 
 
https://git.kernel.org/pub/scm/linu [...] source=anz
 

Il me semble qu'on a plus le choix sur Windows 10 famille.

 
Le patch concerne la faille "Meltdown" qui est exclusive à Intel,
 

 
Je copie / colle depuis l'autre topac :
 
Il y a plusieurs exploits, "Meltdown" (CVE-2017-5754) et "Spectre" (CVE-2017-5753 & CVE-2017-5715) :
 

• Meltdown touche tous les processeurs Intel depuis 1995 et c'est cette faille qui est concernée par le patch.

• Spectre touche les processeurs Intel, AMD et ARM et il ne semble pas y avoir de patch pour le moment.

 
Source

Non mais là ce qu'il ont fait, c'est juste empiriquement prouvé qu'une faille théorique connu depuis que l’exécution spéculative existe est possible.
 
C'est juste qu'il y a 20 ans on avait pas la même notion des risques, pas la même connectivités à Internet, pas le même usage de l'outil informatique.
 
C'est pour ça qu'à titre personnel, je trouve que les patchs devrais être facilement désactivable quelque soit l'OS, puisque dans beaucoup d'usage c'est une protection pas forcement utile en fait. D'autant plus qu'au bout du compte ils ont prouvé que c'était techniquement possible, mais aucune attaque pratique n'a été réalisée ou mis en lumière...

Je suis quand même surpris que personne ne tique plus sur les CPU ARM impactés.
Sachant que les téléphones portables/tablettes sont de plus en plus utilisés pour accéder à des données "confidentielles" comme son compte en banque par exemple.

Curieux de voir si Samsung va pousser un patch pour mon S5 qui, a priori, est à base de A15 modifiés.
Ou alors Android n'est pas impacté? Je n'ai pas trouvé d'info...

Oui, c'est dommage que (à part Linux) les OS soient de plus en plus fermés, au détriment des utilisateurs qui savent de quoi ils parlent.

Faire des OS «pour les nuls» qui se maintiennent tous seuls, très bien. Mais tout fermer pour ceux qui s'y connaissent, c'est n'importe quoi.  

Ça m'est déjà arrivé de vouloir ouvrir un dossier sur mon HDD et que Windows me dise «bah non, t'as pas le droit». Ce jour là j'ai fait la gueule.

ARM est impacté par Spectre, qui n'a pas de patch possible.

https://cdn.kernel.org/pub/linux/ke [...] og-4.14.11
Pas tout rose pour AMD non plus :
 
x86/pti: Put the LDT in its own PGD if PTI is on
     
    commit f55f0501cbf65ec41cca5058513031b711730b1d upstream.
     
    With PTI enabled, the LDT must be mapped in the usermode tables somewhere.
    The LDT is per process, i.e. per mm.
     
    An earlier approach mapped the LDT on context switch into a fixmap area,
    but that's a big overhead and exhausted the fixmap space when NR_CPUS got
    big.
     
    Take advantage of the fact that there is an address space hole which
    provides a completely unused pgd. Use this pgd to manage per-mm LDT
    mappings.
     
    This has a down side: the LDT isn't (currently) randomized, and an attack
    that can write the LDT is instant root due to call gates (thanks, AMD, for
    leaving call gates in AMD64 but designing them wrong so they're only useful
    for exploits).  This can be mitigated by making the LDT read-only or
    randomizing the mapping, either of which is strightforward on top of this
    patch.
     
    This will significantly slow down LDT users, but that shouldn't matter for
    important workloads -- the LDT is only used by DOSEMU(2), Wine, and very
    old libc implementations.

c'est typiquement le genre de faille qui permet(tait) de craquer les consoles type PS3 etc, une porte s'entrouve et avec un exploit approprié, on rentre en mode noyau.
 
t'inquiete, y en a qui vont trouver un moyen de s'en servir, d'ou la ruée vers les patchs

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