linux-kernel - Re: [PATCH 2/4] efi/libstub: detect panel-id

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:   Tue, 2 Jul 2019 15:48:48 -0700
From:   Rob Clark <robdclark@...il.com>
To:     Leif Lindholm <leif.lindholm@...aro.org>
Cc:     Ard Biesheuvel <ard.biesheuvel@...aro.org>,
        dri-devel <dri-devel@...ts.freedesktop.org>,
        linux-arm-msm <linux-arm-msm@...r.kernel.org>,
        freedreno <freedreno@...ts.freedesktop.org>,
        aarch64-laptops@...ts.linaro.org,
        Rob Clark <robdclark@...omium.org>,
        Ingo Molnar <mingo@...nel.org>, Will Deacon <will@...nel.org>,
        Alexander Graf <agraf@...e.de>,
        Steve Capper <steve.capper@....com>,
        Lukas Wunner <lukas@...ner.de>,
        Julien Thierry <julien.thierry@....com>,
        linux-efi <linux-efi@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 2/4] efi/libstub: detect panel-id

On Tue, Jul 2, 2019 at 2:59 PM Leif Lindholm <leif.lindholm@...aro.org> wrote:
>
> On Tue, Jul 02, 2019 at 02:01:49PM -0700, Rob Clark wrote:
> > > > So we are dealing with a platform that violates the UEFI spec, since
> > > > it does not bother to implement variable services at runtime (because
> > > > MS let the vendor get away with this).
> > >
> > > To clarify, the above remark applies to populating the DT from the OS
> > > rather than from the firmware.
> >
> > yeah, it isn't pretty, but there *are* some other similar cases where
> > efi-stub is populating DT.. (like update_fdt_memmap() and
> > kaslr-seed)..
>
> The problem isn't with the stub updating the DT, the problem is what
> it updates it with.
>
> update_fdt_memmap() is the stub filling in the information it
> communicates to the main kernel.
>
> kaslr-seed sets a standard property using a standard interface if that
> interface is available to it at the point of execution.
>
> Since what we're doing here is dressing up an ACPI platform to make it
> look like it was a DT platform, and since we have the ability to tweak
> the DT before ever passing it to the kernel, let's just do that.
>
> Yes, I know I said I'd rather not, but it's way nicer than sticking
> platform-specific hacks into the EFI stub.
>
> (If adding it as a DT property is indeed the thing to do.)
>
> > > ... but saving variables at boot time for consumption at runtime is
> > > something that we will likely see more of in the future.
> >
> > I think this will be nice, but it also doesn't address the need for a
> > quirk to get this into /chosen..  I guess we *could* use a shim or
> > something that runs before the kernel to do this.  But that just seems
> > like a logistical/support nightmare.
> >
> > There is one kernel, and there
> > are N distro's, so debugging a users "I don't get a screen at boot"
> > problem because their distro missed some shim patch really just
> > doesn't seem like a headache I want to have.
>
> The distros should not need to be aware *at all* of the hacks required
> to disguise these platforms as DT platforms.
>
> If they do, they're already device-specific installers and have
> already accepted the logistical/support nightmare.
>

I guess I'm not *against* a DT loader shim populating the panel-id
over into /chosen.. I had it in mind as a backup plan.  Ofc still need
to get dt folks to buy into /chosen/panel-id but for DT boot I think
that is the best option.  (At least the /chosen/panel-id approach
doesn't require the shim to be aware of how the panel is wired up to
dsi controller and whether their is a bridge in between, and that
short of thing, so the panel-id approach seems more maintainable that
other options.)

I am a bit fearful of problems arising from different distros and
users using different versions of shim, and how to manage that.  I
guess if somehow "shim thing" was part of the kernel, there would by
one less moving part... I'd know if user had kernel vX.Y.Z they'd be
good to go vs not.  But *also* depending on a new-enough version of a
shim, where the version # is probably not easily apparent to the end
user, sounds a bit scary from the "all the things that can go wrong"
point of view.  Maybe I'm paranoid, but I'm a bit worried about how to
manage that.

BR,
-R