Crunchez vos adresses URL
|
Calculez la conso électrique de votre PC
|
Hébergez vos photos
Affichage des résultats 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 différentes failles connus des produits et c'est assez dommage car vraiment très intéressant. Bon ok, parfois c'est hard à comprendre .

    J'ouvre le "bal" avec la dernière faille trouvé sur de très nombreux processeurs Intel au niveau de la mémoire SSM du processeur.

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

    Un article en français 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'intéresse énormément, je te MP.

  2. #2
    L'exploit est joli, mais leur deuxième tentative (exécuter 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 régulièrement des failles qui permettent de passer en SMM. La gestion de la mémoire physique entre les différents périphériques est tellement complexe et dépend de tellement de constructeurs différents qu'il y a toujours des trous. Genre une PCI Option ROM d'un composant quelconque qui a une faille dans un coin. Vouloir protéger de la mémoire sans vrai mécanisme de protection mémoire, c'est forcément casse-gueule.

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

  3. #3
    Obligatory rowhammer:

    Quand on lit de façon répétée une ligne (row, ~8KiO) de DRAM, ça a tendance à modifier des bits dans les lignes adjacentes (le papier ISCA, même si c'était un problème relativement connu). Google nous a fait une démo en début d'année sur comment s'en servir pour passer root (http://googleprojectzero.blogspot.fr...g-to-gain.html).

    En général, on considérait qu'il était nécessaire d'avoir clflush pour que rowhammer fonctionne, histoire d'avoir assez d'accès à 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 sûr de virer une ligne. Après, pour exploiter la faille dans javascript, ça me paraît être une autre paire de manche.

    A priori ça a été réparé dans la DDR4 en comptant les accès 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 liés à la vente d'ARM.

  4. #4
    Alimentons le topic avec la fameuse faille critique de la techno AMT présente 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 contrôler à distance n'importe quelle machine même éteinte branchée au réseau, et que la faille soit passée inaperçue 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 sécurité 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 contrôle et le HW et le SW, mais vu la tronche du "contrôle" c'était peut-être pas la peine...
    On ne parlera jamais assez des RISC liés à la vente d'ARM.

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

    On a donc différentes attaques par canaux cachés sur la microarchitecture. Elles permettent de contourner les mécanismes de protection mémoire en exploitant les effets de bords d'instructions sur un chemin spéculatif. Notamment les chargements mémoire faits sur le wrong path qui changent l'état du cache. On peut par exemple reconstituer les données à une adresse protégée arbitraire, et ça marche particulièrement bien sur les CPU Intel.

    Au delà des failles proprement dites qui peuvent être patchées au cas par cas, je pense que c'est une remise en cause profonde de la microarchitecture à la papa des années 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 sécurité de l'information n'entre même pas en ligne de compte pour la plupart des microarchitectes (au moins dans la communauté académique, 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 portée réelle 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 ciblées et il y a la dernière grille de sûreté, la chance, qui protège pas mal ?

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

  8. #8
    La chance ne suffit pas en sécurité, surtout sur un processeur à plusieurs GHz. Même si l'attaque ne sort qu'un seul bit une fois sur un million, tu as tout le temps de récupérer toutes les clés de chiffrement que tu veux en quelques secondes.
    On peut aussi objecter que les attaques sont très spécifiques à 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 déjà 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 prêts à 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 récupères un dump mémoire (32Go sur mon PC perso) de l'ensemble des PC dans le même type de config, tu traites comment pour trouver les clés ?

    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é secrète",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 arrêter 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 liés à la vente d'ARM.

  12. #12
    Citation Envoyé par Møgluglu Voir le message
    Comme on parle déjà des failles Meltdown et Spectre dans tous les autres topics, il est temps que celui-ci s'y mette.

    On a donc différentes attaques par canaux cachés sur la microarchitecture. Elles permettent de contourner les mécanismes de protection mémoire en exploitant les effets de bords d'instructions sur un chemin spéculatif. Notamment les chargements mémoire faits sur le wrong path qui changent l'état du cache. On peut par exemple reconstituer les données à une adresse protégée arbitraire, et ça marche particulièrement bien sur les CPU Intel.

    Au delà des failles proprement dites qui peuvent être patchées au cas par cas, je pense que c'est une remise en cause profonde de la microarchitecture à la papa des années 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 sécurité de l'information n'entre même pas en ligne de compte pour la plupart des microarchitectes (au moins dans la communauté académique, 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 trés doué en archi.
    Si j'ai bien compris, pour Meltdown c'est basé sur le fait que la différence entre Kernel et user c'est un simple bit qui change séquentiellement durant l’accès à 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 exécuté préventivement (et pas dans l'ordre du coups ) pour éviter les goulets d’étranglement en amont. Mais sans utiliser la sécurité qui va bien de flip flap de bit. Résultat 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 très proche, mais ça utilise le fait que les CPU font de la prédiction sur le futur code exécutable et donc qu'on peut les leurrer. Je n'ai pas forcement capté en quoi ça cause un soucis de sécurité par contre, un peu de mal sur celui ci.

    Dans les deux cas, en quoi ça ne peut pas être évité en désactivant ces optimisation au niveau du firmware du cpu ? Ou alors il est impossible matériellement d’exécuter 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 trés doué en archi.
    Si j'ai bien compris, pour Meltdown c'est basé sur le fait que la différence entre Kernel et user c'est un simple bit qui change séquentiellement durant l’accès à 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 exécuté préventivement (et pas dans l'ordre du coups ) pour éviter les goulets d’étranglement en amont. Mais sans utiliser la sécurité qui va bien de flip flap de bit. Résultat 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 même si les instructions sont exécutées dans l'ordre. Ce qu'elles exploitent c'est le fait que le processeur prédit la direction des branchements bien avant d'avoir calculé la vraie valeur de leur condition, et commence à exécuter le code sur la branche qu'il estime la plus probable. S'il se goure, il répare l'état architectural du processeur : les registres et les accès mémoire en vol, pour faire comme si le code spéculatif n'avait jamais été exécuté. Néanmoins, 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 déroulement est le suivant :
    - L'attaquant commence par entrainer le prédicteur de branchements en exécutant le code avec cond qui vaut true, et un index i inoffensif.
    - Puis remplit tout le cache avec des données, genre en parcourant un tableau assez grand.
    - Puis met cond à false, et i calculé pour que array2[i] tombe sur l'adresse secrète qu'on cherche à lire.
    - Le processeur prédit que cond sera vrai comme avant, et commence à exécuter l'intérieur du if. Il accède à la donnée secrète array2[i], et dans la foulée lance un chargement mémoire en l'utilisant comme adresse. La donnée remonte dans le cache. Puis la mauvaise prédiction de branchement est corrigée, mais la donnée est toujours dans le cache.
    - Enfin, on accède de nouveau aux données qu'on avait mis dans le cache, en mesurant le temps que ça prend à chaque fois. Si un élément rencontre un défaut de cache, c'est qu'il a été remplacé par l'élément array1[array2[i]]. Comme tu sais lequel c'est, tu récupères 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 à exécuter le code spéculatif même si le processus n'a pas le droit d'accéder à array2[i], contrairement à AMD par exemple. C'était considéré comme "pas grave" puisque les architectes considèrent que le code exécuté spéculativement 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 prédicteur indirect pour qu'il saute à une adresse qui correspond par exemple à une instruction load [r1]. Sur le même principe, il se produit un accès spéculatif à [r1], ce qui te permet de récupérer des infos sur la valeur de r1. Et ce coup-ci tu fais exécuter la branche spéculative 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 désactivant ces optimisation au niveau du firmware du cpu ? Ou alors il est impossible matériellement d’exécuter un code sans ces optims ?
    Si on désactive la prédiction de branchement et les caches, on retourne à l'age de pierre.

  14. #14
    Citation Envoyé par Møgluglu Voir le message
    Si on désactive la prédiction de branchement et les caches, on retourne à l'age de pierre.
    Pas si sûr. On pourrait faire un processeur avec des coeurs in-order connectés 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 liés à la vente d'ARM.

  16. #16


    Moui en effet j'ai mentalement confusé les problématiques. Veuillez oublier mon message précédent.
    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 Møgluglu Voir le message
    S'il se goure, il répare l'état architectural du processeur : les registres et les accès mémoire en vol, pour faire comme si le code spéculatif n'avait jamais été exécuté. Néanmoins, 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 Møgluglu Voir le message
    - Le processeur prédit que cond sera vrai comme avant, et commence à exécuter l'intérieur du if. Il accède à la donnée secrète array2[i], et dans la foulée lance un chargement mémoire en l'utilisant comme adresse. La donnée remonte dans le cache. Puis la mauvaise prédiction de branchement est corrigée, mais la donnée est toujours dans le cache.
    - Enfin, on accède de nouveau aux données qu'on avait mis dans le cache, en mesurant le temps que ça prend à chaque fois. Si un élément rencontre un défaut de cache, c'est qu'il a été remplacé par l'élément array1[array2[i]]. Comme tu sais lequel c'est, tu récupères 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’intégrer au niveau "firmware" ou même OS le fait d'automatiquement écraser le cache (ou juste les bits dangereux) après ce type d’opération ?
    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 générale. Pourquoi la sécurité d’accès à une adresse interdite n'est pas activé durant l’exécution de code prédictif ? Ça a l'air con comme question, mais c'est pourtant une faille immense, et je ne comprends pas bien pourquoi elle est présente ... parce que pendant l’exécution du code prédictif il sait bien qu'il accède a une adresse interdite.
    Ou alors c'est parce que l'autorisation pourrait etre donné juste avant le segment prédit donc il le fait quand même. Et qu'il préfère prédire parce que ce genre de cas est trop courant, le désactiver reviendrait à perdre énormément en perf ?
    Dernière modification par Nilsou ; 14/01/2018 à 14h01.

  18. #18
    Citation Envoyé par Møgluglu Voir le message
    Si on désactive la prédiction de branchement et les caches, on retourne à l'age de pierre.
    Néanmoins 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 Møgluglu 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 prédicteur indirect pour qu'il saute à une adresse qui correspond par exemple à une instruction load [r1]. Sur le même principe, il se produit un accès spéculatif à [r1], ce qui te permet de récupérer des infos sur la valeur de r1. Et ce coup-ci tu fais exécuter la branche spéculative 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’exécutant 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 même stratégie que ce que tu a décrit plus haut. Dans ce que tu a décrit plus haut c'est la faculté qu'a l'utilisateur de mesurer le temps d’accès 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 exécuter toi même ce que tu a envie directement ^^)

    Dans les deux cas, ce type de code semble facilement repérable/typique non ? Ne serait-il pas possible de simplement les détecter façon virus ?
    Dernière 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 linéaire est un mensonge.

    Idéalement, il faudrait restaurer l'état de tous les caches, les buffers internes, et même les row buffers dans les puces mémoires, pour faire comme si la spéculation 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'accès mémoire à d'autres endroits ou même au même endroit dans ces caches et buffers. Même si tu arrives à restaurer un tel état, ça n'empêche pas le code spéculatif d'avoir causé des interférences sur les accès mémoire des autres threads, en changeant légèrement leur timing. Ça suffit pour faire fuir de l'information qu'un attaquant pourra récupérer en détectant des petites variations de timing sur des séquences d'opérations bien choisies.

    Pour le premier truc en gras : Du coups en quoi n'est-il pas possible t’intégrer au niveau "firmware" ou même OS le fait d'automatiquement écraser le cache (ou juste les bits dangereux) après ce type d’opération ?
    Si tu agis a posteriori c'est trop tard : tu as du évincer une donnée qui était auparavant dans le cache pour la remplacer par celle que tu as chargé spéculativement, et tu ne sais même plus laquelle c'était. Par contre l'attaquant peut détecter que tu as dégagé la donnée qu'il avait soigneusement placé à cet endroit.

    En agissant a priori au niveau matériel, c'est sûrement 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 problème aux autres caches, L2, L3, et L1 des autres cœurs.
    Par exemple tu peux exploiter le protocole de cohérence de caches pour fuiter de l'info. Quand le core 1 charge une donnée 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 modifiée. Paf, effet de bord visible même si le core 1 change d'avis juste après.

    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 différence 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 entrées sont indexée par les bits de poids faible des adresses. Deux adresses qui ont les mêmes bits de poids faibles vont se retrouver en conflit et se battre pour le même 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 générale. Pourquoi la sécurité d’accès à une adresse interdite n'est pas activé durant l’exécution de code prédictif ? Ça a l'air con comme question, mais c'est pourtant une faille immense, et je ne comprends pas bien pourquoi elle est présente ... parce que pendant l’exécution du code prédictif il sait bien qu'il accède a une adresse interdite.
    Ou alors c'est parce que l'autorisation pourrait etre donné juste avant le segment prédit donc il le fait quand même. Et qu'il préfère prédire parce que ce genre de cas est trop courant, le désactiver reviendrait à perdre énormément en perf ?
    Ce point précis, oui, ça semble une connerie, spécifique aux archis Intel et quelques autres.
    Enfin quasiment tout le monde résume Meltdown en "Intel ne vérifie pas les permissions sur le code spéculatif, lol", mais il semble que c'est plus compliqué que ça. C'est plutôt : sous certaines conditions, le processeur va accéder au cache et faire suivre la donnée aux instructions suivantes avant d'avoir vérifié les permissions du TLB. Je soupçonne que ce soit lié à un mécanisme de prédiction de voie agressif, qui accède au données du cache avant même d'avoir la confirmation des tags et du TLB.

    Citation Envoyé par Nilsou Voir le message
    Néanmoins 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 spéculatif : ils ont une moulinette qui marque les branchements considérés comme vulnérables et place des barrières de spéculation qui empêche la prédiction.

    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’exécutant 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 même stratégie que ce que tu a décrit plus haut. Dans ce que tu a décrit plus haut c'est la faculté qu'a l'utilisateur de mesurer le temps d’accès 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 exécuter toi même ce que tu a envie directement ^^)
    C'est ça qui est beau. Tu pilotes du code existant dans le kernel, mais depuis l'extérieur. Par exemple, tu peux :
    1. Entraîner le prédicteur de branchements indirects dans ton code utilisateur non-privilégié : code inoffensif qui ne fait que des sauts indirects genre appels de fonctions virtuelles.
    2. Faire un appel système inoffensif, genre un write sur stdout. L'exécution spéculative se déroule en mode kernel.
    3. De retour en mode utilisateur, tu examines ce qui est présent dans le cache comme pour l'attaque Meltdown. Code inoffensif qui ne fait que des accès tableau (et quelques lectures de timer).

    Dans les deux cas, ce type de code semble facilement repérable/typique non ? Ne serait-il pas possible de simplement les détecter façon 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 déjà écrit ce code pour des raisons totalement légitimes. Il n'y a absolument rien de suspect là-dedans. On peut même ajouter un test que a[i] < m, ça marche toujours.

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •