On Mon, Sep 10, 2007 at 10:54:29AM +0900, Horms wrote:
> On Sat, Sep 08, 2007 at 06:06:30AM +0200, Tristan Gingold wrote:
> > On Fri, Aug 17, 2007 at 03:50:55PM +0900, Simon Horman wrote:
> > > This is used by paches that move the EFI runtime regions into what is
> > > normally guest space. A description of why this mapping is made is
> > > included in the patch that makes the mapping.
> > [...]
> > > +/* In order for Kexec between Xen and Linux to work EFI needs
> > > + * to be mapped into the same place by both. It seems most convenient
> > > + * to make Xen do the dirty work here */
> > > +#define __IA64_EFI_UNCACHED_OFFSET 0xc000000000000000UL
> > > +#define __IA64_EFI_CACHED_OFFSET 0xf000000000000000UL
> >
> > Hi,
> >
> > sorry or this late comment but doesn't this code creates a security hole ?
> > EFI_UNCACHED_OFFSET area will be visible inside vti domains as its virtual
> > address is valid in these domains.
>
> Hi Tristan,
>
> I think that you have a good point there.
>
> Currently the code is checking psr.cpl to make sure that it is 0,
> and thus deny access to (non-vti?) domains. Is a similar check possible
> for vti domains, or is the problem a little deeper?
Unfortunately similar check is not possible for vti. Hypervisor memory
is protected from guest domain by using a 1 bit wider virtual address.
(I think it would have been better to add a new bit in the mmu but...)
Tristan.
_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ia64-devel
|
Home