Guillaume Knispel a écrit 2474 commentaires

Et encore, Linux (au sens les mainteneurs officiels principaux) n'a ne semble-t-il reçu qu'une demi info :/

J'abonde qu'on aurait probablement trouvé Meltdown même sans le commit message d'AMD. Il n'y a pas 36 raisons de vouloir démapper tout le kernel space en urgence, dans tous les OS (et non, le simple cassage de KASLR n'en est pas une très bonne…). Justement l'intégration sous l'upstream Linux a été mal organisée s'il y a vraiment eu une volonté correctement pensée de discrétion. Les distros "commerciales" avaient déjà des patchs "secrets" couvrant y compris Spectre (avec du code venant d'Intel, qui semble être globalement le même qui a été intégré à Windows), alors qu'au moins GregKH ne semblait pas au courant de tout (et probablement même Linus… vu ses réactions et ses propositions récentes à la lecture des propositions de mitigations de Spectre). Il semblerait même que le développement secret pour les distros commerciales se soit fait en silo, sans trop de communication entre elles…

Ça aurait ptet moins choqué les observateurs si KPTI avait été intégré bien plus tôt dans le cycle, et simplement activé par défaut au dernier moment de la fin de l'embargo (avec une sortie rapide du premier backport), mais bon ya pas d'alignement de ce calendrier avec le patch Tuesday de MS sauf à avancer ou retarder d'un mois ou plus (même si au final ça c'est terminé par une MAJ hors calendrier côté MS, donc bon, Linux aurait du primer, ça aurait mieux fonctionné). Bon ceci étant Linus avait déjà un peu vendu la mèche en prévenant qu'il pensait que ça allait être backporté sur tous les noyaux LTS.

Il semblerait que les projets concernant Linux ont été au moins depuis fin août/début septembre de ne publier sur la LKML les premiers patchs pour Spectre qu'à la fin de l'embargo. Du coup, son arrêt précipité est une bonne nouvelle; on aura des mitigations officielles pour le vrai Linux sans doute un peu plus tôt, et un peu mieux conçues.

Les deux première sont nommées Spectre, et la dernière Meltdown.

Le problème c'est que l'idée générale de la première attaque pourrait potentiellement être déclinée en plein de nouvelles autres attaques similaires. Le second problème c'est que les patchs en cours de réalisation sont des mitigations posées pour certaines manuellement à des endroits que l'ont considère aujourd'hui comme particulièrement sensibles.

Enfin d'autres patchs en cours de développement sont des mitigations contre la variante 2, et cela inclut de nouvelles manières pour les compilateurs d'émettre du code correspondant à certaines constructions. Cela pourrait plus ou moins ralentir de nombreux programmes dans divers langages de prog (selon les programmes, et selon la manière dont on les compile)

Le seul vrai fix pour Spectre qui comblera beaucoup mieux la faille, et sans trop sacrifier les performances, sera de changer assez radicalement la micro-architecture interne de futurs processeurs.

Meltdown nécessite aussi de fixer le hard des fondeurs concernés histoire de pas sacrifier les performances, mais le fix devrait être relativement simple. Reste qu'Intel n'a pour l'instant que les procs les plus touchés, et c'est même pas sûr que les prochains qu'il va sortir ne fixeront ne serait-ce que Meltdown. On peut toujours se rabattre sur AMD en attendant (ou durablement), avec son archi Zen qui devient encore plus intéressante…

Chez Intel, la manière dont les infos fournies par la MMU sont exploitées par d'autres bouts du CPU est en effet clairement défaillante (même si le fondeur n’arrête pas de répéter que tout fonctionne comme conçu, ce qui veut dire que c'est leur conception qui est clairement moisie et bugué): les données d'un privilège élevé sont chargées spéculativement pour du code d'un niveau de privilège plus bas, et en plus de ça l'exécution spéculative continue y compris en produisant des effets de bord micro-architecturaux flagrant.

