linux-kernel - Re: [PATCH] CHROMIUM: arm64: dts: qcom: Add sc7180-gelarshie

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, 4 May 2022 16:56:01 -0700
From:   Julius Werner <jwerner@...omium.org>
To:     Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
Cc:     Doug Anderson <dianders@...omium.org>,
        Krzysztof Kozłowski <k.kozlowski.k@...il.com>,
        Mars Chen <chenxiangrui@...qin.corp-partner.google.com>,
        Andy Gross <agross@...nel.org>,
        Bjorn Andersson <bjorn.andersson@...aro.org>,
        Rob Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski <krzk+dt@...nel.org>,
        linux-arm-msm <linux-arm-msm@...r.kernel.org>,
        "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
        <devicetree@...r.kernel.org>, LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] CHROMIUM: arm64: dts: qcom: Add sc7180-gelarshie

Trying to chime in here from the firmware development side of this
issue to help clarify what Doug is asking for. We have the fundamental
problem that we have several different board revisions that we _think_
should be 100% compatible for kernel and userspace, so for various
practical reasons (easier to maintain in the source, limiting kernel
image size by not having to bundle the same DTB multiple times under a
different name), we want to use the same DTB for all of them. Just
saying "well, you should treat each revision as incompatible to all
the others from the start then" doesn't scale (we have a lot of
revisions, and in the vast majority of cases they are just as
compatible as we initially expect them to be).

However, we also can't just exhaustively enumerate all revision
numbers that are compatible with this DTB, because we don't know in
advance how many we'll build. For again various practical reasons
(bundling, signing, testing), it would cost a lot of extra effort and
friction to rebuild a new kernel image just to add a new compatible
string to the list every time the factory updates the revision number.
An earlier hacky solution we had for this is to just define a bunch of
extra revision compatible strings in advance even though they don't
exist yet (e.g. you can still see this in
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/arch/arm/boot/dts/tegra124-nyan-blaze.dts
-- I believe there were only actually ever 3 or 4 Blaze revisions, the
other compatible strings defined there never existed as physical
boards). This is cumbersome and hacky and also doesn't really scale
(particularly when we need to add SKU as another dimension into the
string), so we needed to come up with something more manageable.

Our solution is to use "google,lazor" as the stand-in compatible
string for "all Lazor boards compatible with the latest revision".
When a compatibility break happens at some point in the Lazor series
(say between rev3 and rev4), we'll change the compatible string in the
old rev3 DTB to no longer include "google,lazor" but to instead list
all specific revision numbers ("google,lazor-rev0", ...,
"google-lazor-rev3") exhaustively (at this point we can do it, because
at this point we know we're not going to build any new boards
compatible with that old layout in the future). The new rev4 DTB will
then list "google,lazor" and again remain valid for all future
revisions we build, until the next compatibility break.

You are correct that this ends up changing the meaning of
"google,lazor" at some point, but it's really the only good way I can
see how to solve this within our practical constraints. I also don't
really see a practical concern with that, since our firmware matching
algorithm (and I believe this is the standard other bootloaders like
U-Boot also follow) will look for the more specific string with the
explicit revision number first, before falling back to the generic
one. So whenever we decide to change the meaning of the latter in the
kernel, we also make sure to provide matches for all the specific
revisions that previously used the generic match, so that they will
pick up those instead and there's no chance of them getting confused
by the change in meaning. While it is perhaps a bit unorthodox, I
think it is practical, safe, and I don't really see a practical
alternative for our use case.