Crunchez vos adresses URL
|
Calculez la conso lectrique de votre PC
|
Hbergez vos photos
Affichage des rsultats 1 25 sur 25
  1. #1
    Coin Coin la communaut X86,

    merci de m'avoir accept dans vos rangs !

    J'ai eu beau chercher, je n'ai pas trouv un topic qui parle des diffrentes failles connus des produits et c'est assez dommage car vraiment trs intressant. Bon ok, parfois c'est hard comprendre .

    J'ouvre le "bal" avec la dernire faille trouv sur de trs nombreux processeurs Intel au niveau de la mmoire SSM du processeur.

    L'article en anglais => https://www.blackhat.com/docs/us-15/...Escalation.pdf

    Un article en franais pas trop mal, bien qu'assez simpliste => http://www.numerama.com/magazine/338...seurs-x86.html

    Bon j'avoue que j'imagine difficilement comment utiliser a pour faire une attaque de "masse" mais cela reste vraiment impressionnant que cela soit pass sous le radar de tous le monde aussi longtemps...
    Citation Envoy par Oldnoobie Voir le message
    Salut Charlot, Ton stick m'intresse normment, je te MP.

  2. #2
    L'exploit est joli, mais leur deuxime tentative (excuter les registres APIC comme du code x86) tait encore plus classe. L a marche surtout sur un gros coup de bol.

    Mais ce n'est pas vraiment rest "sous le radar". On trouve rgulirement des failles qui permettent de passer en SMM. La gestion de la mmoire physique entre les diffrents priphriques est tellement complexe et dpend de tellement de constructeurs diffrents qu'il y a toujours des trous. Genre une PCI Option ROM d'un composant quelconque qui a une faille dans un coin. Vouloir protger de la mmoire sans vrai mcanisme de protection mmoire, c'est forcment casse-gueule.

    D'ailleurs, il y a 10 ans c'tait open-bar, les BIOS n'activaient mme pas le bit de protection de la mmoire SMM, d'o des exploits ne ncessitant mme pas d'tre root :
    http://forum.canardpc.com/threads/17...64#post3158664

  3. #3
    Obligatory rowhammer:

    Quand on lit de faon rpte une ligne (row, ~8KiO) de DRAM, a a tendance modifier des bits dans les lignes adjacentes (le papier ISCA, mme si c'tait un problme relativement connu). Google nous a fait une dmo en dbut d'anne sur comment s'en servir pour passer root (http://googleprojectzero.blogspot.fr...g-to-gain.html).

    En gnral, on considrait qu'il tait ncessaire d'avoir clflush pour que rowhammer fonctionne, histoire d'avoir assez d'accs la DRAM avant que la ligne victime ne soit rafraichie. Mais en fait y'en a pas vraiment besoin puisqu'on peut apparemment observer des bitflips dans javascript (Ars, papier). Il a juste fallu reverse la fonction de hash du L3 pour ne pas avoir remplir le L3 pour tre sr de virer une ligne. Aprs, pour exploiter la faille dans javascript, a me parat tre une autre paire de manche.

    A priori a a t rpar dans la DDR4 en comptant les accs aux lignes et en rafraichissant les lignes adjacentes si a ressemble du hammering. Pour la DDR3 il suffit juste de diviser l'intervalle de refresh par 2 ou 4 :3
    On ne parlera jamais assez des RISC lis la vente d'ARM.

  4. #4
    Alimentons le topic avec la fameuse faille critique de la techno AMT prsente sur les processeurs Intel de gamme pro depuis 10 ans :
    https://www.embedi.com/files/white-p...-is-Silent.pdf

    Alors qu'un attaquant puisse contrler distance n'importe quelle machine mme teinte branche au rseau, et que la faille soit passe inaperue aussi longtemps, c'est un peu embarrassant. Mais quand on voit la gueule de la faille et la simplicit de l'attaque...

    Ironiquement, c'est probablement la faute un audit de scurit qui a demand au programmeur de changer son strcmp en strncmp...

  5. #5
    Je pense que c'est by design : Si tu as oubli ton mot de passe c'est plus simple. J'imagine que c'est design comme a pour qu'Intel contrle et le HW et le SW, mais vu la tronche du "contrle" c'tait peut-tre pas la peine...
    On ne parlera jamais assez des RISC lis la vente d'ARM.

  6. #6
    Comme on parle dj des failles Meltdown et Spectre dans tous les autres topics, il est temps que celui-ci s'y mette.

    On a donc diffrentes attaques par canaux cachs sur la microarchitecture. Elles permettent de contourner les mcanismes de protection mmoire en exploitant les effets de bords d'instructions sur un chemin spculatif. Notamment les chargements mmoire faits sur le wrong path qui changent l'tat du cache. On peut par exemple reconstituer les donnes une adresse protge arbitraire, et a marche particulirement bien sur les CPU Intel.

    Au del des failles proprement dites qui peuvent tre patches au cas par cas, je pense que c'est une remise en cause profonde de la microarchitecture la papa des annes 1990. Les failles n'exploitent pas juste quelques bugs qu'on aurait laiss pass par accident : elles exploitent surtout le fonctionnement normal d'un processeur superscalaire, et elles sont videntes a posteriori. C'est simplement que jusqu'ici la scurit de l'information n'entre mme pas en ligne de compte pour la plupart des microarchitectes (au moins dans la communaut acadmique, mais l'existence des failles en question laisse penser que c'est pareil dans l'industrie).

    Mais avec le bruit que fait cette affaire, a va surement changer. a peut avoir l'effet d'un nouveau bug du Pentium, et obliger les architectes tre un peu plus rigoureux et regarder autre chose que la perf et le power.

  7. #7
    J'avoue que j'ai du mal mesurer la porte relle des attaques : on peut faire de l'attaque de masse utilisable sans disposer des moyens de la NSA pour traiter les retours, ou c'est des attaques cibles et il y a la dernire grille de sret, la chance, qui protge pas mal ?

    Et parce qu'il faut bien aider les amis :
    La provence

  8. #8
    La chance ne suffit pas en scurit, surtout sur un processeur plusieurs GHz. Mme si l'attaque ne sort qu'un seul bit une fois sur un million, tu as tout le temps de rcuprer toutes les cls de chiffrement que tu veux en quelques secondes.
    On peut aussi objecter que les attaques sont trs spcifiques un processeur et un superviseur, OS, ou navigateur. Admettons que tu aies fait une attaque qui marche sur Skylake et Windows 10, ou sur Skylake et Firefox, ou sur A10 et iOS... ah bah tu pwnes dj un parc install de centaines de millions de machines. Le retour sur investissement d'une attaque c'est le produit nombre de cibles * importance des cibles. Si ce produit est grand, tu trouveras toujours assez de hackers prts y passer le temps qu'il faut.

    Une seule faille de ce genre ne suffit pas faire un Skynet, mais quand tu la combines avec le reste de ton catalogue d'attaques connues, il y a moyen de construire des malwares qui font vraiment chier.

  9. #9
    Oui mais si tu rcupres un dump mmoire (32Go sur mon PC perso) de l'ensemble des PC dans le mme type de config, tu traites comment pour trouver les cls ?

    Ou alors, l'attaque c'est
    Code:
    if CPUID=="Skylake" && OS.version=="Windows 10" && Browser.version=="Firefox 52.0 64bits" then
    data[]=getdatafromram;
    i=find("Ici ya la cl secrte",data);
    sendtohackerz(data[i]);
    endif;

    Et parce qu'il faut bien aider les amis :
    La provence

  10. #10
    Option 2. Une fois que tu sais o chercher, tu trouves.
    Et pour trouver o chercher, il y a d'autres attaques.

  11. #11
    Au moins on va peut-tre arrter de nous bassiner avec le machine learning ISCA

    Du grain moudre sur comment certains designers envisagent de patcher les failles en attendant les "vrais" correctifs (hardware, donc) : Intel, ARM
    On ne parlera jamais assez des RISC lis la vente d'ARM.

  12. #12
    Citation Envoy par Mgluglu Voir le message
    Comme on parle dj des failles Meltdown et Spectre dans tous les autres topics, il est temps que celui-ci s'y mette.

    On a donc diffrentes attaques par canaux cachs sur la microarchitecture. Elles permettent de contourner les mcanismes de protection mmoire en exploitant les effets de bords d'instructions sur un chemin spculatif. Notamment les chargements mmoire faits sur le wrong path qui changent l'tat du cache. On peut par exemple reconstituer les donnes une adresse protge arbitraire, et a marche particulirement bien sur les CPU Intel.

    Au del des failles proprement dites qui peuvent tre patches au cas par cas, je pense que c'est une remise en cause profonde de la microarchitecture la papa des annes 1990. Les failles n'exploitent pas juste quelques bugs qu'on aurait laiss pass par accident : elles exploitent surtout le fonctionnement normal d'un processeur superscalaire, et elles sont videntes a posteriori. C'est simplement que jusqu'ici la scurit de l'information n'entre mme pas en ligne de compte pour la plupart des microarchitectes (au moins dans la communaut acadmique, mais l'existence des failles en question laisse penser que c'est pareil dans l'industrie).

    Mais avec le bruit que fait cette affaire, a va surement changer. a peut avoir l'effet d'un nouveau bug du Pentium, et obliger les architectes tre un peu plus rigoureux et regarder autre chose que la perf et le power.
    J'ai eu un peu de mal comprendre ces deux papiers. N'tant pas trs dou en archi.
    Si j'ai bien compris, pour Meltdown c'est bas sur le fait que la diffrence entre Kernel et user c'est un simple bit qui change squentiellement durant l’accs l'un de ces espaces. Mais qu'avec les optimisations "out of order" une partie du code en aval, qui peut etre kernel du coups, va tre excut prventivement (et pas dans l'ordre du coups ) pour viter les goulets d’tranglement en amont. Mais sans utiliser la scurit qui va bien de flip flap de bit. Rsultat des courses : du code kernel se retrouve en stand bye dans un bout du CPU et peut tre observ par l'utilisateur.
    Je sens que je doit me gourer quelques part ^^. Si tu peut me corriger ^^.

    Pour le second si j'ai bien compris c'est trs proche, mais a utilise le fait que les CPU font de la prdiction sur le futur code excutable et donc qu'on peut les leurrer. Je n'ai pas forcement capt en quoi a cause un soucis de scurit par contre, un peu de mal sur celui ci.

    Dans les deux cas, en quoi a ne peut pas tre vit en dsactivant ces optimisation au niveau du firmware du cpu ? Ou alors il est impossible matriellement d’excuter un code sans ces optims ?

  13. #13
    Citation Envoy par Nilsou Voir le message
    J'ai eu un peu de mal comprendre ces deux papiers. N'tant pas trs dou en archi.
    Si j'ai bien compris, pour Meltdown c'est bas sur le fait que la diffrence entre Kernel et user c'est un simple bit qui change squentiellement durant l’accs l'un de ces espaces. Mais qu'avec les optimisations "out of order" une partie du code en aval, qui peut etre kernel du coups, va tre excut prventivement (et pas dans l'ordre du coups ) pour viter les goulets d’tranglement en amont. Mais sans utiliser la scurit qui va bien de flip flap de bit. Rsultat des courses : du code kernel se retrouve en stand bye dans un bout du CPU et peut tre observ par l'utilisateur.
    Je sens que je doit me gourer quelques part ^^. Si tu peut me corriger ^^.
    Toutes les attaques fonctionnent mme si les instructions sont excutes dans l'ordre. Ce qu'elles exploitent c'est le fait que le processeur prdit la direction des branchements bien avant d'avoir calcul la vraie valeur de leur condition, et commence excuter le code sur la branche qu'il estime la plus probable. S'il se goure, il rpare l'tat architectural du processeur : les registres et les accs mmoire en vol, pour faire comme si le code spculatif n'avait jamais t excut. Nanmoins, il peut rester des traces sous la forme d'effet de bord sur le cache.

    Les attaques ont cette forme-l :
    Code:
    flush_cache();
    if(cond) {
      x = array1[array2[i]];
    }
    probe_cache();
    Le droulement est le suivant :
    - L'attaquant commence par entrainer le prdicteur de branchements en excutant le code avec cond qui vaut true, et un index i inoffensif.
    - Puis remplit tout le cache avec des donnes, genre en parcourant un tableau assez grand.
    - Puis met cond false, et i calcul pour que array2[i] tombe sur l'adresse secrte qu'on cherche lire.
    - Le processeur prdit que cond sera vrai comme avant, et commence excuter l'intrieur du if. Il accde la donne secrte array2[i], et dans la foule lance un chargement mmoire en l'utilisant comme adresse. La donne remonte dans le cache. Puis la mauvaise prdiction de branchement est corrige, mais la donne est toujours dans le cache.
    - Enfin, on accde de nouveau aux donnes qu'on avait mis dans le cache, en mesurant le temps que a prend chaque fois. Si un lment rencontre un dfaut de cache, c'est qu'il a t remplac par l'lment array1[array2[i]]. Comme tu sais lequel c'est, tu rcupres des infos sur l'adresse, c'est--dire des bits de array2[i], qui est le secret que tu voulais.

    Dans le cas de Meltdown, la faille des processeurs Intel est qu'ils continuent excuter le code spculatif mme si le processus n'a pas le droit d'accder array2[i], contrairement AMD par exemple. C'tait considr comme "pas grave" puisque les architectes considrent que le code excut spculativement n'a pas d'effet visible niveau architectural.

    Spectre c'est plus vicieux. Tu attaques un branchement indirect dans le kernel, par exemple un appel sur un pointeur de fonction. Tu entraines ton prdicteur indirect pour qu'il saute une adresse qui correspond par exemple une instruction load [r1]. Sur le mme principe, il se produit un accs spculatif [r1], ce qui te permet de rcuprer des infos sur la valeur de r1. Et ce coup-ci tu fais excuter la branche spculative par le kernel, qui a toutes les permissions qu'il faut.

    tl;dr: c'est la faute l'IA dans les processeurs.

    Dans les deux cas, en quoi a ne peut pas tre vit en dsactivant ces optimisation au niveau du firmware du cpu ? Ou alors il est impossible matriellement d’excuter un code sans ces optims ?
    Si on dsactive la prdiction de branchement et les caches, on retourne l'age de pierre.

  14. #14
    Citation Envoy par Mgluglu Voir le message
    Si on dsactive la prdiction de branchement et les caches, on retourne l'age de pierre.
    Pas si sr. On pourrait faire un processeur avec des coeurs in-order connects directement sur un bus circulaire par exemple.
    Citation Envoy par Sidus Preclarum Voir le message
    Ben du caramel pas sucr alors...
    "Avant, j'tais dyslexique, masi aujorudh'ui je vasi meiux."

  15. #15
    Pourquoi in-order?
    On ne parlera jamais assez des RISC lis la vente d'ARM.

  16. #16


    Moui en effet j'ai mentalement confus les problmatiques. Veuillez oublier mon message prcdent.
    Citation Envoy par Sidus Preclarum Voir le message
    Ben du caramel pas sucr alors...
    "Avant, j'tais dyslexique, masi aujorudh'ui je vasi meiux."

  17. #17
    Citation Envoy par Mgluglu Voir le message
    S'il se goure, il rpare l'tat architectural du processeur : les registres et les accs mmoire en vol, pour faire comme si le code spculatif n'avait jamais t excut. Nanmoins, il peut rester des traces sous la forme d'effet de bord sur le cache.
    Pourquoi exactement du coups ?
    Si j'ai bien compris, sans cet effet de bord Spectre et Meltdown n'existent plus ...

    Citation Envoy par Mgluglu Voir le message
    - Le processeur prdit que cond sera vrai comme avant, et commence excuter l'intrieur du if. Il accde la donne secrte array2[i], et dans la foule lance un chargement mmoire en l'utilisant comme adresse. La donne remonte dans le cache. Puis la mauvaise prdiction de branchement est corrige, mais la donne est toujours dans le cache.
    - Enfin, on accde de nouveau aux donnes qu'on avait mis dans le cache, en mesurant le temps que a prend chaque fois. Si un lment rencontre un dfaut de cache, c'est qu'il a t remplac par l'lment array1[array2[i]]. Comme tu sais lequel c'est, tu rcupres des infos sur l'adresse, c'est--dire des bits de array2[i], qui est le secret que tu voulais.
    Pour le premier truc en gras : Du coups en quoi n'est-il pas possible t’intgrer au niveau "firmware" ou mme OS le fait d'automatiquement craser le cache (ou juste les bits dangereux) aprs ce type d’opration ?
    Pour la seconde partie en gras, pourquoi "comme tu sais lequel c'est", tu peut lire le cache sans soucis ce stade j'imagine que c'est ce que tu veut dire ?

    J'ai aussi une question plus gnrale. Pourquoi la scurit d’accs une adresse interdite n'est pas activ durant l’excution de code prdictif ? a a l'air con comme question, mais c'est pourtant une faille immense, et je ne comprends pas bien pourquoi elle est prsente ... parce que pendant l’excution du code prdictif il sait bien qu'il accde a une adresse interdite.
    Ou alors c'est parce que l'autorisation pourrait etre donn juste avant le segment prdit donc il le fait quand mme. Et qu'il prfre prdire parce que ce genre de cas est trop courant, le dsactiver reviendrait perdre normment en perf ?
    Dernire modification par Nilsou ; 14/01/2018 14h01.

  18. #18
    Citation Envoy par Mgluglu Voir le message
    Si on dsactive la prdiction de branchement et les caches, on retourne l'age de pierre.
    Nanmoins si c'tait possible de l'interdire pour certaines application alors il existe un patch simple la compilation pour certaines application critique (qui n'aurais rien faire de la perfs, par exemple).

    Citation Envoy par Mgluglu Voir le message
    Spectre c'est plus vicieux. Tu attaques un branchement indirect dans le kernel, par exemple un appel sur un pointeur de fonction. Tu entraines ton prdicteur indirect pour qu'il saute une adresse qui correspond par exemple une instruction load [r1]. Sur le mme principe, il se produit un accs spculatif [r1], ce qui te permet de rcuprer des infos sur la valeur de r1. Et ce coup-ci tu fais excuter la branche spculative par le kernel, qui a toutes les permissions qu'il faut.
    J'ai du mal a capter spectre. Si tu part d'un code s’excutant dans le kernel (car dans ton exemple le branchement indirect et sa destination load[r1] sont sans le kernel si j'ai bien capt), comment peut tu employer la mme stratgie que ce que tu a dcrit plus haut. Dans ce que tu a dcrit plus haut c'est la facult qu'a l'utilisateur de mesurer le temps d’accs et de lire la valeur du cache qui joue, donc sa facult finalement a avoir la mainmise sur le cot utilisateur du code. Ici je vois mal comment ce serait possible puisque qu'il faudrait tre dans le kernel pour faire la mesure ... (et que si tu a du code a toi dans le kernel, autant excuter toi mme ce que tu a envie directement ^^)

    Dans les deux cas, ce type de code semble facilement reprable/typique non ? Ne serait-il pas possible de simplement les dtecter faon virus ?
    Dernire modification par Nilsou ; 14/01/2018 14h14.

  19. #19
    Citation Envoy par Nilsou Voir le message
    Pourquoi exactement du coups ?
    Si j'ai bien compris, sans cet effet de bord Spectre et Meltdown n'existent plus ...
    Il y a toujours des effets de bords parce qu'on ne sait pas remonter le temps, et pire, parce que le temps linaire est un mensonge.

    Idalement, il faudrait restaurer l'tat de tous les caches, les buffers internes, et mme les row buffers dans les puces mmoires, pour faire comme si la spculation n'avait jamais eu lieu. Sachant que pendant ce temps les autres threads sur les autres cœurs ont fait quelques centaines ou milliers d'accs mmoire d'autres endroits ou mme au mme endroit dans ces caches et buffers. Mme si tu arrives restaurer un tel tat, a n'empche pas le code spculatif d'avoir caus des interfrences sur les accs mmoire des autres threads, en changeant lgrement leur timing. a suffit pour faire fuir de l'information qu'un attaquant pourra rcuprer en dtectant des petites variations de timing sur des squences d'oprations bien choisies.

    Pour le premier truc en gras : Du coups en quoi n'est-il pas possible t’intgrer au niveau "firmware" ou mme OS le fait d'automatiquement craser le cache (ou juste les bits dangereux) aprs ce type d’opration ?
    Si tu agis a posteriori c'est trop tard : tu as du vincer une donne qui tait auparavant dans le cache pour la remplacer par celle que tu as charg spculativement, et tu ne sais mme plus laquelle c'tait. Par contre l'attaquant peut dtecter que tu as dgag la donne qu'il avait soigneusement plac cet endroit.

    En agissant a priori au niveau matriel, c'est srement possible pour le cache L1 : on pourrait ajouter des buffers pour ne mettre jour le cache qu'au moment du retirement des instructions. Mais a ne fait que repousser le problme aux autres caches, L2, L3, et L1 des autres cœurs.
    Par exemple tu peux exploiter le protocole de cohrence de caches pour fuiter de l'info. Quand le core 1 charge une donne que le core 2 a modifi dans son propre cache, a peut forcer par exemple le core 2 mettre jour le cache partag avec la version modifie. Paf, effet de bord visible mme si le core 1 change d'avis juste aprs.

    Pour la seconde partie en gras, pourquoi "comme tu sais lequel c'est", tu peut lire le cache sans soucis ce stade j'imagine que c'est ce que tu veut dire ?
    Oui, tu parcours ton tableau jusqu' trouver la diffrence de timing, l'index que tu obtiens correspond aux bits de poids faibles de la valeur que tu cherches. Tu exploites le fait que sur un cache set-associative, les entres sont indexe par les bits de poids faible des adresses. Deux adresses qui ont les mmes bits de poids faibles vont se retrouver en conflit et se battre pour le mme set.
    Le code de l'exploit est relativement lisible d'ailleurs :
    https://github.com/IAIK/meltdown/blo...ibkdump.c#L507

    J'ai aussi une question plus gnrale. Pourquoi la scurit d’accs une adresse interdite n'est pas activ durant l’excution de code prdictif ? a a l'air con comme question, mais c'est pourtant une faille immense, et je ne comprends pas bien pourquoi elle est prsente ... parce que pendant l’excution du code prdictif il sait bien qu'il accde a une adresse interdite.
    Ou alors c'est parce que l'autorisation pourrait etre donn juste avant le segment prdit donc il le fait quand mme. Et qu'il prfre prdire parce que ce genre de cas est trop courant, le dsactiver reviendrait perdre normment en perf ?
    Ce point prcis, oui, a semble une connerie, spcifique aux archis Intel et quelques autres.
    Enfin quasiment tout le monde rsume Meltdown en "Intel ne vrifie pas les permissions sur le code spculatif, lol", mais il semble que c'est plus compliqu que a. C'est plutt : sous certaines conditions, le processeur va accder au cache et faire suivre la donne aux instructions suivantes avant d'avoir vrifi les permissions du TLB. Je souponne que ce soit li un mcanisme de prdiction de voie agressif, qui accde au donnes du cache avant mme d'avoir la confirmation des tags et du TLB.

    Citation Envoy par Nilsou Voir le message
    Nanmoins si c'tait possible de l'interdire pour certaines application alors il existe un patch simple la compilation pour certaines application critique (qui n'aurais rien faire de la perfs, par exemple).
    C'est essentiellement ce que fait Intel pour patcher le kernel contre l'attaque Spectre par injection de code spculatif : ils ont une moulinette qui marque les branchements considrs comme vulnrables et place des barrires de spculation qui empche la prdiction.

    Quelques ordres de grandeur : entre 1 instruction sur 3 et 1 instruction sur 5 est un branchement. Une microarchi moderne a 200 instructions en vol, dont 50 branchements.

    J'ai du mal a capter spectre. Si tu part d'un code s’excutant dans le kernel (car dans ton exemple le branchement indirect et sa destination load[r1] sont sans le kernel si j'ai bien capt), comment peut tu employer la mme stratgie que ce que tu a dcrit plus haut. Dans ce que tu a dcrit plus haut c'est la facult qu'a l'utilisateur de mesurer le temps d’accs et de lire la valeur du cache qui joue, donc sa facult finalement a avoir la mainmise sur le cot utilisateur du code. Ici je vois mal comment ce serait possible puisque qu'il faudrait tre dans le kernel pour faire la mesure ... (et que si tu a du code a toi dans le kernel, autant excuter toi mme ce que tu a envie directement ^^)
    C'est a qui est beau. Tu pilotes du code existant dans le kernel, mais depuis l'extrieur. Par exemple, tu peux :
    1. Entraner le prdicteur de branchements indirects dans ton code utilisateur non-privilgi : code inoffensif qui ne fait que des sauts indirects genre appels de fonctions virtuelles.
    2. Faire un appel systme inoffensif, genre un write sur stdout. L'excution spculative se droule en mode kernel.
    3. De retour en mode utilisateur, tu examines ce qui est prsent dans le cache comme pour l'attaque Meltdown. Code inoffensif qui ne fait que des accs tableau (et quelques lectures de timer).

    Dans les deux cas, ce type de code semble facilement reprable/typique non ? Ne serait-il pas possible de simplement les dtecter faon virus ?
    C'est a qui est beau (bis). Le code Meltdown/Spectre 1, c'est un truc de la forme :
    Code:
    unsigned int a[n], b[m];
    if(i < n) {
      x = b[a[i]];
    }
    On a tous dj crit ce code pour des raisons totalement lgitimes. Il n'y a absolument rien de suspect l-dedans. On peut mme ajouter un test que a[i] < m, a marche toujours.

  20. #20
    Merci pour la rponse, j'ai pas mal appris ^^.

    Autre question que je me posais. Une solution ne serait-elle pas d'uniformiser les temps d’accs ? En insrant des variations de temps alatoire dans les accs au cache par exemple ? J'imagine que l'OS comme n'importe quelle micro-code bas niveau pourrait le faire sans soucis, et donc interdire, en change de perfs, la dduction par temps d’accs.

    Pour l'histoire de la dduction en tant que virus. Je pensais au fait que quelque part il va devoir insrer du code pour mesurer les temps d’accs justement. Et du code pour remplir tout le cache ET du code pour le lire en entier.
    L'ensemble doit tre possible dtecter ...

    Par ailleurs, il faut aussi que les mecs aient accs une appli largement distribue de faon lgitime. C'est surement le plus dure ...

  21. #21
    De rien, pardon pour le pav...

    Citation Envoy par Nilsou Voir le message
    Autre question que je me posais. Une solution ne serait-elle pas d'uniformiser les temps daccs ? En insrant des variations de temps alatoire dans les accs au cache par exemple ? J'imagine que l'OS comme n'importe quelle micro-code bas niveau pourrait le faire sans soucis, et donc interdire, en change de perfs, la dduction par temps daccs.
    La raison d'tre du cache est de rendre l'accs aux donnes qui sont dans le cache plus rapides qu' celles qui n'y sont pas. Si on uniformise les temps d'accs, autant ne pas avoir de cache du tout. Ce n'est pas raisonnable de passer tous les accs de 3 300 cycles. Mme si a l'tait, il resterait d'autres structures comme les TLB ou les row buffers en DRAM comme canaux cachs exploitables.

    Par contre, plus simplement, tu peux ajouter de l'ala aux timers pour les rendre moins prcis, et donc plus difficile utiliser pour des mesures de latence. C'est ce qui est fait dans certains moteurs Javascript. Mais a se contourne : mme un timer imprcis suffit pour dtecter un biais statistique, moyennant suffisamment de mesures. Mme sans timer du tout on peut fabriquer un compteur de temps assez prcis avec un thread qui fait un while(1) { i++; } sur un autre cur.

    Pour l'histoire de la dduction en tant que virus. Je pensais au fait que quelque part il va devoir insrer du code pour mesurer les temps daccs justement. Et du code pour remplir tout le cache ET du code pour le lire en entier.
    L'ensemble doit tre possible dtecter ...
    Le code qui remplit le cache et le lit en entier, c'est une boucle for qui lit une colonne dans une matrice. On ne va pas pouvoir interdire tous les parcours de tableaux. On pourrait ventuellement interdire tous les timers, mais comme dit plus haut a ne suffirait pas.

    Pour vraiment se prmunir des fuites d'info par le timing, il faut se limiter aux programmes dont le comportement est entirement spcifi. C'est possible pour du code squentiel, sans I/O. Mais les programmes de la vraie vie ont une fcheuse tendance vouloir interagir avec le monde extrieur.

    Par ailleurs, il faut aussi que les mecs aient accs une appli largement distribue de faon lgitime. C'est surement le plus dure ...
    Javascript.

  22. #22
    J'avais pas pens Javascript en effet...
    Un ptit no-script va donc devenir obligatoire...

  23. #23
    Au dela du "on peut pas remonter le temps dans un superscalaire multicoeur", qui est une faille non-patchable a ce jour, y'a quand mme un truc que je comprend pas pour spectre/meltdown: pourquoi le code spculatif est excut en mode kernel ?
    tu fais un accs mmoire, et spculation ou pas, tu devrai pas sortir de ce que te dit ta table de translation, nan ?
    La guerre, ce sont des idiots qui tapent sur des abrutis pour des raisons stupides.
    Citation Envoy par Gwynyam Voir le message
    C'est pas du communautarisme primaire, mais plutt un mal de front chronique d aux facepalm incessants.

  24. #24
    De ce que j'avais compris ce n'est pas execut en mode kernel, c'est plutot que si tu a du code comme ceci :
    Autorisation d'accs en mode kernel
    -------------------
    Appel d'une partie en mode kernel
    -------------------

    Le code spculatif entre le tirets ne sait pas si l'autorisation d’accs pour le kernel existe ou non. Il suppose alors que oui, et si il s'est tromp il n’excutera simplement pas la partie et renverra une erreur de droit, j'imagine. Sauf qu'en attendant il l'a quand mme execut ^^.

    Mais si c'est un code user dans la partie en question il sera surement execut en mode user j'imagine, sans plus de prcision... je n'avais pas compris que l'execution spculative tait systmatiquement en mode kernel.

  25. #25
    Au dela du "on peut pas remonter le temps dans un superscalaire multicoeur", qui est une faille non-patchable a ce jour, y'a quand mme un truc que je comprend pas pour spectre/meltdown: pourquoi le code spculatif est excut en mode kernel ?
    tu fais un accs mmoire, et spculation ou pas, tu devrai pas sortir de ce que te dit ta table de translation, nan ?
    A priori c'est plutt de Meltdown que tu parles. Dans tous les cas, plus facile dire qu' faire, probablement. Enfin, il y a plusieurs possibilits...

    1. Intel (et les autres*) n'ont pas du tout pens ce cas et alors d'un point de vue architectural, c'est pas dconnant de laisser les instructions qui dpendent d'un load qui fait une faute de permission s'excuter, puisque a vite d'ajouter du hard pour grer ce cas particulier dans le pipe, et de toute faon, tout ce qui est illgal se fait jeter du pipeline quand le load avec la faute devient visible par le software (commit).
    2. Intel (et les autres) ont vu le coup mais ont pens que a serait inexploitable et n'ont donc pas voulu investir le hardware pour fermer le side-channel.


    En effet, il faut bien voir que sur la majorit des archi haute performances, le premier load (celui qui accde une adresse kernel sans avoir le droit) part vert le pipeline qui excute les loads, puis les instructions qui en dpendent partent vers leurs pipelines d'excutions respectifs avant de savoir si le premier load est lgal ou non. Du coup, pour fermer le side channel, il faut du hard pour "annuler" l'excution des instructions dpendantes (a c'est chaud je pense), ou pour rendre l'excution inoffensive : par exemple, si le load est illgal, il renvoie 0 au lieu de renvoyer la valeur lue dans le cache (a c'est plus facile, c'est peut-tre ce que fait AMD par exemple). Cependant, mme la dernire technique rajoute un multiplexeur dans le chemin critique du bypass ("si lgal alors valeur du cache sinon 0"), et peut donc diminuer la frquence maximale atteignable par le CPU si le bypass est le chemin critique du CPU. Et du coup le marketing n'est pas content.

    De ce que j'avais compris ce n'est pas execut en mode kernel, c'est plutot que si tu a du code comme ceci :
    Autorisation d'accs en mode kernel
    -------------------
    Appel d'une partie en mode kernel
    -------------------

    Le code spculatif entre le tirets ne sait pas si l'autorisation daccs pour le kernel existe ou non. Il suppose alors que oui, et si il s'est tromp il nexcutera simplement pas la partie et renverra une erreur de droit, j'imagine. Sauf qu'en attendant il l'a quand mme execut ^^.

    Mais si c'est un code user dans la partie en question il sera surement execut en mode user j'imagine, sans plus de prcision... je n'avais pas compris que l'execution spculative tait systmatiquement en mode kernel.
    Alors en effet l'excution spculative n'a pas systmatiquement les permissions du kernel, elle a les permissions du contexte courant. Pour Meltdown, du code user fait un accs une adresse privilgie et prendra une faute de permission, mais aura excut "au del" de la faute (chez Intel et d'autres). Notons que l'excution spculative n'a pas d'impact sur ce qui est visible pour le programmeur (l'tat architectural), mais elle a un impact sur le cache notamment, d'ou le side channel en timant les accs mmoire aprs avoir dclench la faute.

    *Parce que bon, tout le monde rle sur Intel pour Meltdown mais des CPUs d'IBM, Sun et ARM sont vulnrables aussi, il me semble.
    On ne parlera jamais assez des RISC lis la vente d'ARM.

Rgles de messages

  • Vous ne pouvez pas crer de nouvelles discussions
  • Vous ne pouvez pas envoyer des rponses
  • Vous ne pouvez pas envoyer des pices jointes
  • Vous ne pouvez pas modifier vos messages
  •