Pour Spectre, c'est clairement un truc malin auquel personne n'avait pensé intégralement auparavant (du moins sans le signaler). En choisissant bien les données contrôlées par un niveau de privilège inférieur/un contexte ne devant pas avoir accès à d'autre données, et utilisées par du code ayant l'accès (par exemple en jouant sur les paramètres d'un appel système), il est possible de pousser le code privilégié à réaliser des exécutions spéculatives complètement délirantes, et ensuite en mesurant les effets de bord microarchitecturaux, d'en déduire des données ciblés. Mais il faut trouver des bouts de code dans les programmes existant qui prévoient des opérations pouvant être ainsi détournées. Ce qui est beau dans cette dernière attaque c'est que le code source du programme ciblé a beau être parfaitement correct, ça ne change rien, car les processeurs en régime spéculatif passent outre les vérifications programmées classiquement pour tenter de prendre de l'avance sur la suite du boulot. C'est cette anticipation qui, selon les cas, change suffisamment l'état interne du processeur d'une manière dépendant des données lues, et mesurable.

Dans le cas de Meltdown il n'y a pas de code tiers privilégié qui effectue les accès pour le compte de l'attaquant: c'est le CPU qui est à moitié con.

Ça se pourrait que leurs communicants n'aient pas été prévenus tout de suite, afin de limiter le risque de fuites. Ceci étant dit 1 semaine avant la deadline, ça reste curieux.

AMD a indiqué sur la LKML que leurs processeurs ne chargent jamais les données d'un niveau de privilège élevé vers un plus faible, même lors d'une exécution spéculative. Ils sont donc à priori immunisés contre Meltdown tel qu'il a été défini. Maintenant ptet qu'on imaginera des variantes entre Meltdown et Spectre…

Meltdown et Spectre permettent de lire les données de divers espaces d'adressage.

Pour Meltdown, c'est le noyau, et ça suffit pcq sous Linux ya toute la mémoire du système mappée pour lui. Pour Spectre, c'est aussi le noyau sauf s'il intègre des contres mesures spécifiques (à au moins 2 variantes connues de Spectre, on en trouvera ptet d'autres plus tard), et plus généralement si le noyau est protégé, tout processus n'intégrant pas de contre-mesures et avec lequel on peut interagir un minimum. C'est "un peu" gênant pour les navigateurs Web pcq'ils JIT le JS vers du code natif…

Pour certaines des contremesures, des patchs GCC / LLVM sont en préparation. Jusqu'à 50% de perfs en moins sur du C++ rempli de vtable et pas optimisé… :/ (et le premier qui me sort que c'est pas grave on peut faire du LTO et de la dévirtualisation, je l'étrangle à coups d'undefined behaviors)

Vous pouvez être sûr qu'on a pas fini d'en entendre parler et que l'imagination va déborder pour trouver d'autres vecteurs.

Les serveurs de tous genres vont être assez affectés car ils font beaucoup d'IO. Accéder à pleins de fichiers aussi. Tous ce qui fait surtout mouliner le CPU sans faire beaucoup d'IO ne sera pas affecté. Selon les systèmes, certains sous-systèmes ont déjà été optimisés pour diminuer le nombre de syscalls et logiquement l'impact sera négligeable dans ces cas. Enfin on peut s'attendre à des mois voire des années de réoptimisation des différents noyaux pour mitiger l'impact en perf avec toutes les astuces qu'ils trouveront, voire des modifs plus profondes sur l'archi de certaine parties.

Y a des compteurs de perf pour observer les ratios des caches et autres bouts du CPU soit sur un programme soit sur une machine entière: sous Linux, ya entre autre l'outil "perf" pour faire ça.

C'est déjà le cas, mais dorénavant l'impact d'un syscall a, selon le processeurs, des effets indirects élevés qui peuvent être très gênants sur certaines workload, et ça pourrait motiver à réorganiser du code pour éviter des syscalls appelés pas trop fréquemment qui en soit prennent peu de temps mais se mettent maintenant à flusher des caches.

Ainsi alors que certains soft n'auraient eu aucun intérêt à modifier leur code lorsque ce problème n'avait pas été découvert (ils n'en auraient tiré qu'une accélération marginale voire non mesurable), il est fort possible que dorénavant la chasse aux syscalls deviennent bien plus rentable. Ce qui est gênant c'est que du profiling par sampling de %rip pourrait ne pas indiquer parfaitement les endroits où viser, vu qu'une partie du ralentissement est indirect et dilué sur une "longue" période (quand on revient en userspace et que des trucs ont été flushés)

