RE: [PATCH] Introduce support for Systems Management Driver over WMI for Dell Systems

[Limonciello, Mario]

> > Those are very different flows to get to and change the same "types" of
> data.  By Dell's interface
> > being Dell specific we can guarantee that the documented flow works how it
> should.
> 
> 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
> unavoidable.

> 
> 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
> implementations.
> 

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.

> >> 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
> "outside"
> > of the kernel in an userland library.  All the vendor drivers that change
> settings can
> > behave very similarly for the most part, but differences between vendor
> implementations
> > 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
> differences.
> 
> Regards,
> 
> Hans

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:
/sys/devices/platform/dell-wmi-sysman/attributes/Camera

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
functionality.

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.