Jan Kiszka <jan.kiszka@xxxxxx> wrote on 07/06/2012 14:10:32: > > BTW, the shadow IDT has to be put in the guest address space, right? So > > we need to make it read-only for the guest? > > Just found your solution: Append to a PCI bar. That's nasty. Better > reserve some memory via e820. There is a paravirtual channel from QEMU > to the BIOS to communicate such reservations. We will take a look at e820 and consider your suggestion, thanks! The PCI BAR worked well to obtain an "unused" and "mapped" memory area for unmodified guests. Nasty ? Well, as usual, depends who you ask and the alternatives you compare with. For us, it was an elegant and easy way to achieve the goal. > BTW, the IDTR holds a linear address, not a virtual one. Unless I > misremember, there is no need to map the IDT via the page table. The > processor will not consult it for reading its entries. As I understand and as we noticed in our runs using ELI, the processor uses the page tables to translate the IDTR (linear address) into physical address (guest physical in this case). (1) Logical addresses are converted to linear addresses using segments (not relevant in our case) (2) Linear addresses are converted to physical addresses using page tables (this is our case) Am I missing something ? In your case, I assume, [virtual = logical] and [linear = linear] or you are using some different semantics ? > Also, you do not discuss making the shadow table read-only in the guest > address space. This should help enforcing some security properties, no? We discussed this shortly at the end of Section 4.2: "...To detect runtime changes to the guest IDT, the host also write-protects the shadow IDT page. Other security and isolation considerations are discussed in Section 6" -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
