Dear Professor Shinagawa, Thank you very much for your useful help. Is it possible to implement a complete shadow paging mechanism (like XEN) in Bitvisor in order to have more complicated protection mechanisms for memory? Thanks again, Best Regards, <div class="gmail_quote">On Tue, Apr 12, 2011 at 5:05 PM, Takahiro Shinagawa <<a href="mailto:shina@ecc.u-tokyo.ac.jp">shina@ecc.u-tokyo.ac.jp</a>> wrote: <blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">Dear Nafise Sadat Moosavi: Thank you for being interested in BitVisor.<div class="im"> <blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> Thank you for your response. However, this statements has been stated in "BitVisor: A Thin Hypervisor for Enforcing I/O Device Security" paper: "The guest OS of parapass-through hypervisors use the physical address space that is identical to the machine (real) physical address space. The hypervisor does not need to carry out address translations. This contributes to reducing the size of the hypervisor." </blockquote> </div> The identical-mapping is only applied to guest memory regions, not to hypervisor memory regions.<div class="im"> <blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> "Hypervisors must hide their own memory regions from the guest OS so that the guest OS do not use them. BitVisor hooks the BIOS functions for obtaining the memory usage map (function e820h) to fake that the memory regions are reserved. " So we have concluded int0x15 would be the only mechanism for protecting Bitvisor memory area. </blockquote> </div> The paper also said "the hypervisor cannot directly use the guest page table because the guest OS can access the memory regions of the hypervisor by setting a physical address of the memory regions to the page table. To prevent such attacks, the hypervisor must verify each page table entry before the entry is used by the processor." So the protection is done by verifying page table entries, not by hooking int 0x15, as Eiraku said. Int 0x15 just tells the normal (non-malicious) guest OS not to use the hypervisor memory regions. Since a malicious guest OS can ignore it and try to access the hypervisor memory regions, it does not work as a protection mechanism.<div class="im"> <blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> Indeed, there is no address translation in gmm_pass_gp2hp() function, it just check whether the mentioned memory area is located in Bitvisor memory region or not and set the fakerom based on the result. </blockquote> </div> Setting the fakerom is a kind of address translation and works as protection; gmm_pass_gp2hp() verifies page table entries and prevents the guest OS from setting the physical address of hypervisor memory regions. Therefore, even a malicious guest OS, which may ignore int 0x15, cannot read or write the hypervisor memory regions. Takahiro Shinagawa </blockquote></div>