Crunchez vos adresses URL
|
Rejoignez notre discord
|
Hébergez vos photos
Affichage des résultats 1 à 19 sur 19
  1. #1
    AMD propose une amélioration du x86 en introduisant des instructions qui permettent (notamment) de déterminer si des instructions provoquent des erreurs de branchement (par exemple) et donc de pouvoir modifier certains trucs en temps réel en fonction des problèmes

    ils indiquent que ce sera intégré dans des machines virtuelles (donc que ça optimisera pas mal de trucs, du coup)

    Vous en pensez quoi ? C'est viable ? Plus effiucace que d'optimiser au départ ?

    http://developer.amd.com/LWP

  2. #2
    C'est du performance monitoring comme ça existe depuis longtemps, mais rendu accessible en ring 3 (le monitoring actuel passe par des MSRs, et donc nécessite un accès ring 0).

    Dans l'absolu c'est la méthode la plus efficace pour profiler et optimiser, mais personne ne s'en sert, hormis peut-être par le biais des analyseurs de code fournis par Intel et AMD (V-Tune chez Intel, CodeAnalyst chez AMD).

  3. #3
    Ben, si ça passe en ring 3, ça pourrait être beaucoup plus utilisé, non ?

  4. #4
    C'est effectivement le truc qui irait bien avec le JIT de Java !

  5. #5
    C'est une bonne idee, surtout le fait d'avoir un mode secure qui permet de proteger un thread des observations que d'autres pouraient faire (tres important dans le cadre de la crypto).
    fefe - Dillon Y'Bon

  6. #6
    Y'avais pas des problèmes en se basant sur l'HT justement ?

    Comme quoi un thread pouvait observer un autre, et que du coup, ben ça mettais tout en vrac.

  7. #7
    Citation Envoyé par Franck@x86
    C'est du performance monitoring comme ça existe depuis longtemps, mais rendu accessible en ring 3 (le monitoring actuel passe par des MSRs, et donc nécessite un accès ring 0).

    Dans l'absolu c'est la méthode la plus efficace pour profiler et optimiser, mais personne ne s'en sert, hormis peut-être par le biais des analyseurs de code fournis par Intel et AMD (V-Tune chez Intel, CodeAnalyst chez AMD).
    Les MSR si j'ai bien compris c'est les registres permettant d'activer/désactiver des fonctionnalités spécifiques d'une archi sur les CPU, ( Instructions 64bits par ex) ?

  8. #8
    Citation Envoyé par claneys
    Les MSR si j'ai bien compris c'est les registres permettant d'activer/désactiver des fonctionnalités spécifiques d'une archi sur les CPU, ( Instructions 64bits par ex) ?
    oui entre autres, mais les MSR regroupent par définition tous les registres spécifiques au processeur (msr = machine-specific register, ou encore model-specific register). En ceci ils se différencient des registres de contrôle (CR) dont les fonctions sont communes à tous les CPUs.

    On trouve entre autres dans les MSR :
    - la gestion des MTRR ( http://en.wikipedia.org/wiki/Memory_...ange_Registers )
    - la gestion de certaines fonctions internes.
    - des compteurs (TSC, compteurs de performances ...)

    L'accès ring3 simplifie les choses, mais pas tant que ça. Windows propose des fonctions pour accéder aux MSR, elles nécessitent les droits admin certes, mais permettent de se passer d'un driver en mode kernel. Ce n'est donc pas si contraignant que ça, et je ne sais pas si ce seul fait suffise à démocratiser leur utilisation. D'autant que chez AMD la gestion des compteurs de performance est déjà une des plus simples.

  9. #9
    Citation Envoyé par Lissyx
    Y'avais pas des problèmes en se basant sur l'HT justement ?

    Comme quoi un thread pouvait observer un autre, et que du coup, ben ça mettais tout en vrac.
    Oui, ils arrivent à faire des déductions sur la valeur d'une clé de chiffrement grâce aux temps d'exécution d'un process espion, en se basant sur le fait que la performance de ce process va être impacté par le travail qu'est en train de faire le process crypto.
    Pour l'HT, je crois que c'est en fonction des unités utilisées, puisqu'elles sont mutualisées dans ce cas entre les 2 process.
    Ca marche aussi avec le cache (injection d'une grosse quantité de données de référence dans le L2, attente de plusieurs cycles afin qu'elle soit en partie flushée par le process crypto, puis détermination des données remplacées en déduisant les cache hit / miss à partir des temps d'exécution du process espion).

    Alors, effectivement, la sureté de leur monitoring doit être béton (bien que le danger étant je pense plus au niveau de la fourniture du service par l'OS)

  10. #10
    Le probleme n est pas seulement lie a HT, il est potentiel pour tous les processeurs disposant de plusieurs thread hardware ayant acces a des ressources partagees (dual-quad cores avec caches partages par ex). HT partageant beaucoup plus de ressources cela donne juste plus d'opportunites. La fuite de metadata est un des principaux risques de la crypto moderne.
    fefe - Dillon Y'Bon

  11. #11
    Ceci étant, avant d'avoir un rootkit qui soit script-kiddies proof, les risques sont limités

  12. #12
    Je crois qur ces trucs sont encore au niveau du "proof of concept", il ne me semble pas avoir vu de mise en application.

    Pour que ça marche il faudrait être sûr qu'il n'y a pas d'autres process qui pourraient s'intercaler.

  13. #13
    J ai vu de mes yeux un crack (complet) de cle 64 bits en 3.4s dans un environnement realiste.
    fefe - Dillon Y'Bon

  14. #14
    mais rien d'utilisable par le premier venu ?

  15. #15
    Non assuremment, la conception de tels patterns de déduction est clairement très complexe, bien plus qu'un exploit classique.
    Du coup, ca doit être bien plus onéreux qu'un banal 0day... :whistle:

  16. #16
    Citation Envoyé par Lissyx
    mais rien d'utilisable par le premier venu ?
    genre lancer hack.exe et attendre ? Pas plus dur que ca la difficulte etant juste d avoir acces a un account sur la machine.
    fefe - Dillon Y'Bon

  17. #17
    Oui, mais le 'hack.exe', soit il existe déjà, soit il faut le faire. (...)

    C'est bien ce que j'entends par utilisable par le premier venu : des 0-day ou autres qui traineraient entre les mains du premier script-kiddie venu.

  18. #18
    L'isolation permettra surtout limiter les mesures sur un seul thread.
    Avec le monitoring actuel, j'arrive pas à limiter la mesure à un thread. Pourtant les softs constructeurs le font, donc y'a moyen.
    Enfin avec les nouvelles fonctions ça semble plus simple, et c'est tant mieux.

  19. #19
    Citation Envoyé par fefe
    J ai vu de mes yeux un crack (complet) de cle 64 bits en 3.4s dans un environnement realiste.
    Intéressant, le crack c'était sur quel soft ?

    Cependant, je pense que ce genre d'exploits ne sera pas trop utilisé pour compromètre une machine, mais plustôt pour récupérer des clefs genre celle de la protection AVC des HD-DVD et autre systèmes a DRM.

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
  •