Hi,
I alloc some memory (some pages)in the hvm domU kernel space, but not map
it. So the kernel space could not access the memory by its guest tables. But
I
would access it by shadow pages for some use. When the shadow pages are
built, they should be in memory always and should not be paged out.
Then how to create the shadow pages for the memory? My hvm is 32 bit , with
PAE, So sl3,sl2,sl1 shadow pages need to be created, which API should I
use?
ps, I took a look at the code of shadow table, especially multi.c,
gust_walk.c, common.c, but still have no solution.
Best Regards,
Baozeng Ding
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Hi, At 12:30 +0000 on 04 Nov (1288873804), ding baozeng wrote:> I alloc some memory (some pages)in the hvm domU kernel space, but not > map it. So the kernel space could not access the memory by its guest > tables. But I would access it by shadow pages for some use.Why can''t you just map it with the guest pagetables? Having it only in the shadow pagetables would be confusing. What if the guest kernel wants to map something else at that virtual address?> When the > shadow pages are built, they should be in memory always and should not > be paged out. Then how to create the shadow pages for the memory?The easiest thing would be to change guest_walk_tables to insert your mappings as if they were in the guest pagetables. That way all the users in Xen will be consisitent. Cheers, Tim. -- Tim Deegan <Tim.Deegan@citrix.com> Principal Software Engineer, Xen Platform Team Citrix Systems UK Ltd. (Company #02937203, SL9 0BG) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Hi, 2010/11/4 Tim Deegan <Tim.Deegan@citrix.com>> Hi, > > At 12:30 +0000 on 04 Nov (1288873804), ding baozeng wrote: > > I alloc some memory (some pages)in the hvm domU kernel space, but not > > map it. So the kernel space could not access the memory by its guest > > tables. But I would access it by shadow pages for some use. > > Why can''t you just map it with the guest pagetables? Having it only in > the shadow pagetables would be confusing. What if the guest kernel > wants to map something else at that virtual address? > >I want to create another address space for security analysis. In this address space, we could access all the kernel address space, but the kernel address space could not access some memory of it. So this address space need to create its own shadow pages. In the shadow pages, they contain all the mapping that kernel shadow pages have, and also contains some mapping for the memory that the kernel could not access. The shadow pages are always in memory. So there would be two shadows, one for kernel, one for this address space. First, I want to copy the kernel shadow pages and then make some change to create the shadow pages we need. As we know, the kernel shadow pages is built dynamically, then how to copy it and make it in memory always? Best Regards, Baozeng Ding> > When the > > shadow pages are built, they should be in memory always and should not > > be paged out. Then how to create the shadow pages for the memory? > > The easiest thing would be to change guest_walk_tables to insert your > mappings as if they were in the guest pagetables. That way all the > users in Xen will be consisitent. > > Cheers, > > Tim. > > -- > Tim Deegan <Tim.Deegan@citrix.com> > Principal Software Engineer, Xen Platform Team > Citrix Systems UK Ltd. (Company #02937203, SL9 0BG) >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
At 01:32 +0000 on 05 Nov (1288920725), ding baozeng wrote:> I want to create another address space for security analysis. In this > address space, we could access all the kernel address space, but the > kernel address space could not access some memory of it.I''m not sure shadow pagetables are the right place to do this - have you thought about having your security code in another VM? Otherwise you need to stop the kernel mapping the secure memory in its own pagetables, granting it to other VMs, DMAing to it, &c. Also what if you want to use EPT/NPT?> So this > address space need to create its own shadow pages. In the shadow > pages, they contain all the mapping that kernel shadow pages have, and > also contains some mapping for the memory that the kernel could not > access. The shadow pages are always in memory. So there would be two > shadows, one for kernel, one for this address space.If this address space is identified by its own %CR3 value then there already are - all you need to do is modify guest_walk_tables to add the extra mappings whenever %CR3 holds the right value and everything will work out. Cheers, Tim.> First, I want to > copy the kernel shadow pages and then make some change to create the > shadow pages we need. As we know, the kernel shadow pages is built > dynamically, then how to copy it and make it in memory always?-- Tim Deegan <Tim.Deegan@citrix.com> Principal Software Engineer, Xen Platform Team Citrix Systems UK Ltd. (Company #02937203, SL9 0BG) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
2010/11/5 Tim Deegan <Tim.Deegan@citrix.com>> At 01:32 +0000 on 05 Nov (1288920725), ding baozeng wrote: > > I want to create another address space for security analysis. In this > > address space, we could access all the kernel address space, but the > > kernel address space could not access some memory of it. > > I''m not sure shadow pagetables are the right place to do this - have you > thought about having your security code in another VM?If I put the security code out-of-vm, the overhead is not satisfactory.> Otherwise you > need to stop the kernel mapping the secure memory in its own pagetables, > granting it to other VMs, DMAing to it, &c. Also what if you want to > use EPT/NPT? > > I use the SPT to obtain security effect and the overhead is also small. Iwould 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)> > So this > > address space need to create its own shadow pages. In the shadow > > pages, they contain all the mapping that kernel shadow pages have, and > > also contains some mapping for the memory that the kernel could not > > access. The shadow pages are always in memory. So there would be two > > shadows, one for kernel, one for this address space. > > If this address space is identified by its own %CR3 value then there > already areDo you mean when the hvm domain is created, its shadow page for the kernel is built already? I thought spt is empty first, but when we access the kernel space, the spt entry is built for it. Am I right?> - all you need to do is modify guest_walk_tables to add the > extra mappings whenever %CR3 holds the right value and everything will > work out. > > Cheers, > > Tim. > > > First, I want to > > copy the kernel shadow pages and then make some change to create the > > shadow pages we need. As we know, the kernel shadow pages is built > > dynamically, then how to copy it and make it in memory always? > > -- > Tim Deegan <Tim.Deegan@citrix.com> > Principal Software Engineer, Xen Platform Team > Citrix Systems UK Ltd. (Company #02937203, SL9 0BG) >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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. 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? Cheers, Tim. -- Tim Deegan <Tim.Deegan@citrix.com> Principal Software Engineer, Xen Platform Team Citrix Systems UK Ltd. (Company #02937203, SL9 0BG) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
2010/11/5 Tim Deegan <Tim.Deegan@citrix.com>> 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@citrix.com> > Principal Software Engineer, Xen Platform Team > Citrix Systems UK Ltd. (Company #02937203, SL9 0BG) >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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? When is the shadow page for the built,
at "alloc_pages" or "page_address " or is not built at all?
Best Regards,
Baozeng Ding
2010/11/6 ding baozeng <baozengding@gmail.com>
>
>
> 2010/11/5 Tim Deegan <Tim.Deegan@citrix.com>
>
> 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@citrix.com>
>> Principal Software Engineer, Xen Platform Team
>> Citrix Systems UK Ltd. (Company #02937203, SL9 0BG)
>>
>
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
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@gmail.com<mailto:baozengding@gmail.com>> > > > 2010/11/5 Tim Deegan <Tim.Deegan@citrix.com<mailto:Tim.Deegan@citrix.com>> > > 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@citrix.com<mailto:Tim.Deegan@citrix.com>> > Principal Software Engineer, Xen Platform Team > Citrix Systems UK Ltd. (Company #02937203, SL9 0BG) > >-- Tim Deegan <Tim.Deegan@citrix.com> Principal Software Engineer, Xen Platform Team Citrix Systems UK Ltd. (Company #02937203, SL9 0BG) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel