linux-kernel - Re: [PATCH] of/fdt: Ignore disabled memory nodes

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAFEAcA80B2aGdaxK2pm7AK84KK_UqwD-KCMKtK6b8fF41MeKRg@mail.gmail.com>
Date:   Wed, 18 May 2022 18:54:28 +0100
From:   Peter Maydell <peter.maydell@...aro.org>
To:     Rob Herring <robh@...nel.org>
Cc:     Andre Przywara <andre.przywara@....com>,
        Frank Rowand <frowand.list@...il.com>,
        devicetree@...r.kernel.org,
        linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Ross Burton <ross.burton@....com>,
        Ard Biesheuvel <ardb@...nel.org>,
        Catalin Marinas <catalin.marinas@....com>,
        Will Deacon <will@...nel.org>,
        Russell King <linux@...linux.org.uk>
Subject: Re: [PATCH] of/fdt: Ignore disabled memory nodes

On Wed, 18 May 2022 at 17:54, Rob Herring <robh@...nel.org> wrote:
>
> On Tue, May 17, 2022 at 08:19:47PM +0100, Peter Maydell wrote:
> > We generate the DTB with libfdt, so source-only information
> > isn't something we can put in, I think. (The quoted DT fragment
> > in this patch's commit message is the result of decompiling
> > the runtime generated DT binary blob with dtc.)
>
> Given the runtime aspect with overlays, it's conceivable that libfdt
> could support setting labels some day and then dts output maintaining
> them.
>
> We could also consider a standard node name such as 'secure-memory'.
> It's a whole can of worms though on how secure vs. non-secure memory
> (and other things) are represented.

Mmm. We put in the very basic parts years ago in
Documentation/devicetree/bindings/arm/secure.txt
which is (and has remained) generally sufficient for the QEMU->Trusted
Firmware-> maybe uboot->Linux stack, which is pretty much the only use
case I think. (My intention when we wrote that up was that memory
that's S-only would be indicated the same way as S-only devices,
with the secure-status and status properties.)

> > Are we just stuck with what we have for historical reasons ?
>
> Yes. If we were designing this, we'd probably have 'compatible =
> "memory"'. We're likely just stuck with things how they are. Mostly node
> names haven't been an ABI and we're just trying to be consistent in
> naming and use of unit-addresses.

So, do you think it's worthwhile/a good idea for me to rename
the DT node that QEMU is currently calling "secmem" to be
"memory" ? My default is "leave it as it is", for economy of
effort reasons :-) -- but it's an easy enough change to make.
Though EDK2's dtb reading code just looks for the first
"memory" node and assumes it's the big one, so changing the node
name would make us reliant on the order of the two nodes in the
DTB unless we fixed EDK2 (which we should probably do anyway, tbh).

thanks
-- PMM