lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160121115033.GC2581@leverpostej>
Date:	Thu, 21 Jan 2016 11:50:34 +0000
From:	Mark Rutland <mark.rutland@....com>
To:	Shannon Zhao <shannon.zhao@...aro.org>
Cc:	Stefano Stabellini <stefano.stabellini@...citrix.com>,
	ard.biesheuvel@...aro.org, leif.lindholm@...aro.org,
	Shannon Zhao <zhaoshenglong@...wei.com>,
	linux-arm-kernel@...ts.infradead.org,
	stefano.stabellini@...rix.com, david.vrabel@...rix.com,
	catalin.marinas@....com, will.deacon@....com,
	julien.grall@...rix.com, xen-devel@...ts.xen.org,
	devicetree@...r.kernel.org, linux-efi@...r.kernel.org,
	linux-kernel@...r.kernel.org, peter.huangpeng@...wei.com,
	Jan Beulich <JBeulich@...ell.com>,
	Ian Campbell <Ian.Campbell@...rix.com>
Subject: Re: [PATCH v2 12/16] ARM: Xen: Document UEFI support on Xen ARM
 virtual platforms

On Tue, Jan 19, 2016 at 09:43:59PM +0800, Shannon Zhao wrote:
> 
> On 2016/1/19 21:13, Mark Rutland wrote:
> >On Tue, Jan 19, 2016 at 12:23:17PM +0000, Stefano Stabellini wrote:
> >>>On Tue, 19 Jan 2016, Mark Rutland wrote:
> >>>> >On Tue, Jan 19, 2016 at 06:25:25PM +0800, Shannon Zhao wrote:
> >>>>>>> > > >>We don't do this in Documentation/arm/uefi.txt, and I don't see why we
> >>>>>>> > > >>should do so here.
> >>>>>>> > > >>
> >>>>>>> > > >>Does Xen handle arbitrary size memory map descriptors? I'm not sure what
> >>>>>>> > > >>new information might be passed in future additions to the descriptor
> >>>>>>> > > >>format, and I'm not sure what should happen in the Dom0 case.
> >>>>>> > > >
> >>>>>> > > >Xen passes to Dom0 the memory map in the same format as the native
> >>>>>> > > >memory map.
> >>>> >
> >>>> >Does Xen parse or modify the EFI memory map in any way?
> >>>
> >>>Xen:
> >>>- calls EFI_BOOT_SERVICES.GetMemoryMap()
> >>>- takes note of the memory regions for its own usage
> >>>- create the fdt notes, including efi-mmap-start, with a pointer to it
> >>>
> >>>
> >>>> >Does it pass the raw values returned by EFI_BOOT_SERVICES.GetMemoryMap()
> >>>> >through to the xen,uefi-* properties, or does is make any static
> >>>> >assumptions about what the values will be?
> >>>
> >>>It just passes the raw values.
> >I take it that means that any memory carved out for Xen itself is
> >described/discovered via a separate mechanism? How does that work
> 
> For Xen hypervisor booting on UEFI, it get the EFI memory map
> through the similar way like Linux, e.g. call
> EFI_BOOT_SERVICES.GetMemoryMap().
> For Dom0, Xen will create a new EFI memory map for Dom0.
> 
> See [PATCH v3 52/62] arm/acpi: Prepare EFI memory descriptor for Dom0
> http://lists.xen.org/archives/html/xen-devel/2015-11/msg01884.html

Ok. So Xen will parse the EFI memory map, and will create a new memory
map to pass to the Dom0 kernel, presumably with some memory having been
carved out for Xen itself, and never described to Dom0.

So if there's any extension to that in future, Dom0 may see problems.
There's not much that can be done about that, however, and extensions to
the descriptors seem unlikely at present.

Thanks,
Mark.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