Et pour dire strictement inférieur on écrit ⩽≠. Problème résolu.
En flottant IEEE-754 avec sous-normaux, on a bien A<B ssi A-B<0. Par contre, a*b<c n'est pas équivalent à fma(a,b,c)<0 avec des comparaisons strictes.
Ici, c'est une combinaison un peu subtile de transformations de code.
La norme C, et par extension les langages de shaders, autorise le compilateur à évaluer des expressions intermédiaires dans une précision supérieure au type de donnée flottant spécifié. Aujourd'hui, les compilateurs utilisent cette règle surtout pour remplacer l'expression a * b + c par fma(a, b, c). Par défaut, on arrondit d'abord le résultat de a * b en double, puis on ajoute c et on arrondit de nouveau. Avec le FMA, on calcule la valeur exacte de a * b + c et on n'arrondit qu'une seule fois le résultat. C'est donc plus précis, et plus rapide comme c'est une seule instruction au lieu de deux, tout le monde est content.
Savoir s'il vaut mieux utiliser un FMA ou des additions et multiplications dépend d'un tas de facteurs, qui font qu'on a envie de faire ce choix assez tard à la compilation, typiquement au moment de la sélection d'instructions.
Ici, le compilateur a décidé de dupliquer le calcul de l'expression a*b parce que ça l'arrangeait sur cette archi VLIW exotique. Jusqu'ici tout va bien. Le drame, c'est que certains des calculs de a*b ont été intégrés dans des FMA par la suite, mais pas celui de la comparaison. Du coup le "même" calcul dupliqué produit des résultats différents. En particulier, on peut trouver des flottants a et b tels que l'arrondi de a*b renvoie le flottant c, mais qu'en valeur exacte a*b<c. Le FMA qui calcule la valeur exacte de a*b-c avant arrondi renverra un flottant <0.
Fondamentalement, c'est parce que les règles de réécriture ne sont pas confluentes : suivant l'ordre dans lequel on les combine on peut arriver à n'importe quoi, y compris des contradictions comme prouver que 0=1.
Dans ce cas précis, c'est aussi les architectes qui ont défini le jeu d'instructions qui ont merdé. Il y aurait du y avoir une instruction pour calculer fma(a, b, c) < 0 plutôt que a * b < c avec arrondi : c'est pas plus cher.
Dernière modification par Møgluglu ; 23/12/2017 à 13h12.
Ok, c’est à peu près ce que j’envisageais...
Bref, les flottants, plus les architectures exotiques, c’est le mal, je le savais. Je retourne apprendre Coq.
Argh
"Dieu est mort" · "Si le téléchargement c’est du vol, Linux c’est de la prostitution."
Mais non. Le mal c'est les langages comme C qui ne définissent pas correctement ou pas du tout la sémantique des codes flottants.
Le message que j'essaie de faire passer, c'est que les flottants sont des objets comme les autres en informatique : c'est du discret, pas du continu. Les raisonnements qui supposent un comportement continu genre "je m'en fous de la précision des calculs, un résultat à 10% près ça me suffit" sont aussi faux que "je m'en fous de la précision de mes pointeurs, j'ai un espace mémoire 64 bits et 64 Go de RAM, je ne suis pas à quelques octets près". Autant ça peut être contre-intuitif pour des physiciens numériciens, autant pour les informaticiens ça devrait être parfaitement naturel.
D'ailleurs tu peux faire du Coq sur des flottants et des architectures exotiques : https://hal.archives-ouvertes.fr/hal-00862689
J'étais pas loin de penser que j'en avais rien à battre de la précision en flottants, jusqu'à ce qu'un calcul me sorte un résultat en escalier au lieu d'une courbe continue.
Long story made short, j'avais des valeurs flottantes de l'ordre de 10e6 avec une précision souhaitée à 3 décimales: eh ben non. J'ai dû appliquer un offset à mes valeurs avant et après calcul pour récupérer la précision souhaitée. Ca fait bizarre la première fois...
Intel a encore merdé dans ses processeurs, et on va tous prendre cher en terme d'inpact sur les performances :
https://www.theregister.co.uk/2018/0...u_design_flaw/
Jusqu'à 23% de perte de perf au pire :
https://www.postgresql.org/message-i...p3.anarazel.de
Apparemment, la base du bug serait là : https://cyber.wtf/2017/07/28/negativ...rom-user-mode/
source CPC (où ça en discute aussi) : http://forum.canardpc.com/threads/11...1#post11407294
Dernière modification par Max_well ; 03/01/2018 à 11h20.
Attention, un Max_well peut en cacher un autre
Equipe Highlander La Rache
Je vois tout le monde sauter sur le mot clé "spéculation" et ressortir les attaques par canaux cachés sur la randomisation de l'espace mémoire (ASLR), mais je ne vois toujours pas le rapport avec la faille dont on parle. Là on parle de récupérer des données kernel au niveau user, pas juste les mappings mémoire ?
D'après ce que j'ai compris (mais je suis pas du tout expert CPC), l'idée est de profiter de l'execution spéculative pour récupérer les adresses mémoires du kernel et donc bypaser le ASLR.
Attention, un Max_well peut en cacher un autre
Equipe Highlander La Rache
Non mais ça c'est connu, et a priori ça affecte les CPU AMD aussi. C'est une des nombreuses attaques par canaux cachés en exploitant les caches, les TLB, et les prédicteurs de toutes sortes. Si ce n'était que ça, pourquoi paniquer seulement maintenant ?
C'est parce qu'il existe désormais une contremesure et qu'on peut sortir la tête du sable ?
En attendant plus de détails sur la faille, déjà je ne comprends pas trop cette histoire de KASLR. Les pages noyaux sont adressable mais pas lisibles en mode utilisateur, non ? Qu'est ce que du code en mode utilisateur peut faire une fois qu'il a obtenu l'adresse du noyau ?
Rien dans l'immédiat, mais combiné avec une autre faille genre buffer overflow ou rowhammer, ça permet d'injecter du code ou des données ou d'exécuter du code au bon endroit.
Le principe d'ASLR est de rendre les attaques par buffer overflow bien plus difficiles, parce que tu ne peux pas coder d'adresses en dur dans l'attaque, ni même récupérer les valeurs des adresses côté kernel dont tu as besoin pour l'attaque. Mais si on arrive à contourner ASLR en récupérant les adresses qui vont bien dans le kernel, on peut de nouveau faire marcher ces attaques.
Si je comprend bien, on parle d'une série de patchs dans Linux qui renforcent la sécurité en isolant complètement les pages kernel des pages user, au prix d'un coût sensible en perf (donc une contremesure contre une attaque qui contourne une contremesure contre une attaque) :
https://lwn.net/SubscriberLink/741878/eaff7b24627c41a2/
https://lwn.net/Articles/738975/
À partir de là, The Register sort un article putaclic comme quoi ça implique que les CPU Intel c'est tout pourri et qu'on va tous mourir, et bien sûr l'internet s'empresse de faire tourner ce scoop.
Dernière modification par Møgluglu ; 03/01/2018 à 14h59.
En attendant Intel perd 2.5% et AMD prend 6% en pre-trading, je me suis fait un peu de pognon dessus
Oui je pense que c'est une résonance particulière avec Rowhammer, par exemple.
La KASLR permet de rajouter de la difficulté à taper dans/sur le nouillau.
Sleeping all day, sitting up all night
Poncing fags that's all right
We're on the dole and we're proud of it
We're ready for 5 More Years
KASLR avait déjà été cassé, et uniquement sur du CPU intel du fait de leur TLB
https://www.blackhat.com/docs/us-16/...-Intel-TSX.pdf
Quelques infos en plus:
https://www.phoronix.com/forums/foru...753#post998753
KASLR a beaucoup été cassé de plein de manières différentes, y compris sur les CPU AMD. L'attaque par double faute de TLB de Hund et al. en 2013 sur Sandy Bridge en est une effectivement.
Mais ça ne veut pas dire qu'il faut jeter KASLR, qui rend toujours a priori les attaques plus difficiles.
D'où l'argument complotiste : mais pourquoi les industriels poussent tout d'un coup ce patch en 2018 ? c'est qu'ils savent quelque chose de nouveau qu'on nous cache.
J'ai pas trouvé de discussion sur ça dans les exposés de 34c3 : https://media.ccc.de/c/34c3
Enfin à part l'attaque du moment sur ASLR par Javascript (à laquelle les CPU AMD n'échappent pas d'ailleurs) : https://media.ccc.de/v/34c3-9135-aslr_on_the_line
Mais les reptiliens ont surement effacé les vidéos.
MINIX je ne pense pas, il est bien trop en dessous de tout ça à tourner dans son propre espace mémoire sur son 486 à lui dans le southbridge.
Moi j'attends qu'on me fasse un digest du ccc parce que je suis hyper occupé.
Non, je déconne, j'ai la flemme.
Sleeping all day, sitting up all night
Poncing fags that's all right
We're on the dole and we're proud of it
We're ready for 5 More Years
La prez sur la recherche de failles dans les différents BSD est assez intéressante.
Quand on cherche, et qu'on sait chercher, on trouve.
https://media.ccc.de/v/34c3-8968-are...reated_equally
Sleeping all day, sitting up all night
Poncing fags that's all right
We're on the dole and we're proud of it
We're ready for 5 More Years
Sleeping all day, sitting up all night
Poncing fags that's all right
We're on the dole and we're proud of it
We're ready for 5 More Years
Je vais acheter des actions dans les bouliers. On ne sait jamais...
Sinon, les chercheurs indiquent ne pas connaître de malware qui exploitent la faille mais maintenant qu'ils ont fait un PoC, cela arrivera, non ?
Mes Lego - Tof : Canon EOS 40D + Tamron 17-50mm F/2.8 + Canon Seepdlite 430 EX II | VDS MadCatz Arcade Fight Stick TE
On va revoir du MIPS, probablement
Sleeping all day, sitting up all night
Poncing fags that's all right
We're on the dole and we're proud of it
We're ready for 5 More Years