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: <CAFEAcA8sE8Rj0GmF71ox4BdDr0UcaS4QwiLUVUUFH5oj+hDhfA@mail.gmail.com>
Date:   Tue, 17 May 2022 17:54:36 +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@...ts.infradead.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 Tue, 17 May 2022 at 16:34, Rob Herring <robh@...nel.org> wrote:
>
> On Tue, May 17, 2022 at 11:14:10AM +0100, Andre Przywara wrote:
> > When we boot a machine using a devicetree, the generic DT code goes
> > through all nodes with a 'device_type = "memory"' property, and collects
> > all memory banks mentioned there. However it does not check for the
> > status property, so any nodes which are explicitly "disabled" will still
> > be added as a memblock.
> > This ends up badly for QEMU, when booting with secure firmware on
> > arm/arm64 machines, because QEMU adds a node describing secure-only
> > memory:
> > ===================
> >       secram@...0000 {
>
> BTW, 'memory' is the correct node name.

We already have a 'memory' node, which is for the NS
memory. This one's for the secure-only RAM block,
which is why I gave it a name that hopefully helps in
spotting that when a human is reading the DT.

I'm not really sure to what extent node names in device trees are
"this is just an identifying textual label" and to what extent
they are "this is really ABI and you need to follow the standard",
though -- nothing in practice seems to care what they are,
suggesting the "textual label" theory, but some bits of tooling
complain if you do things like forget the address value or use the
same address for two different nodes, suggesting the "really ABI"
theory.

thanks
-- PMM

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