linux-kernel - Re: [PATCH v2 2/2] x86/of: add support for reserved memory defined by DT

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: <CAGptq8GzJh38349ZZpEOw9sV8ihtJMHqV=PH9WUbG-C7b0tJjg@mail.gmail.com>
Date: Thu, 24 Apr 2025 20:06:33 +0200
From: Grzegorz Jaszczyk <jaszczyk@...omium.org>
To: Rob Herring <robh@...nel.org>
Cc: tglx@...utronix.de, mingo@...hat.com, bp@...en8.de, 
	dave.hansen@...ux.intel.com, x86@...nel.org, hpa@...or.com, 
	saravanak@...gle.com, dmaluka@...omium.org, bgrzesik@...gle.com, 
	jaszczyk@...gle.com, ilpo.jarvinen@...ux.intel.com, usamaarif642@...il.com, 
	linux-kernel@...r.kernel.org, devicetree@...r.kernel.org, tnowicki@...gle.com, 
	mazurekm@...gle.com, vineethrp@...gle.com
Subject: Re: [PATCH v2 2/2] x86/of: add support for reserved memory defined by DT

On Wed, Apr 23, 2025 at 4:09 PM Rob Herring <robh@...nel.org> wrote:
>
> On Fri, Apr 18, 2025 at 12:47:18PM +0000, Grzegorz Jaszczyk wrote:
> > From: Grzegorz Jaszczyk <jaszczyk@...gle.com>
> >
> > The DT reserved-memory nodes can be present in DT as described in
> > Documentation/devicetree/bindings/reserved-memory/reserved-memory.yaml.
> > Similar to other architecture, which supports DT, there is a need to
> > create reserved memory regions for such nodes.
> >
> > Additionally, the x86 architecture builds its memory map based on E820
> > description passed by bootloader and not on DT. Since x86 already has
> > some DT support and allows booting with both ACPI and DT at the same
> > time, let's register an arch specific hook which will validate if a
> > reserved-memory region passed by DT is valid (covered by E820 reserved
> > region entry).
> >
> > Without this check, the reserved memory from DT could be successfully
> > registered, even though such a region could conflict with e820
> > description e.g. it could be described as E820_RAM and could be already
> > used at early x86 boot stage for memblock initialization (which happens
> > before DT parsing).
>
> Sorry, I don't get how it conflicts. Wouldn't the E820_RAM be registered
> with memblock and memblock then handles the conflict (or should).
>

On x86, early memblock setup is performed by e820__memblock_setup()
and regions which are marked as E820_RAM are added to the memblock
"memory" type and such regions can be later on used for memblock
allocation on early x86 setup. If memblock allocation is performed
after e820__memblock_setup and before x86_flattree_get_config,  the
reserved region described in DT (but described as RAM in e820) could
be silently used before we scan DT for reserved memory regions.

Additionally there are more reasons why we want to make sure that e820
reserved regions are in sync with DT reserved memory: resource tree
building and setup pci gap based on e820.
On the x86 resource tree is built taking into account e820 entries
(e820__reserve_resources()) while on other arch like e.g. arm64, which
relies on DT, the resource tree is built taking into account
information from DT(request_standard_resources). Mixing both on x86
seems problematic and at first glance could be achieved by e.g.
patching e820_table via e820__range_update so other part of the early
x86 kernel setup such as e820__setup_pci_gap() will also not use
region which is described in DT as reserved-memory. But it is not
straight-forward (initially I've tried to go through this path) e.g.
it will require handling DT earlier (x86_flattree_get_config) but at
the same time x86_flattree_get_config relies on the memblock being set
up. Therefore it seems that making a requirement that the e820
reserved region should be in sync with DT reserved-memory on x86 is
reasonable.

Best regards,
Grzegorz