linux-kernel - Re: [PATCH v2 12/16] ARM: Xen: Document UEFI support on Xen ARM virtual platforms

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: <CAKv+Gu_+MOv-p=o7j9Mwwd2+tEp91s6rtfP4_E=S9hiQjDg+kQ@mail.gmail.com>
Date:	Tue, 19 Jan 2016 14:18:53 +0100
From:	Ard Biesheuvel <ard.biesheuvel@...aro.org>
To:	Mark Rutland <mark.rutland@....com>
Cc:	Stefano Stabellini <stefano.stabellini@...citrix.com>,
	Leif Lindholm <leif.lindholm@...aro.org>,
	Shannon Zhao <zhaoshenglong@...wei.com>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	Stefano Stabellini <stefano.stabellini@...rix.com>,
	David Vrabel <david.vrabel@...rix.com>,
	Catalin Marinas <catalin.marinas@....com>,
	Will Deacon <will.deacon@....com>,
	Julien Grall <julien.grall@...rix.com>,
	"xen-devel@...ts.xen.org" <xen-devel@...ts.xen.org>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	"linux-efi@...r.kernel.org" <linux-efi@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Shannon Zhao <shannon.zhao@...aro.org>,
	"Huangpeng (Peter)" <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 19 January 2016 at 14:13, Mark Rutland <mark.rutland@....com> 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?
>
>> > I'm trying to get a feeling for what the behaviour will be if/when a
>> > version of the EFI spec expands the memory map format.
>>
>> Linux is likely to get the memory map in the same format as it's
>> provided on native.
>
> Ok.
>
> The only fragility I forsee there would be if some extended memory
> descriptor format defined things the kernel understood but Xen did not.
>
> Given that would require an update to the kernel, at that point code is
> added for that we can figure out how to determine whether Xen handled
> any of said information, and whether any further negotiation with Xen is
> necessary. I assume Xen exposes some feature probing mechanism to guests
> that can cater for that if necessary.
>
> Ard, Leif, I trust you two can keep an eye out for anything of that
> sort on the UEFI side. :)
>

Yes. I think the likelihood that we will ever see an updated memory
descriptor format is negligible (we are still at version 1). I do know
that EDK2 deliberately uses a descriptor size that is larger than the
size of the struct in its implementation of GetMemoryMap(), so it
would appear that most existing OSes will be able to deal with it
(apart from being able to interpret the new fields) if it ever does
occur.

-- 
Ard.