At 08:43 +0000 on 11 Nov (1289465027), ding baozeng wrote:
> Hi,
> I wrote a module test.c in hvm domU, simple as the following:
> struct page * pg;
> unsigned long *vaddr;
> pg = alloc_pages(GFP_HIGHUSER, 1);
> if (!pg) return 0;
> vaddr = page_address(pg);
> if (!vaddr) return 0;
> printk("The address allocated is %lx\n", (unsigned long)vaddr);
> printk("The value at the address is %lx\n", *vaddr);
> __free_pages(pg, 1);
> return 1;
>
> After compile and insmod the module, the result is:
> The address allocated is fab3d000;
> The value at the address is 3125
> I have a few questions about it:
> As we could obtain the value at the address fab3d000, does that means
> the shadow pages for it has been built?
Yes.
> When is the shadow page for
> the built, at "alloc_pages" or "page_address " or is not built at all?
The shadow pagetables are like a software TLB. The shadow is built when
the virtual address is actually accessed (or maybe before, depending on
prefetching). It's then kept around for some indeterminate length of
time before being discarded.
One problem you will have is that unlike a real TLB the contents of the
shadows depend only on the contents of guest memory that are used for
pagetables. So if two guest pagetables use the same L1 pagetable page
they will get exactly the same shadows (using the same L1 shadow
pagetable page).
If you can guarantee that your secure pagetables don't share any
pagetable pages with any other pagetables in the guest kernel, then
it will be possible to have a per-vcpu flag that says whether the vcpu
is currently "secure" or not, and check that flag in _sh_propagate() to
know whether you should allow mappings of your secure memory.
(You will have to register the GFNs of the secure memory with the
hypervisor, of course, to avoid aliasing at other virtual addresses).
BTW, if you're planning to use the CR3-list feature to allow fast
switching to and from the secure pagetables, you'll need to turn off at
least SHOPT_VIRTUAL_TLB and SHOPT_OUT_OF_SYNC, and possibly other
optimizations that rely on intercepting CR3 writes to flush state.
You'll also have to look carefully at the code that holds a reference
count on the page currently in CR3 - maybe in the vmexit handler you can
check whether CR3 has changed since vmentry and handle that before
anything else.
Cheers,
Tim.
> Best Regards,
> Baozeng Ding
>
> 2010/11/6 ding baozeng <baozengding@xxxxxxxxx<mailto:baozengding@xxxxxxxxx>>
>
>
> 2010/11/5 Tim Deegan <Tim.Deegan@xxxxxxxxxx<mailto:Tim.Deegan@xxxxxxxxxx>>
>
> At 11:42 +0000 on 05 Nov (1288957359), ding baozeng wrote:
> > I use the SPT to obtain security effect and the overhead is also
> > small. I would disable EPT. When putting the security code in-vm, I
> > further use the VT-d technology, CR3_TARGET_LIST to decrease the
> > overhead. As we know, when processes switch, it would update CR3, and
> > so trap into xen, which bring up a lot of overhead. But after we
> > write the value of CR3 into the CR3_TARGET_LIST, it would not trap
> > into xen when process switch. So I would create another address space
> > to put the security code and put the address of its shadow page into
> > CR3_TARGET_LIST. (when you have time, please take look at the paper in
> > attachment, thx)
>
> I've read the paper ("Secure In-VM Monitoring Using Hardware
> Virtualization", from Proc. CCS '09, for anyone reading along) and the
> thing they do there will be difficult in the Xen shadow pagetables
> because Xen shadows individual frames of memory rather than %CR3 values,
> so if the guest kernel shares pagetables between the secure and
> non-secure %CR3s they will always see exactly the same mappings in the
> shadows.
> We do not share pagetables. Is it possible that we just create our own shadow
> pagetables for SIM address space?(The guest pagetables for SIM may be not
> needed). This may consume some memory in xen, but i think it is a way to
> implement it. If it is possible, how to implement it?
>
> It would take quite a lot of work to make Xen's shadow pagetables treat
> one process differently from all the others. Have you tried asking the
> authors for their KVM code?
> I asked, but they said their code is not opened.
>
> Cheers,
>
> Tim.
>
> --
> Tim Deegan <Tim.Deegan@xxxxxxxxxx<mailto:Tim.Deegan@xxxxxxxxxx>>
> Principal Software Engineer, Xen Platform Team
> Citrix Systems UK Ltd. (Company #02937203, SL9 0BG)
>
>
--
Tim Deegan <Tim.Deegan@xxxxxxxxxx>
Principal Software Engineer, Xen Platform Team
Citrix Systems UK Ltd. (Company #02937203, SL9 0BG)
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home