[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] reserve e820 ram



At 18:10 +0100 on 18 Apr (1334772613), Francisco Rocha wrote:
> On 04/18/2012 05:43 PM, Tim Deegan wrote:
> >
> > At 15:36 +0100 on 18 Apr (1334763404), Francisco Rocha wrote:
> > > Hi Tim,
> > >
> > > I was thinking about changing my approach.
> > >
> > > I think that for now I will leave those pages off because I am
> > > mostly interested in protecting other areas.
> > >
> > > Those accesses for now are inevitable to get the VM to properly
> > > operate. Now, the question is if it is possible to use page table
> > > entries to do what I want to do.
> > >
> > > The objective would be to use a bit flag that would determine if
> > > the pages are returned when a call to map_foreign_range is made.
> > > So, my final objective would be that only pages used for the three
> > > operations you describe are accessible to Dom0.
> > > Everything that is not BIOS and related, Qemu or PV backend
> > > drivers will not be returned.
> > >
> > > From what I see in the header files you use 12-bits from a 24-bit
> > > flag (x86_64). Can we do it? This would again take us to controlling
> > > access at get_page_from_l1e(), right?
> >
> > Are you talking about the count_info and type_info fields?  yes, I think
> > you can probably put a new flag or two in there.
> >
> I was thinking about the ones used in page table entries
> (_PAGE_PRESENT|RW, etc).

Oh.  That's probably not so suitable for access control since (a) there
may be more that one PTE pointing to the same page, even controlled by
different domains, and what if they have different flags? and (b) given
a page number you can't easily find a PTE that points to it to look at
the bits.

Th type_info and count_info fields, on the other hand, exist once per
page and are entirely under Xen's control.

> > Choosing which pages
> > qemu can map will be interesting, though -- it needs to map anything the
> > VM uses for I/O.  But maybe you can just define the things you protect
> > and declare taht they can't be used for I/O.  That sounds easier. :)
> >
> The objective is to protect the kernel and its data structures.
> That is why I was considering the flags I previously mentioned.
> There is one denominated _PAGE_GUEST_KERNEL.

That's part of the 64-bit PV interface; if the guest is 32-bit or HVM it
won't be used like that.  I think you'll have to modify the kernel to
explicitly tell Xen which pages are kernel ones (wih a hypercall) and
then remember that with a bit in the count_info/type_info.

Cheers,

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.