linux-kernel - Re: [PATCH v12] firmware: google: Implement cbmem in sysfs driver

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: <CAODwPW-7Y_CbCch+Y5unH3yJD1T=3epYvqja6w_CB-23C9x9sw@mail.gmail.com>
Date:   Tue, 4 Oct 2022 18:10:01 -0700
From:   Julius Werner <jwerner@...omium.org>
To:     Jack Rosenthal <jrosenth@...omium.org>
Cc:     Greg KH <gregkh@...uxfoundation.org>,
        LKML <linux-kernel@...r.kernel.org>,
        chrome-platform@...ts.linux.dev,
        Stephen Boyd <swboyd@...omium.org>,
        Tzung-Bi Shih <tzungbi@...nel.org>,
        Guenter Roeck <groeck@...omium.org>,
        Julius Werner <jwerner@...omium.org>
Subject: Re: [PATCH v12] firmware: google: Implement cbmem in sysfs driver

> > Then how does the kernel know what to print out?  Why not add such a
> > reference somewhere?
>
> The kernel really doesn't need to know the list of possible ids: it
> simply reads what coreboot gives it from the coreboot tables and proxies
> that on up to sysfs nodes.
>
> In an earlier version of this patch
> (https://lore.kernel.org/chrome-platform/CAODwPW-JzXXsEANaS+6n695YqriAQ0j0LXm31R2u1OP3MhX9Uw@mail.gmail.com/T/#u),
> I actually had this list so that the directory names were human-readable
> instead of using the 32-bit CBMEM id, but Julius didn't like it citing
> that we'd have to keep the kernel tree and the coreboot tree in sync.
>
> I'm fine with either solution ... just want to make all parties happy
> here =)

There is quite a long list of possible IDs (79 at the current count),
many of them are just coreboot-internal implementation details for
specific platforms that are really not interesting to the running OS
after we're done booting, and new ones get added all the time. I don't
think there's any practical value in trying to maintain a
corresponding list in the kernel, it would just be unnecessary bloat
and a maintenance nightmare to keep in sync.

This whole driver is supposed to be a thin bridge between coreboot and
coreboot-specific userspace tools. Those tools will know about the
specific meaning of individual IDs and the data format of their
contents, and they are much easier to keep updated and in sync with
new coreboot releases than the kernel itself. So the whole goal of the
design is to leave all those details to the userspace tools and have
the kernel involved as little as possible, just passing the raw
information through without being involved in its interpretation.