linux-kernel - Re: [RFC] Correct memory layout reporting for "jedec,lpddr2" and related bindings

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]

Date:   Wed, 27 Jul 2022 17:22:42 -0700
From:   Julius Werner <jwerner@...omium.org>
To:     Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
Cc:     Julius Werner <jwerner@...omium.org>,
        Krzysztof Kozlowski <krzk+dt@...nel.org>,
        Dmitry Osipenko <digetx@...il.com>,
        Jian-Jia Su <jjsu@...gle.com>,
        Doug Anderson <dianders@...omium.org>,
        Rob Herring <robh+dt@...nel.org>,
        LKML <linux-kernel@...r.kernel.org>,
        "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
        <devicetree@...r.kernel.org>,
        Nikola Milosavljevic <mnidza@...look.com>
Subject: Re: [RFC] Correct memory layout reporting for "jedec,lpddr2" and
 related bindings

> > By "use case" I mean our particular platform and firmware requirements
> > -- or rather, the realities of building devices with widely
> > multi-sourced LPDDR parts. One cannot efficiently build firmware that
> > can pass an exact vendor-and-part-specific compatible string to Linux
> > for this binding for every single LPDDR part used on such a platform.
>
> Why cannot? You want to pass them as numerical values which directly map
> to vendor ID and some part, don't they?

Yes, but the current compatible string format also requires the exact
part number, of which there are many thousands and it's impossible to
build a list in advance. Even for vendors, hardcoding 255 strings in a
tight firmware space would be an unnecessary burden. There's also an
update problem -- firmware may be built and signed and burned into ROM
long before the assembly of the final mainboard. Board manufacturers
want to be able to just drop-in replace a newly-sourced LPDDR part in
their existing production line without having to worry if the existing
(and possibly no longer changeable) firmware contains a string table
entry for this part.

If you just want the compatible string to be unique, encoding the
numbers like Doug suggested (e.g. jedec,lpddr3-ff-0100) would work for
us.

> If we talk about standard, then DT purpose is not for autodetectable
> pieces. These values are autodetectable, so such properties should not
> be encoded in DT.

But the DT is the only interface that we have to pass information from
firmware to kernel and userspace. Where else should these properties
be encoded? They are auto-detectable, but not for the kernel itself
(only for memory-training firmware running in SRAM). Maybe the usual
rules of thumb don't apply here, because unlike all other peripheral
controllers the memory controller is special in that the kernel cannot
simply reinitialize it and get the same information from the original
source again.