Quoting Horms <horms@xxxxxxxxxxxx>:
> 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.
Maybe I spoke too quickly. I should read your code again and understand
when this area is used.
Tristan.
_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ia64-devel
|
Home