Crunchez vos adresses URL
|
Calculez la conso lectrique de votre PC
|
Hbergez vos photos
Affichage des rsultats 1 19 sur 19
  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.

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
  •