C'est pas trivial. Mais faut relativiser un peu : le découpage de la série est très fin. Du style l'ajout d'une option qui ne fait rien (au moment précis de son ajout) prend un patch rien que pour ça.

J'ai parcouru vite fait les patchs et certes il y a plein de détails à régler, mais le plus important est assez localisé, la suite semble relativement dépendant de la propreté de l'OS dans cette zone, et le reste c'est de la limitation des dégâts sur l'impact sur les perfs. Évidemment même faire un truc basique c'est pas trivial, mais en passant par une première étape qui se concentre sur la sécu et si avec un peu de chance le noyau d'OpenBSD est propre dans cette zone (j'en sais rien) c'est jouable de faire un truc semi-rapidement :p (mais qui risque quand même de crasher un peu à droite à gauche au début; y a déjà un rapport de régression pour Athlon 64 pour Linux)

Petite précision: le jeu de page utilisé quand on est en kernel space map aussi l'espace utilisateur. En plus de ça il map, comme d'hab, (presque) toute la RAM physique (presque pcq des fois des trous sont creusés par d'autres features en aval, mais même en ring0 on y a alors jamais accès). C'est uniquement quand on tourne en userspace qu'il y aura moins de pages mappées. Reste que des flushs sont nécessaires en entrée et en sortie de noyau, y compris en cas d'interruption matérielle (flushs plus ou moins larges, selon les capacités matérielles dispo pour limiter un chouilla les dégâts sur les proc récents)

Bref tout cela reste un vrai désastre en terme de perfs.

pas de l'exécution des instructions x86 à proprement parler (sinon ça serait corrigeable par microcode)

Hm les instructions x86 ne sont pas exécutées mais décodées vers des uop. Un problème au niveau du décodage ne serait pas forcement corrigible par microcode, mais ce qui n'est pas corrigible est en général mieux testé que le reste (il faut espérer…).

Toujours est-il que l'anticipation du problème pour le side-channel est en effet plus au niveau d'autres parties "câblées", personnellement j'ai un faible pour les BTB (mais je connais pas assez la microarch pour vraiment savoir si c'est une hypothèse raisonnable ou pas, c'est juste que je trouverais ça stylé)

Concernant la spéculation on est a peu près sûr qu'elle rentre en jeu dans le problème, et techniquement les instructions spéculées sont bien exécutées mais pas complètement retirées. L'idée c'est qu'il existe un changement d'état mesurable dépendant des données lues spéculativement dans la microarchitecture. Si vous avez du temps vous pouvez tester toutes les idées qui vous passent pas la tête, et AMA avec un peu de chance vous pouvez retrouver la technique avant la levée de l'embargo. Il est aussi possible qu'il faille une combinaison tordue mettant en œuvre plein d'interactions de pleins de features pour y arriver (ex: transactionnel, hyperthreading, page faults)

Il n'y a pas de cas publié d'infection large de malwares utilisant cette technique.

Ça veut pas dire qu'il n'y en n'a pas, ni qu'il va pas falloir patcher ASA(reasonably)P, sauf dans des cas (très rares) où les modèles d'attaques ne seront pas applicables et que les régressions de perfs ne sont pas acceptables.

C'est pas possible de trancher avant la publication des infos détaillées.

Y a des nouvelles features (ASID / PCID) dans les proc les plus récents qui permettent de flusher sélectivement ou un truc du style, et donc mitiger les pertes de perfs, mais même avec ces features elles restent notables, et en plus surtout dans les régimes où elles sont déjà grandes à la bases.

Personnellement je viens de mesurer un passage de certains syscalls que j'ai patché ya pas longtemps (semget & co) de 200ns (Linux 4.14.10) à 400ns (Linux 4.14.11) (avec un microbenchmark pas extrêmement représentatif de vrai workloads - sauf peut-être dans des softs au design bizarre - c'est plus par curiosité). Vu la technique utilisée c'est pas juste xN ou +200ns, mais une loi complexe qui démarre avec un surcoût de durée constante au départ, puis un facteur multiplicatif très grand pour les premiers accès mémoires, et qui est progressivement amorti au fur et à mesure que les caches se rechargent. Un microbenchmark à base de getpid() montre un ralentissement d'un facteur 4 sur celui là (mais bon, là vraiment personne ne fait ça, c'est juste pour avoir une idée des cas les plus extrêmes).

Bref certains softs activement maintenus vont se mettre à jouer à un nouveau jeux; éviter les syscalls. Par exemple si l'émission d'une simple trace flush trop de caches userspace, ça va être un peu gênant.

Moglen (le SFLC) entre autres initie des actions contre des anciens clients (le SFC), et est contre la mise en application de la GPL. Matthew n'est pas le seul à se demander c'est quoi son problème: Perens, par exemple, aussi.

Il faut noter que malheureusement de l'animosité se renforce entre des figures majeures du projet Linux (et ses organisations depuis des années plus que largement corporates) et du monde Libre—et ça correspond à cette fracture philosophique radicale entre les GPListes allégés sauce Linus qui fantasment presque, sans s'en rendre compte ou alors sans oser le dire tout haut, sur la BSD, et les tenant de la GPL traditionnelle (edit: et de la philosophie LL sous-jacente associée): on peut admirer par exemple Greg KH répondre à Perens le désignant de "random people", je doute qu'il ne sache pas qui c'est, ça doit donc être probablement utilisé en tant que sorte d'insulte.

Aujourd'hui, enfin hier, un développeur a bloqué tous les portefeuilles Parity multisignés.
Grossièrement, il a modifié la lib de Parity et s'est octroyé la propriété de tous les portefeuilles multisignés avec Parity. Il a supprimé son contrat auto-exécutant ce qui bloqué tous les portefeuilles multisignés…

Cyberpunk intensifies.

Je parle de ce qu'est devenu le langage en pratique sur certains aspects, pas des gens qui le normalise.

Je pourrais par contre parler de certains de ceux qui l'implémente, en n'utilisant pas le même mot (sauf si je dérape lorsque je suis trop énervé), mais disons en doutant de leur capacité a ne pas mettre en danger le public de par leur approche inconsidérée sur de l'infrastructure aussi critique en utilisant des approches aussi dangereuses. Et sans doutes que les qualificatifs retenus seront au final plus durs que "débile", car on pourrait arguer que ce terme les aurait un peu déresponsabilisés.

Si encore ils étaient capable de pondre des bases de code irréprochables selon leurs propres exigences, je dirais pas, mais lance un compilo buildé avec les sanitizeurs activés, et tu comprendra la folie dans laquelle ils vivent.

Et de par cela le danger que l'on court en 2017 en continuant à utiliser des langages qui sont devenus en pratique, sur certains aspects critiques, débiles.

La notion de il peut pas faire mieux est pas vraiment celle là.

Par exemple,

uint32_t rol_attempt(uint32_t a, int x)
{
    return (a << x) | (a >> (32-x));
}

au plan du matos il n'y a pas d'archi, probablement pas du tout, en tout cas aucune en dehors d'un truc vraiment exotique, pour laquelle le code précédant aurait des raisons de ne pas produire un rol pour x entre 0 et 32 inclus.

Pourtant, je crois bien que les normes du C/C++ rendent ce code undefined pour x == 0 ou x == 32.
Avec un sanitizer d'UB il n'y a pas d'autre choix que de crasher. Alors que ce que le programmeur voulait clairement, c'est un rol 0 => return a;

Et malheureusement vu la politique irréfléchie de certains dev de compilo, ça pourrait bien être le "bon" choix dorénavant car je crois pas que y en ait beaucoup qui garantissent encore qu'ils vont produire un rol à partir de ce code.

Bref, on a même plus de moyen d'exprimer un rol d'une manière pas trop convolué avec toutes ces conneries. L'argument de "l'exploitation des UB" pour optimiser les perfs des programmes tombe à l'eau—cette approche, poussée à son extrême comme ça a malheureusement été fait, c'est de la fumisterie. De la fumisterie dangereuse.

Je suis même pas sûr que c'est possible de tout définir, mais probablement une partie non négligeable ça devrait l'être. Ceci étant dit vu que l'existence d'un tel compilateur moins punitif est hypothétique, il faut basculer vers d'autres mitigation immédiatement disponibles: en détecter le plus possible à la compile (certaines fois des flags -W existent déjà pour ça), définir une sémantique quand ça semble pertinent et que le compilo fourni un flag (malheureusement -fno-delete-null-pointer-checks inhibe Wnull-dereference, et ce dernier ne détecte évidemment pas tout lorsqu'il fonctionne), et enfin faute de mieux pour les cas que tout cela ne couvre pas: instrumenter au runtime et tester.

Ou alors passer à des langages moins débiles.

Mwai enfin bon y a un "problème" associé c'est qu'Unix c'est (entre autre) un gros IDE, et le plus standard qui soit.

Du coup c'est un peu chiant de voir des gens maîtriser à priori leur bousin mais avoir l'air vaguement perdus quand on leur demande de faire ne serait-ce qu'un grep dans un shell.

D'un autre côté, qu'on me corrige si je me trompe mais je crois bien que la privatisation des résultats de la recherche publique se pratiquait (et se pratique probablement encore toujours) suite à des financements 100% publiques de ladite recherche.

Après il faut voir les conditions de l'exploitation projet par projet, et réfléchir à ce qu'impliquerait l'approche d'une ouverture totale (notamment en terme d'exploitation, voire de risque de privatisation "sauvage" par des groupes y compris étrangers), mais sur le principe c'est sûr que ça peut choquer le libriste (et même d'autres !)

Ma principale utilisation, hors tests divers et variés, est la fourniture d'outils de dev in-house développés sous GNU/Linux a un autre département du taf, avec ainsi un environnement d'exécution virtuellement identique pour ces outils sous Win ou Nux. Étant donné ce qu'ils utilisent (Python, Clang, ssh), je peux faire sans WSL (et d'ailleurs j'ai testé sans avant que WSL existe), mais c'est plus facile avec, et nécessite moins de tests de ma part.

Le seul problème notable que j'ai rencontré est la compat avec les antivirus tiers pour Windows (notamment Kaspersky nique l'accès réseau de WSL, si mes souvenirs sont bons—mais on peut désactiver juste les features réseau de Kaspersky et tout rentre dans l'ordre)

À noter aussi que l'intégration avec Win32 est moins poussée que cygwin, MS ayant privilégié la compat avec un vrai Linux. Sur certains points j'aurais préféré des compromis; par exemple une émulation des perms Posix depuis les ACL win comme cygwin & co font—plutôt que le fs complètement isolé de WSL mais implémentant parfaitement les perms Unix classiques ( hormis /mnt/x/ pour accéder aux lecteurs X:\ ). Mais c'est clair que toute solution a des avantages et des inconvénients.

À noter que j'ai trouvé la compat très bonne même en version beta. En plus l'équipe est sans doute l'une des plus accessible et réactive de MS—et aussi très compétente au vu de quelques bugs traités avec eux. Bravo à eux !

Je sais pas exactement à quoi tu penses en parlant de micro-cablage dans le contexte qui nous intéresse, car dans les archis actuelles (et d'ailleurs en fait aussi beaucoup des anciennes) il n'est pas vraiment envisageable de remplacer le micro-code par d'hypothétiques zones dédiées supplémentaires, et de toutes façon il n'y a aucune raison que la complexité de telles hypothétiques zones dédiées soient notablement inférieures à celle du micro-code (au contraire) et donc que le résultat d'une telle archi soit moins buggué (sauf par des effets indirect du style 30x plus d'efforts de test et validation sur les zones en question par peur d'un bug infixable, mais alors là on risque de dériver vers des considérations économiques…)

Et de toutes façons pour certaines fonctions en guise de zones "dédiées" en question, le seul choix raisonnable sera de balancer une ROM. Donc retour à la case départ.

T'as cas prétendre qu'il est pas modifiable et ne pas le patcher, si cet exercice de pensée suffit à te rendre heureux quant à ta liberté.