On Mon, Sep 10, 2007 at 05:20:49AM +0200, Tristan Gingold wrote:
> 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...)
Mmm, that does indeed seem to cause some problems for my change.
--
Horms
H: http://www.vergenet.net/~horms/
W: http://www.valinux.co.jp/en/
_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ia64-devel
|
Home