Those are very different flows to get to and change the same "types" ofdata. By Dell's interface
being Dell specific we can guarantee that the documented flow works how itshould.
Documenting the flow could be part of the documentation for the
different passwd types.
In the concept of a "generic" API I don't think the word "password" is futureproof
and it would need to be avoided. I think a better term would be "authentication".
For how things currently work the User and
Admin password attributed would have a type of "password", the hash
example you gave will have a different type for its password attribute,
e.g. "hotp" and not only the type could be different but also
the sysfs-attributes, e.g. the "Admin" password-dir which has a "type"
sysfs-atrribute which returns "htop" may not have a current_password
attribute at all, instead it may would have a hash attribute, making
it (more) clear that this one works differently.
In our definition `current_password` is intentionally not readable by userspace.
One process could be writing it (think obtaining it from an escrow service) and
another interacting with attributes, and their threat models might not match.
Furthermore - what's to say multiple authentication schemes might not be
simultaneously supported and this needs to be expressed? This can be a difference
between OEM implementations.
This would mean that existing userspace software can not work with
systems using the new "hotp" password atrributes, but that is
I think that the current generic password flow will work well
for other vendors too, they may need to not cache it in the
kernel (instead sending it directly to the firmware once), but the basic
concept of having to write the plain-text bios Admin password before
being able to change protected settings seems like it is something which
matches how most current BIOS-es work. And needing a way to re-lock the
settings also sounds like something which will be pretty common for most
OK so here is another place that I think vendors might have a different
implementation. When you have a BIOS admin password set, Dell requires that
password to interact with any of these attributes. Another vendor might
only require it only for certain attributes they deemed protected.
So again, Dell's flow might not scale to everyone else.
I do acknowledge this might be mitigatable by adding a sysfs file to every
attribute for Dell's implementation "is_authentication_required" that is always
1 when admin password required and in another implementation an OEM might choose
to set that on a case by case basis.
"outside"We could even do something like we have for .desktop files
fields, where we add something to the sysfs ABI documentation
that vendors may add vendor specific types prefixed with X-<vendorname>.
So all in all I believe that we can make using the proposed sysfs ABI
a generic one work, and that this will be worth it to avoid having the
issue of eventually having both a couple of vendor specific APIs +
one grant unified generic API replacing those vendor-APIs
(where we can never drop the vendor specific APIs because of
backward compat. guarantees).
I'm personally leaning on the right place to have a vendor agnostic view is
of the kernel in an userland library. All the vendor drivers that changesettings can
behave very similarly for the most part, but differences between vendorimplementations
can be better expressed there.
We have tried that before in several cases (that I'm aware of) and this never
works out. Esp. not when the basic kernel interface is reasonable sane,
then a lot of people / projects avoid the lib and just poke the kernel API
directly. We have seen this e.g. with hwmon-class devices and with v4l devices
and with backlight-class devices. Since I've seen this happen 3 times already
I'm not a big believer in adding a userspace library to hide the vendor
Another area that comes to mind is Dell's value_modifier and modifier rules. This
dependency logic is handled and expressed by the firmware. You'll notice the Dell
driver only displays the information that came out of the firmware in sysfs and doesn't
do any processing in driver.
So by using Dell's format, another vendor's driver will need to follow Dell's
formatting and rule validation/generation which their firmware might not support and
they will be forced to implement Dell's schema in their kernel driver.
Lastly I want to caution that individual firmware items with the same name might have
a different meaning across vendors. Here is my hypothetical example:
Dell has an attribute called "Camera" With V3 it populates under:
The description sysfs for it reads as "Enable Camera" and it's possible values are
"Disabled;Enabled;". For Dell this is pretty obviously it turns on and off the camera
For another vendor they might actually not offer to enable/disable the camera but instead
To enable the control of an electromagnetic camera shutter from such an attribute.
Their attribute could still be called "Camera" but the description might read as
"Enable camera shutter control". For them it would still read as "Disabled;Enabled;"
for possible values but have a completely different meaning!
There is no standard for this, and again userspace will need to basically look at
the directory and structure to figure out what the meaning actually is.