Le topic de la programmation: Et envoyez des sioux!

**Møgluglu** · 22/12/2017, 13h49

Et pour dire strictement inférieur on écrit ⩽≠. Problème résolu.

**Shosuro Phil** · 23/12/2017, 02h11

Envoyé par Møgluglu

Un bug rigolo (contexte : un compilateur de shaders pour GPU) : https://pastebin.com/RLD9eiBv

Je suis pas sur de comprendre la source du probleme, c'est que A<B et A-B<0 n'ont pas toujours la même réponse? ou que la parallélisation a la volée faisait s’exécuter les calculs différemment, avec des résultats non cohérents?

**Møgluglu** · 23/12/2017, 12h01

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.

**Shosuro Phil** · 23/12/2017, 23h50

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.

**Metalink** · 24/12/2017, 01h49

Envoyé par ducon

OK, on remplace <= par ⩽.

J'avais testé quelques temps les polices avec ligatures dans Visual, c'était assez sympa

**rOut** · 24/12/2017, 02h29

Argh

**Møgluglu** · 24/12/2017, 11h22

Envoyé par Shosuro Phil

Bref, les flottants, plus les architectures exotiques, c’est le mal, je le savais. Je retourne apprendre Coq.

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

**vectra** · 25/12/2017, 00h48

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...

**Shosuro Phil** · 25/12/2017, 13h40

Envoyé par Møgluglu

D'ailleurs tu peux faire du Coq sur des flottants et des architectures exotiques : https://hal.archives-ouvertes.fr/hal-00862689

Oh ça je sais, j’ai même un collègue qui me tient un peu au courant... mais c’est bien au-delà de mon niveau, je débute moi (j’ai quelques longueurs d’avance sur mes étudiants, mais pas beaucoup plus).

**vectra** · 25/12/2017, 19h28

Han, je savais pas que Coq servait à prouver Compcert

**Max_well** · 03/01/2018, 09h45

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

**Møgluglu** · 03/01/2018, 11h34

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 ?

**Max_well** · 03/01/2018, 11h41

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.

**Møgluglu** · 03/01/2018, 12h04

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 ?

**Cwningen** · 03/01/2018, 12h41

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 ?

**Møgluglu** · 03/01/2018, 13h48

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.

**Mayalabielle** · 03/01/2018, 13h55

Envoyé par Møgluglu

Rien dans l'immédiat, mais combiné avec une autre faille genre buffer overflow, ç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 les 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 Inq 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.

Oui, c'est un peu too much.

**Charmide** · 03/01/2018, 14h10

En attendant Intel perd 2.5% et AMD prend 6% en pre-trading, je me suis fait un peu de pognon dessus

**Tramb** · 03/01/2018, 15h05

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.

**shlagevuk** · 03/01/2018, 16h08

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

**Møgluglu** · 03/01/2018, 16h45

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.

**Tramb** · 03/01/2018, 16h46

Envoyé par Møgluglu

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.

CVE de reptiliens, voilà pourquoi.
Ca peut avoir un rapport avec le CCC, aussi.
Et/ou MINIX

**Møgluglu** · 03/01/2018, 17h01

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.

**Tramb** · 03/01/2018, 17h16

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.

**Tramb** · 04/01/2018, 09h36

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

**Tramb** · 04/01/2018, 11h02

https://meltdownattack.com/meltdown.pdf
https://spectreattack.com/spectre.pdf

**Møgluglu** · 04/01/2018, 11h44

OK on va tous mourir. 2018, la fin du monde pour les micro-architectes.

**PrinceGITS** · 04/01/2018, 11h54

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 ?

**Tramb** · 04/01/2018, 12h47

On va revoir du MIPS, probablement

**Anonyme899** · 05/01/2018, 14h06

Envoyé par Tramb

https://meltdownattack.com/meltdown.pdf
https://spectreattack.com/spectre.pdf

Je ne comprend absolument rien. Je suis complètement inculte en la matière.
En gros ca fait quoi réellement ce genre de faille et les hackers peuvent retirer quoi d'une attaque?

Mettons que j'ai mes clients sur un serveur à base d'intel. Qu'est ce qu'ils risquent?

Discussion: Le topic de la programmation: Et envoyez des sioux!

Outils de la discussion

Règles de messages