linux-kernel - Re: [PATCH v11] 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: <YzdqUX/zPvtyCmNm@chromium.org>
Date:   Fri, 30 Sep 2022 16:14:41 -0600
From:   Jack Rosenthal <jrosenth@...omium.org>
To:     Greg KH <gregkh@...uxfoundation.org>
Cc:     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 v11] firmware: google: Implement cbmem in sysfs driver

On 2022-09-30 at 08:32 +0200, Greg KH wrote:
> symlink?  Ick, no, do not do that at all please.
> 
> As these are device attributes, just stick with them.  Don't do a crazy
> symlink into a non-device-attribute portion of the sysfs tree, by doing
> that you break all userspace tools and stuff like libudev will never
> even see these attributes.

I guess I can fill in some info here about the use case needed:
userspace tools (in this case, a tool called "crossystem") needs to look
up a CBMEM entry by ID and read it.  So, being able to find a fixed path
like /sys/firmware/cbmem/<id>/mem is significantly easier than scanning
all /sys/bus/coreboot/devices/coreboot*/id to find the right device
first.

What exactly do we break here by adding symlinks?  udev won't look into
/sys/firmware, right?

Or, is there another good alternative that we could use to find a CBMEM
entry by its id without needing to scan thru all coreboot bus type
devices?  Setting the device name to something more predictable (e.g.,
"cbmem-<id>") would require the coreboot bus type to "look ahead" and
notice it's a CBMEM entry before registering the device, which wouldn't
exactly be all that clean.

> > +What:		/sys/firmware/cbmem/
> > +Date:		August 2022
> > +Contact:	Jack Rosenthal <jrosenth@...omium.org>
> > +Description:
> > +		Coreboot provides a variety of data structures in CBMEM.  This
> > +		directory contains each CBMEM entry, which can be found via
> > +		Coreboot tables.
> 
> What happened to the coreboot name?

I removed it as it seemed like from your last message you didn't want
it?

> Why cbmem?  What is CBMEM?

I can add this to the next patch once I get clarifications on the above.

> Also, I asked before, but some note about "exposing all of these bios
> values to userspace is not a security issue at all" would be nice, if
> only to point at in a few years and say "wow we were naive"...

Right, I'll add this too.

Thanks,

Jack