linux-kernel - Re: [PATCH v15 1/6] efi: ARM/arm64: ignore DT memory nodes instead of removing them

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_6S+ME8MH8DZ32q+hKcRiOqp=nRy6Reryy5v=J7yE2vg@mail.gmail.com>
Date:	Fri, 18 Mar 2016 14:11:20 +0100
From:	Ard Biesheuvel <ard.biesheuvel@...aro.org>
To:	Matt Fleming <matt@...eblueprint.co.uk>
Cc:	David Daney <ddaney.cavm@...il.com>,
	Will Deacon <will.deacon@....com>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	Rob Herring <robh+dt@...nel.org>,
	Frank Rowand <frowand.list@...il.com>,
	Grant Likely <grant.likely@...aro.org>,
	Pawel Moll <pawel.moll@....com>,
	Ian Campbell <ijc+devicetree@...lion.org.uk>,
	Kumar Gala <galak@...eaurora.org>,
	Ganapatrao Kulkarni <gkulkarni@...iumnetworks.com>,
	Robert Richter <rrichter@...ium.com>,
	Mark Rutland <mark.rutland@....com>,
	Catalin Marinas <catalin.marinas@....com>,
	"linux-efi@...r.kernel.org" <linux-efi@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	David Daney <david.daney@...ium.com>
Subject: Re: [PATCH v15 1/6] efi: ARM/arm64: ignore DT memory nodes instead of
 removing them

On 18 March 2016 at 13:56, Matt Fleming <matt@...eblueprint.co.uk> wrote:
> On Fri, 18 Mar, at 01:31:59PM, Ard Biesheuvel wrote:
>>
>> Typically, the UEFI memory map is more restrictive, since it does not
>> only describe where the memory lives, but also which parts of it the
>> firmware has claimed for its own use. So if both memory nodes and the
>> UEFI memory map are available, we must use the latter anyway, and so
>> it makes sense to ignore the former. Alternatively, we could sanity
>> check the memory nodes against the memory map, but it is simpler just
>> to ignore them.
>>
>> However, that caused some problems in the past, since discovering the
>> memory nodes occurs before the EFI entry point is invoked, and so it
>> was decided that we strip the memory nodes rather than ignore them.
>
> Thanks Ard.
>
> Once you've stripped the memory nodes as represented in memblock,
> there's no way for the memory nodes to re-appear in one form or
> another after that point, right? The EFI memory map is the sole memory
> layout either via memblock or if it's queried directly?

Well, the significance of this patch in this series is that the memory
nodes contain additional properties that describe the NUMA topology,
which the UEFI memory map does not allow us to do. At some point, we
may decide to capture this information in a different way (i.e., a
separate configuration table), but for now, I think this is fine,
especially since stripping nodes is a bit of a blunt tool.