From: Jack Rosenthal <jrosenth@chromium.org>
To: Greg KH <gregkh@linuxfoundation.org>
Cc: linux-kernel@vger.kernel.org, chrome-platform@lists.linux.dev,
Stephen Boyd <swboyd@chromium.org>,
Tzung-Bi Shih <tzungbi@kernel.org>,
Guenter Roeck <groeck@chromium.org>,
Julius Werner <jwerner@chromium.org>
Subject: Re: [PATCH v11] firmware: google: Implement cbmem in sysfs driver
Date: Fri, 30 Sep 2022 16:14:41 -0600 [thread overview]
Message-ID: <YzdqUX/zPvtyCmNm@chromium.org> (raw)
In-Reply-To: <YzaNjlqc0GqmJt68@kroah.com>
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@chromium.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
next prev parent reply other threads:[~2022-09-30 22:14 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-29 23:44 [PATCH v11] firmware: google: Implement cbmem in sysfs driver Jack Rosenthal
2022-09-30 6:32 ` Greg KH
2022-09-30 22:14 ` Jack Rosenthal [this message]
2022-10-01 7:33 ` Greg KH
2022-10-04 0:56 ` Julius Werner
2022-10-04 8:45 ` Greg KH
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YzdqUX/zPvtyCmNm@chromium.org \
--to=jrosenth@chromium.org \
--cc=chrome-platform@lists.linux.dev \
--cc=gregkh@linuxfoundation.org \
--cc=groeck@chromium.org \
--cc=jwerner@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=swboyd@chromium.org \
--cc=tzungbi@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox