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? -- Horms H: http://www.vergenet.net/~horms/ W: http://www.valinux.co.jp/en/ _______________________________________________ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
