pas mal, comme tu dis faut pousser encore un peu tout ca.
En ce qui concerne le code + propre, tu peux utiliser les intrinsics du compilo ie. __vmx_write, include intrin.h (j ai eu qques soucis avec certains d entre eux non definis, je suppose que j utilisais une version batarde du ddk/cl).
Pour ton application de monitoring des io ports c’est pas mal… comme t’es dans windows, et avec un peu de boulot si pas deja fait, tu peux pousser le bouza en enumerant les devices PCI et leur plage memoire, pour monitorer aussi les memory mapped io, ca te ferait un truc vraiment pas mal.
D ailleurs tu arrives a appeler des fonctions de ntos depuis l’hyperviseur? Si oui, t as quoi comme limitation? Et avec PAE enable sur l’host, t as des problemes pour switch?
En tous cas c’est cool, y a beau avoir des projets similaires existants, y a tres peu d applications au dessus de ca, comme si l hyperviseur c’etait la fin en soi… vivement le code.
Merci pour l’astuce des intrinsics du compilo, je savais qu’ils en existait mais je ne savais pas ou les trouver, par contre je ne vois pas le intrin.h dans le dossier « inc » de mon WDK (version 6001.18001) par contre il apparaît bien dans les includes de mon Visual Studio C 2008 comme dit ici , la et la. Il existe bien les fichiers : emmintrin.h, mmintrin.h et xmmintrin.h dans mon WDK mais ils servent aux extensions MMX et SSE3. Bref de toute façon j’ai codé mes propres wrappers VMX dans des fichiers .asm qui vont aussi servir à vérifier que l’instruction VMX s’est bien déroulée en regardant le statut de l’eflags.
Concernant le monitoring des memory mapped I/O, j’avoue que je ne me suis pas encore penché dessus, d’après ce que j’ai lu et compris, il faudrait retrouvé les PTE des memory mapped I/O, les marqués non-present puis trapper les exceptions lors des accès sur ceux ci avec l’hyperviseur, ca serait la seule solution veux que le VMX ne peut faire la différence entre un accès mémoire sur un adressage physique qui correspond à la de RAM et un adressage physique qui correspond à un memory mapped I/O … Je verrais ça après je pense :p
Sinon quand je suis dans le contexte de l’hyperviseur je me retrouve dans le cas d’un driver normal et je peux donc avoir accès a toutes les fonctionnalité du kernel, donc c’est cool Le PAE ne pose pas de limitation, sauf si tu veux jouer avec la mémoire il faut faire attention à la forme de tes PDE/PTE
3.
texane | mai 28th, 2008 at 20:07
ok ok, bien pour tout ca.
Pour le memory mapped io je pensais a ca aussi. Je sais que c’est faisable pour un nombre limite de CR3, mais y aurait pas moyen de shadow une translation d’addresse? ca peut etre vraiment pratique pour analyser le comportement d un driver proprio, voir faire mumuse avec les ring buffers des cartes reseaux pci (encore plus bas que ndis, meme si t as pas besoin d un hyperviseur pour ca).
Pour les intrin ca me revient, j avais surement cp le header dans mon projet, mais j avais de toute facon du recoder un wrapper sur certaines des instruction vmx (cpuid aussi je crois).
Yop, effectivement tu peux implémenter des shadow CR3 avec l’hyperviseur, ca te permet de faire des VM Exit si ton cr3 est différents des N valeurs gérés par l’hvm, je vois pas ce que ca peut m’apporter dans le cas présent car il faudrait dire que les pages des mm I/O sont non-present et pour ca, ya pas le choix faut modif les PTEs à la main. D’ailleurs je me demandais si il fallait le faire pour tous les PTEs kernel de chaque process ….
En tout cas, c’est loin d’être trivial …
5.
texane | mai 29th, 2008 at 20:14
justement, ma question c’etait de savoir si y avait un moyen de shadow les translations de la mmu comme tu peux le faire avec les acces CR3. Apres les TLB mais avant la mmu donc.
Dans l optique ou un process arriverait a mapper un device PCI avec une @ userland qui soit accessible dans tous les process (a part en passant par un driver, je vois vraiment pas), il faudrait en effet marquer les ptes correspondantes de chaque process comme invalid. Ca ne poserait pas de probleme puisque t as un vm exit a chaque mov CR3, XXXX, ce qui arrive dans KiSwapContext au moment de switcher de process.
6 Comments
1. texane | mai 27th, 2008 at 20:26
pas mal, comme tu dis faut pousser encore un peu tout ca.
En ce qui concerne le code + propre, tu peux utiliser les intrinsics du compilo ie. __vmx_write, include intrin.h (j ai eu qques soucis avec certains d entre eux non definis, je suppose que j utilisais une version batarde du ddk/cl).
Pour ton application de monitoring des io ports c’est pas mal… comme t’es dans windows, et avec un peu de boulot si pas deja fait, tu peux pousser le bouza en enumerant les devices PCI et leur plage memoire, pour monitorer aussi les memory mapped io, ca te ferait un truc vraiment pas mal.
D ailleurs tu arrives a appeler des fonctions de ntos depuis l’hyperviseur? Si oui, t as quoi comme limitation? Et avec PAE enable sur l’host, t as des problemes pour switch?
En tous cas c’est cool, y a beau avoir des projets similaires existants, y a tres peu d applications au dessus de ca, comme si l hyperviseur c’etait la fin en soi… vivement le code.
2. admin | mai 28th, 2008 at 14:09
Yo texane,
Merci pour l’astuce des intrinsics du compilo, je savais qu’ils en existait mais je ne savais pas ou les trouver, par contre je ne vois pas le intrin.h dans le dossier « inc » de mon WDK (version 6001.18001) par contre il apparaît bien dans les includes de mon Visual Studio C 2008 comme dit ici , la et la. Il existe bien les fichiers : emmintrin.h, mmintrin.h et xmmintrin.h dans mon WDK mais ils servent aux extensions MMX et SSE3. Bref de toute façon j’ai codé mes propres wrappers VMX dans des fichiers .asm qui vont aussi servir à vérifier que l’instruction VMX s’est bien déroulée en regardant le statut de l’eflags.
Concernant le monitoring des memory mapped I/O, j’avoue que je ne me suis pas encore penché dessus, d’après ce que j’ai lu et compris, il faudrait retrouvé les PTE des memory mapped I/O, les marqués non-present puis trapper les exceptions lors des accès sur ceux ci avec l’hyperviseur, ca serait la seule solution veux que le VMX ne peut faire la différence entre un accès mémoire sur un adressage physique qui correspond à la de RAM et un adressage physique qui correspond à un memory mapped I/O … Je verrais ça après je pense :p
Sinon quand je suis dans le contexte de l’hyperviseur je me retrouve dans le cas d’un driver normal et je peux donc avoir accès a toutes les fonctionnalité du kernel, donc c’est cool
Le PAE ne pose pas de limitation, sauf si tu veux jouer avec la mémoire il faut faire attention à la forme de tes PDE/PTE
3. texane | mai 28th, 2008 at 20:07
ok ok, bien pour tout ca.
Pour le memory mapped io je pensais a ca aussi. Je sais que c’est faisable pour un nombre limite de CR3, mais y aurait pas moyen de shadow une translation d’addresse? ca peut etre vraiment pratique pour analyser le comportement d un driver proprio, voir faire mumuse avec les ring buffers des cartes reseaux pci (encore plus bas que ndis, meme si t as pas besoin d un hyperviseur pour ca).
Pour les intrin ca me revient, j avais surement cp le header dans mon projet, mais j avais de toute facon du recoder un wrapper sur certaines des instruction vmx (cpuid aussi je crois).
4. admin | mai 29th, 2008 at 16:46
Yop, effectivement tu peux implémenter des shadow CR3 avec l’hyperviseur, ca te permet de faire des VM Exit si ton cr3 est différents des N valeurs gérés par l’hvm, je vois pas ce que ca peut m’apporter dans le cas présent car il faudrait dire que les pages des mm I/O sont non-present et pour ca, ya pas le choix faut modif les PTEs à la main. D’ailleurs je me demandais si il fallait le faire pour tous les PTEs kernel de chaque process ….
En tout cas, c’est loin d’être trivial …
5. texane | mai 29th, 2008 at 20:14
justement, ma question c’etait de savoir si y avait un moyen de shadow les translations de la mmu comme tu peux le faire avec les acces CR3. Apres les TLB mais avant la mmu donc.
Dans l optique ou un process arriverait a mapper un device PCI avec une @ userland qui soit accessible dans tous les process (a part en passant par un driver, je vois vraiment pas), il faudrait en effet marquer les ptes correspondantes de chaque process comme invalid. Ca ne poserait pas de probleme puisque t as un vm exit a chaque mov CR3, XXXX, ce qui arrive dans KiSwapContext au moment de switcher de process.
6. Malware :: Hiding Virtual&hellip | novembre 27th, 2012 at 00:40
[...] Ivanlef0u’s Blog – Hypervisor Abyss (in French) :: Part 1 :: Part 2 :: Part 3 [...]
Trackback this post