Re: [PATCH v6 4/4] Introduction of HP-BIOSCFG driver [4]

Re: [PATCH v6 4/4] Introduction of HP-BIOSCFG driver [4]

[Thomas Weißschuh]

Hi Jorge,

Hans asked me to do a review of your series, so this is it.

I'll start with patch 4 because it is the one with the docs and build
system changes.
Reviews of the other patches and the code of this patch will follow.

In my opinion the best way forward is to drop some of the non-core
and duplicated functionality.
The reduced scope will make review and rework easier and therefore speed
up the process.

Please also Cc the general kernel mailing list
linux-kernel@vger.kernel.org for future revisions.
This will make sure the patchset is picked up and tested by the bots.

On 2023-03-09 14:10:22-0600, Jorge Lopez wrote:
> The purpose for this patch is submit HP BIOSCFG driver to be list of
> HP Linux kernel drivers.  The driver include a total of 12 files
> broken in several patches.

No need for this paragraph.

> HP BIOS Configuration driver purpose is to provide a driver supporting
> the latest sysfs class firmware attributes framework allowing the user
> to change BIOS settings and security solutions on HP Inc.’s commercial
> notebooks.

Here it says "notebooks", below "PC's". Does it also support
non-notebook machines?

> Many features of HP Commercial PC’s can be managed using Windows
> Management Instrumentation (WMI). WMI is an implementation of Web-Based
> Enterprise Management (WBEM) that provides a standards-based interface
> for changing and monitoring system settings.  HP BISOCFG driver provides
> a native Linux solution and the exposed features facilitates the
> migration to Linux environments.
> 
> The Linux security features to be provided in hp-bioscfg driver enables
> managing the BIOS settings and security solutions via sysfs, a virtual
> filesystem that can be used by user-mode applications.   The new
> documentation cover features such Secure Platform Management, Sure
> Admin, and Sure Start.  Each section provides security feature
> description and identifies sysfs directories and files exposed by
> the driver.
> 
> Many HP Commercial PC’s include a feature called Secure Platform
> Management (SPM), which replaces older password-based BIOS settings
> management with public key cryptography. PC secure product management
> begins when a target system is provisioned with cryptographic keys
> that are used to ensure the integrity of communications between system
> management utilities and the BIOS.
> 
> HP Commercial PC’s have several BIOS settings that control its behaviour
> and capabilities, many of which are related to security. To prevent
> unauthorized changes to these settings, the system can be configured
> to use a Sure Admin cryptographic signature-based authorization string
> that the BIOS will use to verify authorization to modify the setting.
> 
> Signed-off-by: Jorge Lopez <jorge.lopez2@hp.com>
> 
> ---
> Based on the latest platform-drivers-x86.git/for-next
> 
> History
> 
> Version 6
> 	Breaks down the changes into 4 patches
> 	SureAdmin-attributes was removed
> 
> Version 5
> 	Remove version 4 patch 1
> 	Address review changes proposed in Version 4
> 	Reorganize all patches number and file order
> ---
>  .../testing/sysfs-class-firmware-attributes   | 107 ++++++-
>  MAINTAINERS                                   |   6 +
>  drivers/platform/x86/hp/hp-bioscfg/Makefile   |  13 +
>  .../x86/hp/hp-bioscfg/biosattr-interface.c    | 303 ++++++++++++++++++
>  .../x86/hp/hp-bioscfg/passwdattr-interface.c  |  51 +++
>  5 files changed, 479 insertions(+), 1 deletion(-)
>  create mode 100644 drivers/platform/x86/hp/hp-bioscfg/Makefile
>  create mode 100644 drivers/platform/x86/hp/hp-bioscfg/biosattr-interface.c
>  create mode 100644 drivers/platform/x86/hp/hp-bioscfg/passwdattr-interface.c
> 
> diff --git a/Documentation/ABI/testing/sysfs-class-firmware-attributes b/Documentation/ABI/testing/sysfs-class-firmware-attributes
> index 4cdba3477176..d1ae6b77da13 100644
> --- a/Documentation/ABI/testing/sysfs-class-firmware-attributes
> +++ b/Documentation/ABI/testing/sysfs-class-firmware-attributes
> @@ -22,6 +22,13 @@ Description:
>  			- integer: a range of numerical values
>  			- string
>  
> +		HP specific types
> +		-----------------
> +			- ordered-list - a set of ordered list valid values
> +			- sure-admin

Does sure-admin still exist?

> +			- sure-start
> +
> +
>  		All attribute types support the following values:
>  
>  		current_value:
> @@ -126,6 +133,38 @@ Description:
>  					value will not be effective through sysfs until this rule is
>  					met.
>  
> +		HP specific class extensions
> +		------------------------------
> +
> +		On HP systems the following additional attributes are available:
> +
> +		"ordered-list"-type specific properties:
> +
> +		elements:
> +					A file that can be read to obtain the possible
> +					list of values of the <attr>. Values are separated using
> +					semi-colon (``;``). The order individual elements are listed
> +					according to their priority.  An Element listed first has the
> +					hightest priority. Writing the list in a different order to
> +					current_value alters the priority order for the particular
> +					attribute.
> +
> +		"sure-start"-type specific properties:
> +
> +		audit_log_entries:
> +					A read-only file that returns the events in the log.
> +
> +					Audit log entry format
> +
> +					Byte 0-15:   Requested Audit Log entry  (Each Audit log is 16 bytes)
> +					Byte 16-127: Unused
> +
> +		audit_log_entry_count:
> +					A read-only file that returns the number of existing audit log events available to be read.
> +
> +					[No of entries],[log entry size],[Max number of entries supported]

sysfs is based on the idea of "one-value-per-file".
The two properties above violate this idea.
Maybe a different interface is needed.

Are these properties very important for the first version of this
driver? If not I would propose to drop them for now and resubmit them
as separate patches after the main driver has been merged.

> +
> +
>  What:		/sys/class/firmware-attributes/*/authentication/
>  Date:		February 2021
>  KernelVersion:	5.11
> @@ -206,7 +245,7 @@ Description:
>  		Drivers may emit a CHANGE uevent when a password is set or unset
>  		userspace may check it again.
>  
> -		On Dell and Lenovo systems, if Admin password is set, then all BIOS attributes
> +		On Dell, Lenovo, and HP systems, if Admin password is set, then all BIOS attributes

No comma after "Lenovo".

>  		require password validation.
>  		On Lenovo systems if you change the Admin password the new password is not active until
>  		the next boot.
> @@ -296,6 +335,15 @@ Description:
>  						echo "signature" > authentication/Admin/signature
>  						echo "password" > authentication/Admin/certificate_to_password
>  
> +		HP specific class extensions
> +		--------------------------------
> +
> +		On HP systems the following additional settings are available:
> +
> +		role: enhanced-bios-auth:
> +					This role is specific to Secure Platform Management (SPM) attribute.
> +					It requires configuring an endorsement (kek) and signing certificate (sk).
> +
>  
>  What:		/sys/class/firmware-attributes/*/attributes/pending_reboot
>  Date:		February 2021
> @@ -364,3 +412,60 @@ Description:
>  		use it to enable extra debug attributes or BIOS features for testing purposes.
>  
>  		Note that any changes to this attribute requires a reboot for changes to take effect.
> +
> +
> +		HP specific class extensions
> +		--------------------------------
> +
> +What:		/sys/class/firmware-attributes/*/authentication/SPM/kek
> +Date:		March 29
> +KernelVersion:	5.18
> +Contact:	"Jorge Lopez" <jorge.lopez2@hp.com>
> +Description:	'kek' is a write-only file that can be used to configure the
> +		RSA public key that will be used by the BIOS to verify
> +		signatures when setting the signing key.  When written,
> +		the bytes should correspond to the KEK certificate
> +		(x509 .DER format containing an OU).  The size of the
> +		certificate must be less than or equal to 4095 bytes.
> +
> +
> +What:		/sys/class/firmware-attributes/*/authentication/SPM/sk
> +Date:		March 29
> +KernelVersion:	5.18
> +Contact:	"Jorge Lopez" <jorge.lopez2@hp.com>
> +Description:	'sk' is a write-only file that can be used to configure the RSA
> +		public key that will be used by the BIOS to verify signatures
> +		when configuring BIOS settings and security features.  When
> +		written, the bytes should correspond to the modulus of the
> +		public key.  The exponent is assumed to be 0x10001.

The names of the files 'SPM', 'kek' and 'sk' are cryptic.

> +
> +
> +What:		/sys/class/firmware-attributes/*/authentication/SPM/status
> +Date:		March 29
> +KernelVersion:	5.18
> +Contact:	"Jorge Lopez" <jorge.lopez2@hp.com>
> +Description:	'status' is a read-only file that returns ASCII text reporting
> +		the status information.
> +
> +		  State:  Not Provisioned / Provisioned / Provisioning in progress
> +		  Version:  Major.   Minor
> +		  Feature Bit Mask: <16-bit unsigned number display in hex>
> +		  SPM Counter: <16-bit unsigned number display in base 10>
> +		  Signing Key Public Key Modulus (base64):
> +		  KEK Public Key Modulus (base64):

This also violates 'one-value-per-file'.
Can it be split into different files?
This would also remove the need for the statusbin file.

For the values:

Status: I think symbolic names are better for sysfs:
        not_provisioned, provisioned, etc.
Feature Bit Mask: Use names.
Keys: It would be nicer if these could be shown directly in the files
      that can be used to configure them.

As before, what is really needed and what can be added later?

> +
> +
> +What:		/sys/class/firmware-attributes/*/authentication/SPM/statusbin
> +Date:		March 29
> +KernelVersion:	5.18
> +Contact:	"Jorge Lopez" <jorge.lopez2@hp.com>
> +Description:	'statusbin' is a read-only file that returns identical status
> +		information reported by 'status' file in binary format.

How does this binary format work?

> +
> +
> +What:		/sys/class/firmware-attributes/*/attributes/last_error
> +Date:		March 29
> +KernelVersion:	5.18
> +Contact:	"Jorge Lopez" <jorge.lopez2@hp.com>
> +Description:	'last_error' is a read-only file that returns WMI error number
> +		and message reported by last WMI command.

Does this provide much value?
Or could this error just be logged via pr_warn_ratelimited()?

> diff --git a/MAINTAINERS b/MAINTAINERS
> index f32538373164..663ae73fb8be 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -9367,6 +9367,12 @@ S:	Obsolete
>  W:	http://w1.fi/hostap-driver.html
>  F:	drivers/net/wireless/intersil/hostap/
>  
> +HP BIOSCFG DRIVER
> +M:	Jorge Lopez <jorge.lopez2@hp.com>
> +L:      platform-driver-x86@vger.kernel.org

Broken whitespace

> +S:	Maintained
> +F:	drivers/platform/x86/hp/hp-bioscfg/
> +
>  HP COMPAQ TC1100 TABLET WMI EXTRAS DRIVER
>  L:	platform-driver-x86@vger.kernel.org
>  S:	Orphan
> diff --git a/drivers/platform/x86/hp/hp-bioscfg/Makefile b/drivers/platform/x86/hp/hp-bioscfg/Makefile
> new file mode 100644
> index 000000000000..529eba6fa47f
> --- /dev/null
> +++ b/drivers/platform/x86/hp/hp-bioscfg/Makefile
> @@ -0,0 +1,13 @@
> +obj-$(CONFIG_HP_BIOSCFG) := hp-bioscfg.o

The kbuild part that defines CONFIG_HP_BIOSCFG is missing, so this is
never built.

drivers/platform/x86/hp/Makefile also needs to reference this Makefile.

After fixing up Kbuild please build the driver with "make W=1" and clean
up all the unused functions/variables.
(This won't catch unused stuff from bioscfg.c, so you have to check
these manually)

> +
> +hp-bioscfg-objs := bioscfg.o	\
> +	enum-attributes.o	\
> +	int-attributes.o	\
> +	string-attributes.o	\
> +	passwdobj-attributes.o	\
> +	biosattr-interface.o	\
> +	passwdattr-interface.o	\
> +	ordered-attributes.o	\
> +	surestart-attributes.o	\
> +	spmobj-attributes.o
> +

> [..] unreviewed code here.

Re: [PATCH v6 4/4] Introduction of HP-BIOSCFG driver [4]

[Mark Pearson]

Hi Jorge,

As I implemented similar on our platforms I have a couple of suggestions which may or may not be helpful.

On Sat, Apr 1, 2023, at 7:58 AM, Thomas Weißschuh wrote:
> Hi Jorge,
>
<snip>
> On 2023-03-09 14:10:22-0600, Jorge Lopez wrote:
<snip>
>
>> Many features of HP Commercial PC’s can be managed using Windows
>> Management Instrumentation (WMI). WMI is an implementation of Web-Based
>> Enterprise Management (WBEM) that provides a standards-based interface
>> for changing and monitoring system settings.  HP BISOCFG driver provides
>> a native Linux solution and the exposed features facilitates the
>> migration to Linux environments.

I'd remove this paragraph personally - but as a minor note, typo in BISOCFG

<snip>
>> 
>> diff --git a/Documentation/ABI/testing/sysfs-class-firmware-attributes b/Documentation/ABI/testing/sysfs-class-firmware-attributes
>> index 4cdba3477176..d1ae6b77da13 100644
>> --- a/Documentation/ABI/testing/sysfs-class-firmware-attributes
>> +++ b/Documentation/ABI/testing/sysfs-class-firmware-attributes
<snip>
>> @@ -126,6 +133,38 @@ Description:
>>  					value will not be effective through sysfs until this rule is
>>  					met.
>>  
>> +		HP specific class extensions
>> +		------------------------------
>> +
>> +		On HP systems the following additional attributes are available:
>> +
>> +		"ordered-list"-type specific properties:
>> +
>> +		elements:
>> +					A file that can be read to obtain the possible
>> +					list of values of the <attr>. Values are separated using
>> +					semi-colon (``;``). The order individual elements are listed
>> +					according to their priority.  An Element listed first has the
>> +					hightest priority. Writing the list in a different order to
>> +					current_value alters the priority order for the particular
>> +					attribute.

isn't this already covered in the 'possible_values' attribute - it's just a string of items? Curious as to when/how this would be used instead of possible_values (but I should probably read the code)
Typo in 'hightest'.

<snip>
>
>> +
>> +
>>  What:		/sys/class/firmware-attributes/*/authentication/
>>  Date:		February 2021
>>  KernelVersion:	5.11
>> @@ -206,7 +245,7 @@ Description:
<snip>
>> @@ -296,6 +335,15 @@ Description:
>>  						echo "signature" > authentication/Admin/signature
>>  						echo "password" > authentication/Admin/certificate_to_password
>>  
>> +		HP specific class extensions
>> +		--------------------------------
>> +
>> +		On HP systems the following additional settings are available:
>> +
>> +		role: enhanced-bios-auth:
>> +					This role is specific to Secure Platform Management (SPM) attribute.
>> +					It requires configuring an endorsement (kek) and signing certificate (sk).
>> +

Your implementation might be different on HP's; but on the Lenovo's this was still used along with the regular roles - it's just the authentication changed from password to a signature approach.

Just checking that you really need a whole new role and that it isn't part of the existing role.

<snip>

>> +		HP specific class extensions
>> +		--------------------------------
>> +
>> +What:		/sys/class/firmware-attributes/*/authentication/SPM/kek
>> +Date:		March 29
>> +KernelVersion:	5.18
>> +Contact:	"Jorge Lopez" <jorge.lopez2@hp.com>
>> +Description:	'kek' is a write-only file that can be used to configure the
>> +		RSA public key that will be used by the BIOS to verify
>> +		signatures when setting the signing key.  When written,
>> +		the bytes should correspond to the KEK certificate
>> +		(x509 .DER format containing an OU).  The size of the
>> +		certificate must be less than or equal to 4095 bytes.
>> +
>> +
>> +What:		/sys/class/firmware-attributes/*/authentication/SPM/sk
>> +Date:		March 29
>> +KernelVersion:	5.18
>> +Contact:	"Jorge Lopez" <jorge.lopez2@hp.com>
>> +Description:	'sk' is a write-only file that can be used to configure the RSA
>> +		public key that will be used by the BIOS to verify signatures
>> +		when configuring BIOS settings and security features.  When
>> +		written, the bytes should correspond to the modulus of the
>> +		public key.  The exponent is assumed to be 0x10001.
>

I wondered if these could be combined with the signature and certificate fields that I implemented for the Lenovo platforms - and those be moved out of the Lenovo specific section and then made general (and optional)
kek looks like it corresponds to certificate and sk to signature?

>
>> +
>> +
>> +What:		/sys/class/firmware-attributes/*/attributes/last_error
>> +Date:		March 29
>> +KernelVersion:	5.18
>> +Contact:	"Jorge Lopez" <jorge.lopez2@hp.com>
>> +Description:	'last_error' is a read-only file that returns WMI error number
>> +		and message reported by last WMI command.
>
> Does this provide much value?
> Or could this error just be logged via pr_warn_ratelimited()?

This one seemed odd to me too - doesn't the driver return the error to the use on a failed WMI access?

Re: [PATCH v6 4/4] Introduction of HP-BIOSCFG driver [4]

[Jorge Lopez]

Hi Mark,

Please see my comments below.

On Sat, Apr 1, 2023 at 7:48 PM Mark Pearson <mpearson-lenovo@squebb.ca> wrote:
>
> Hi Jorge,
>
> As I implemented similar on our platforms I have a couple of suggestions which may or may not be helpful.
>
> On Sat, Apr 1, 2023, at 7:58 AM, Thomas Weißschuh wrote:
> > Hi Jorge,
> >
> <snip>
> > On 2023-03-09 14:10:22-0600, Jorge Lopez wrote:
> <snip>
> >
> >> Many features of HP Commercial PC’s can be managed using Windows
> >> Management Instrumentation (WMI). WMI is an implementation of Web-Based
> >> Enterprise Management (WBEM) that provides a standards-based interface
> >> for changing and monitoring system settings.  HP BISOCFG driver provides
> >> a native Linux solution and the exposed features facilitates the
> >> migration to Linux environments.
>
> I'd remove this paragraph personally - but as a minor note, typo in BISOCFG
>
> <snip>
> >>
> >> diff --git a/Documentation/ABI/testing/sysfs-class-firmware-attributes b/Documentation/ABI/testing/sysfs-class-firmware-attributes
> >> index 4cdba3477176..d1ae6b77da13 100644
> >> --- a/Documentation/ABI/testing/sysfs-class-firmware-attributes
> >> +++ b/Documentation/ABI/testing/sysfs-class-firmware-attributes
> <snip>
> >> @@ -126,6 +133,38 @@ Description:
> >>                                      value will not be effective through sysfs until this rule is
> >>                                      met.
> >>
> >> +            HP specific class extensions
> >> +            ------------------------------
> >> +
> >> +            On HP systems the following additional attributes are available:
> >> +
> >> +            "ordered-list"-type specific properties:
> >> +
> >> +            elements:
> >> +                                    A file that can be read to obtain the possible
> >> +                                    list of values of the <attr>. Values are separated using
> >> +                                    semi-colon (``;``). The order individual elements are listed
> >> +                                    according to their priority.  An Element listed first has the
> >> +                                    hightest priority. Writing the list in a different order to
> >> +                                    current_value alters the priority order for the particular
> >> +                                    attribute.
>
> isn't this already covered in the 'possible_values' attribute - it's just a string of items? Curious as to when/how this would be used instead of possible_values (but I should probably read the code)
> Typo in 'hightest'.

Done.  Possible values provides a list of values in any order.
elements in Ordered-list list items in level of priority such it is
case of list of boot order values.
>
> <snip>
> >
> >> +
> >> +
> >>  What:               /sys/class/firmware-attributes/*/authentication/
> >>  Date:               February 2021
> >>  KernelVersion:      5.11
> >> @@ -206,7 +245,7 @@ Description:
> <snip>
> >> @@ -296,6 +335,15 @@ Description:
> >>                                              echo "signature" > authentication/Admin/signature
> >>                                              echo "password" > authentication/Admin/certificate_to_password
> >>
> >> +            HP specific class extensions
> >> +            --------------------------------
> >> +
> >> +            On HP systems the following additional settings are available:
> >> +
> >> +            role: enhanced-bios-auth:
> >> +                                    This role is specific to Secure Platform Management (SPM) attribute.
> >> +                                    It requires configuring an endorsement (kek) and signing certificate (sk).
> >> +
>
> Your implementation might be different on HP's; but on the Lenovo's this was still used along with the regular roles - it's just the authentication changed from password to a signature approach.
>
> Just checking that you really need a whole new role and that it isn't part of the existing role.
>
Unfortunately, we need a whole new role.

> <snip>
>
> >> +            HP specific class extensions
> >> +            --------------------------------
> >> +
> >> +What:               /sys/class/firmware-attributes/*/authentication/SPM/kek
> >> +Date:               March 29
> >> +KernelVersion:      5.18
> >> +Contact:    "Jorge Lopez" <jorge.lopez2@hp.com>
> >> +Description:        'kek' is a write-only file that can be used to configure the
> >> +            RSA public key that will be used by the BIOS to verify
> >> +            signatures when setting the signing key.  When written,
> >> +            the bytes should correspond to the KEK certificate
> >> +            (x509 .DER format containing an OU).  The size of the
> >> +            certificate must be less than or equal to 4095 bytes.
> >> +
> >> +
> >> +What:               /sys/class/firmware-attributes/*/authentication/SPM/sk
> >> +Date:               March 29
> >> +KernelVersion:      5.18
> >> +Contact:    "Jorge Lopez" <jorge.lopez2@hp.com>
> >> +Description:        'sk' is a write-only file that can be used to configure the RSA
> >> +            public key that will be used by the BIOS to verify signatures
> >> +            when configuring BIOS settings and security features.  When
> >> +            written, the bytes should correspond to the modulus of the
> >> +            public key.  The exponent is assumed to be 0x10001.
> >
>
> I wondered if these could be combined with the signature and certificate fields that I implemented for the Lenovo platforms - and those be moved out of the Lenovo specific section and then made general (and optional)
The behavior with Secure Platform Manager requires having KEK and SK separate.

> kek looks like it corresponds to certificate and sk to signature?
> KEK - Key-Encryption-Key
      SK - Signature Key
> >


> >> +
> >> +
> >> +What:               /sys/class/firmware-attributes/*/attributes/last_error
> >> +Date:               March 29
> >> +KernelVersion:      5.18
> >> +Contact:    "Jorge Lopez" <jorge.lopez2@hp.com>
> >> +Description:        'last_error' is a read-only file that returns WMI error number
> >> +            and message reported by last WMI command.
> >
> > Does this provide much value?
> > Or could this error just be logged via pr_warn_ratelimited()?
>
> This one seemed odd to me too - doesn't the driver return the error to the use on a failed WMI access?
>
It was intended for debug purposes and to determine if the failure was
reported because of WMI error.  The WMI error is masked by the driver
and the error reported by WMI is lost.
for instance,   WMI error 6 is reported by driver as  -EINVAL.
This attribute will be removed and replaced by pr_warn().

Jorge.

Re: [PATCH v6 4/4] Introduction of HP-BIOSCFG driver [4]

[Jorge Lopez]

Hi Thomas,

Please see my comments below.

On Sat, Apr 1, 2023 at 6:58 AM Thomas Weißschuh <thomas@t-8ch.de> wrote:
>
> Hi Jorge,
>
> Hans asked me to do a review of your series, so this is it.
>
> I'll start with patch 4 because it is the one with the docs and build
> system changes.
> Reviews of the other patches and the code of this patch will follow.
>
> In my opinion the best way forward is to drop some of the non-core
> and duplicated functionality.
> The reduced scope will make review and rework easier and therefore speed
> up the process.
>
> Please also Cc the general kernel mailing list
> linux-kernel@vger.kernel.org for future revisions.
> This will make sure the patchset is picked up and tested by the bots.
>
Will do.

> On 2023-03-09 14:10:22-0600, Jorge Lopez wrote:
> > The purpose for this patch is submit HP BIOSCFG driver to be list of
> > HP Linux kernel drivers.  The driver include a total of 12 files
> > broken in several patches.
>
> No need for this paragraph.

I will remove it in the next submission.

>
> > HP BIOS Configuration driver purpose is to provide a driver supporting
> > the latest sysfs class firmware attributes framework allowing the user
> > to change BIOS settings and security solutions on HP Inc.’s commercial
> > notebooks.
>
> Here it says "notebooks", below "PC's". Does it also support
> non-notebook machines?

The initial release of the driver will be supported for business notebooks.
Although the driver is not targeted for non-notebooks machines, the
driver was tested on non-notebooks in the event a decision is made to
targets them

> > --- a/Documentation/ABI/testing/sysfs-class-firmware-attributes
> > +++ b/Documentation/ABI/testing/sysfs-class-firmware-attributes
> > @@ -22,6 +22,13 @@ Description:
> >                       - integer: a range of numerical values
> >                       - string
> >
> > +             HP specific types
> > +             -----------------
> > +                     - ordered-list - a set of ordered list valid values
> > +                     - sure-admin
>
> Does sure-admin still exist?

I will remove that entry.   Sure-admin no longer exist as part of the driver

>> > +             HP specific class extensions
> > +             ------------------------------
> > +
> > +             On HP systems the following additional attributes are available:
> > +
> > +             "ordered-list"-type specific properties:
> > +
> > +             elements:
> > +                                     A file that can be read to obtain the possible
> > +                                     list of values of the <attr>. Values are separated using
> > +                                     semi-colon (``;``). The order individual elements are listed
> > +                                     according to their priority.  An Element listed first has the
> > +                                     hightest priority. Writing the list in a different order to
> > +                                     current_value alters the priority order for the particular
> > +                                     attribute.
> > +
> > +             "sure-start"-type specific properties:
> > +
> > +             audit_log_entries:
> > +                                     A read-only file that returns the events in the log.
> > +
> > +                                     Audit log entry format
> > +
> > +                                     Byte 0-15:   Requested Audit Log entry  (Each Audit log is 16 bytes)
> > +                                     Byte 16-127: Unused
> > +
> > +             audit_log_entry_count:
> > +                                     A read-only file that returns the number of existing audit log events available to be read.
> > +
> > +                                     [No of entries],[log entry size],[Max number of entries supported]
>
> sysfs is based on the idea of "one-value-per-file".
> The two properties above violate this idea.
> Maybe a different interface is needed.
>

Both properties report a single string separated by semicolon.  This
is not different from listing all elements in a single string
separated by semicolon.

> Are these properties very important for the first version of this
> driver? If not I would propose to drop them for now and resubmit them
> as separate patches after the main driver has been merged.
>
We want the initial driver to have all predefined properties available
first.   There are plans to add future properties and features which
will be submitted as patches.

> > +
> > +
> >  What:                /sys/class/firmware-attributes/*/authentication/
> >  Date:                February 2021
> >  KernelVersion:       5.11
> > @@ -206,7 +245,7 @@ Description:
> >               Drivers may emit a CHANGE uevent when a password is set or unset
> >               userspace may check it again.
> >
> > -             On Dell and Lenovo systems, if Admin password is set, then all BIOS attributes
> > +             On Dell, Lenovo, and HP systems, if Admin password is set, then all BIOS attributes
>
> No comma after "Lenovo"

Will do
>
> >               require password validation.
> >               On Lenovo systems if you change the Admin password the new password is not active until
> >               the next boot.
> > @@ -296,6 +335,15 @@ Description:
> >                                               echo "signature" > authentication/Admin/signature
> >                                               echo "password" > authentication/Admin/certificate_to_password
> >
> > +             HP specific class extensions
> > +             --------------------------------
> > +
> > +             On HP systems the following additional settings are available:
> > +
> > +             role: enhanced-bios-auth:
> > +                                     This role is specific to Secure Platform Management (SPM) attribute.
> > +                                     It requires configuring an endorsement (kek) and signing certificate (sk).
> > +
> >
> >  What:                /sys/class/firmware-attributes/*/attributes/pending_reboot
> >  Date:                February 2021
> > @@ -364,3 +412,60 @@ Description:
> >               use it to enable extra debug attributes or BIOS features for testing purposes.
> >
> >               Note that any changes to this attribute requires a reboot for changes to take effect.
> > +
> > +
> > +             HP specific class extensions
> > +             --------------------------------
> > +
> > +What:                /sys/class/firmware-attributes/*/authentication/SPM/kek
> > +Date:                March 29
> > +KernelVersion:       5.18
> > +Contact:     "Jorge Lopez" <jorge.lopez2@hp.com>
> > +Description: 'kek' is a write-only file that can be used to configure the
> > +             RSA public key that will be used by the BIOS to verify
> > +             signatures when setting the signing key.  When written,
> > +             the bytes should correspond to the KEK certificate
> > +             (x509 .DER format containing an OU).  The size of the
> > +             certificate must be less than or equal to 4095 bytes.
> > +
> > +
> > +What:                /sys/class/firmware-attributes/*/authentication/SPM/sk
> > +Date:                March 29
> > +KernelVersion:       5.18
> > +Contact:     "Jorge Lopez" <jorge.lopez2@hp.com>
> > +Description: 'sk' is a write-only file that can be used to configure the RSA
> > +             public key that will be used by the BIOS to verify signatures
> > +             when configuring BIOS settings and security features.  When
> > +             written, the bytes should correspond to the modulus of the
> > +             public key.  The exponent is assumed to be 0x10001.
>
> The names of the files 'SPM', 'kek' and 'sk' are cryptic.

SPM - Secure Platform Manager
kek -  Key-Encryption-Key (KEK)
sk - Signature Key (SK)

Those abbreviations were used because they are industry standard and
reduce the  size of the commands.  Any suggestions?
>
> > +
> > +
> > +What:                /sys/class/firmware-attributes/*/authentication/SPM/status
> > +Date:                March 29
> > +KernelVersion:       5.18
> > +Contact:     "Jorge Lopez" <jorge.lopez2@hp.com>
> > +Description: 'status' is a read-only file that returns ASCII text reporting
> > +             the status information.
> > +
> > +               State:  Not Provisioned / Provisioned / Provisioning in progress
> > +               Version:  Major.   Minor
> > +               Feature Bit Mask: <16-bit unsigned number display in hex>
> > +               SPM Counter: <16-bit unsigned number display in base 10>
> > +               Signing Key Public Key Modulus (base64):
> > +               KEK Public Key Modulus (base64):
>
> This also violates 'one-value-per-file'.
> Can it be split into different files?

I will split the information in multiple files.

> This would also remove the need for the statusbin file.
>
Status bin is used by GUI applications where data is managed
accordingly instead of individual lines.

> For the values:
>
> Status: I think symbolic names are better for sysfs:
>         not_provisioned, provisioned, etc.
> Feature Bit Mask: Use names.
> Keys: It would be nicer if these could be shown directly in the files
>       that can be used to configure them.
>
> As before, what is really needed and what can be added later?

Status is needed when the user enables Secure Platform Manager in BIOS
and  KEK and/or SK are configured.

>
> > +
> > +
> > +What:                /sys/class/firmware-attributes/*/authentication/SPM/statusbin
> > +Date:                March 29
> > +KernelVersion:       5.18
> > +Contact:     "Jorge Lopez" <jorge.lopez2@hp.com>
> > +Description: 'statusbin' is a read-only file that returns identical status
> > +             information reported by 'status' file in binary format.
>
> How does this binary format work?

Yes.  Status bin is used by GUI applications where data is managed
accordingly instead of individual lines

>
> > +
> > +
> > +What:                /sys/class/firmware-attributes/*/attributes/last_error
> > +Date:                March 29
> > +KernelVersion:       5.18
> > +Contact:     "Jorge Lopez" <jorge.lopez2@hp.com>
> > +Description: 'last_error' is a read-only file that returns WMI error number
> > +             and message reported by last WMI command.
>
> Does this provide much value?
> Or could this error just be logged via pr_warn_ratelimited()?

It is specially needed to determine if WMI calls reported an error.
This property is similar to the one provided by both Dell and Lenovo
drivers
>
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index f32538373164..663ae73fb8be 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -9367,6 +9367,12 @@ S:     Obsolete
> >  W:   http://w1.fi/hostap-driver.html
> >  F:   drivers/net/wireless/intersil/hostap/
> >
> > +HP BIOSCFG DRIVER
> > +M:   Jorge Lopez <jorge.lopez2@hp.com>
> > +L:      platform-driver-x86@vger.kernel.org
>
> Broken whitespace

I will be corrected.

>
> > +S:   Maintained
> > +F:   drivers/platform/x86/hp/hp-bioscfg/
> > +
> >  HP COMPAQ TC1100 TABLET WMI EXTRAS DRIVER
> >  L:   platform-driver-x86@vger.kernel.org
> >  S:   Orphan
> > diff --git a/drivers/platform/x86/hp/hp-bioscfg/Makefile b/drivers/platform/x86/hp/hp-bioscfg/Makefile
> > new file mode 100644
> > index 000000000000..529eba6fa47f
> > --- /dev/null
> > +++ b/drivers/platform/x86/hp/hp-bioscfg/Makefile
> > @@ -0,0 +1,13 @@
> > +obj-$(CONFIG_HP_BIOSCFG) := hp-bioscfg.o
>
> The kbuild part that defines CONFIG_HP_BIOSCFG is missing, so this is
> never built.
>

This is an oversight on my part.  The changes were made but never made
part of the review.

> drivers/platform/x86/hp/Makefile also needs to reference this Makefile.
>
> After fixing up Kbuild please build the driver with "make W=1" and clean
> up all the unused functions/variables.
> (This won't catch unused stuff from bioscfg.c, so you have to check
> these manually)
>

Thank you.  I will make sure to include it

Re: [PATCH v6 4/4] Introduction of HP-BIOSCFG driver [4]

[Thomas Weißschuh]

Hi Jorge,

On 2023-04-03 11:33:20-0500, Jorge Lopez wrote:
> Hi Thomas,
> 
> Please see my comments below.
> 
> On Sat, Apr 1, 2023 at 6:58 AM Thomas Weißschuh <thomas@t-8ch.de> wrote:
> > On 2023-03-09 14:10:22-0600, Jorge Lopez wrote:
> [..]
> > > HP BIOS Configuration driver purpose is to provide a driver supporting
> > > the latest sysfs class firmware attributes framework allowing the user
> > > to change BIOS settings and security solutions on HP Inc.’s commercial
> > > notebooks.
> >
> > Here it says "notebooks", below "PC's". Does it also support
> > non-notebook machines?
> 
> The initial release of the driver will be supported for business notebooks.
> Although the driver is not targeted for non-notebooks machines, the
> driver was tested on non-notebooks in the event a decision is made to
> targets them

If it is not intended to support both, maybe the documentation could
consistently use "notebook".

> > > +             "sure-start"-type specific properties:
> > > +
> > > +             audit_log_entries:
> > > +                                     A read-only file that returns the events in the log.
> > > +
> > > +                                     Audit log entry format
> > > +
> > > +                                     Byte 0-15:   Requested Audit Log entry  (Each Audit log is 16 bytes)
> > > +                                     Byte 16-127: Unused
> > > +
> > > +             audit_log_entry_count:
> > > +                                     A read-only file that returns the number of existing audit log events available to be read.
> > > +
> > > +                                     [No of entries],[log entry size],[Max number of entries supported]
> >
> > sysfs is based on the idea of "one-value-per-file".
> > The two properties above violate this idea.
> > Maybe a different interface is needed.
> >
> 
> Both properties report a single string separated by semicolon.  This
> is not different from listing all elements in a single string
> separated by semicolon.

The documentation does not mention semicolons.

The nice thing about descoping functionality is that we don't need to
worry about their details now.
Instead it can be added later without haste as the core functionality
can already be used by the users.

> > Are these properties very important for the first version of this
> > driver? If not I would propose to drop them for now and resubmit them
> > as separate patches after the main driver has been merged.
> >
> We want the initial driver to have all predefined properties available
> first.   There are plans to add future properties and features which
> will be submitted as patches.

With "properties" do you mean the bios settings?
I agree that all these are good for the initial driver.

But the audit log, detailed error codes, etc... do not seem integral for
the functioning of the driver or for users.

> > > +             HP specific class extensions
> > > +             --------------------------------
> > > +
> > > +What:                /sys/class/firmware-attributes/*/authentication/SPM/kek
> > > +Date:                March 29
> > > +KernelVersion:       5.18
> > > +Contact:     "Jorge Lopez" <jorge.lopez2@hp.com>
> > > +Description: 'kek' is a write-only file that can be used to configure the
> > > +             RSA public key that will be used by the BIOS to verify
> > > +             signatures when setting the signing key.  When written,
> > > +             the bytes should correspond to the KEK certificate
> > > +             (x509 .DER format containing an OU).  The size of the
> > > +             certificate must be less than or equal to 4095 bytes.
> > > +
> > > +
> > > +What:                /sys/class/firmware-attributes/*/authentication/SPM/sk
> > > +Date:                March 29
> > > +KernelVersion:       5.18
> > > +Contact:     "Jorge Lopez" <jorge.lopez2@hp.com>
> > > +Description: 'sk' is a write-only file that can be used to configure the RSA
> > > +             public key that will be used by the BIOS to verify signatures
> > > +             when configuring BIOS settings and security features.  When
> > > +             written, the bytes should correspond to the modulus of the
> > > +             public key.  The exponent is assumed to be 0x10001.
> >
> > The names of the files 'SPM', 'kek' and 'sk' are cryptic.
> 
> SPM - Secure Platform Manager
> kek -  Key-Encryption-Key (KEK)
> sk - Signature Key (SK)
> 
> Those abbreviations were used because they are industry standard and
> reduce the  size of the commands.  Any suggestions?

Maybe mention the long names once in the documentation "Description".

> > > +
> > > +
> > > +What:                /sys/class/firmware-attributes/*/authentication/SPM/status
> > > +Date:                March 29
> > > +KernelVersion:       5.18
> > > +Contact:     "Jorge Lopez" <jorge.lopez2@hp.com>
> > > +Description: 'status' is a read-only file that returns ASCII text reporting
> > > +             the status information.
> > > +
> > > +               State:  Not Provisioned / Provisioned / Provisioning in progress
> > > +               Version:  Major.   Minor
> > > +               Feature Bit Mask: <16-bit unsigned number display in hex>
> > > +               SPM Counter: <16-bit unsigned number display in base 10>
> > > +               Signing Key Public Key Modulus (base64):
> > > +               KEK Public Key Modulus (base64):
> >
> > This also violates 'one-value-per-file'.
> > Can it be split into different files?
> 
> I will split the information in multiple files.
> 
> > This would also remove the need for the statusbin file.
> >
> Status bin is used by GUI applications where data is managed
> accordingly instead of individual lines.

Can the GUI applications not use the split files?

> > For the values:
> >
> > Status: I think symbolic names are better for sysfs:
> >         not_provisioned, provisioned, etc.
> > Feature Bit Mask: Use names.
> > Keys: It would be nicer if these could be shown directly in the files
> >       that can be used to configure them.
> >
> > As before, what is really needed and what can be added later?
> 
> Status is needed when the user enables Secure Platform Manager in BIOS
> and  KEK and/or SK are configured.

Ok.

> >
> > > +
> > > +
> > > +What:                /sys/class/firmware-attributes/*/authentication/SPM/statusbin
> > > +Date:                March 29
> > > +KernelVersion:       5.18
> > > +Contact:     "Jorge Lopez" <jorge.lopez2@hp.com>
> > > +Description: 'statusbin' is a read-only file that returns identical status
> > > +             information reported by 'status' file in binary format.
> >
> > How does this binary format work?
> 
> Yes.  Status bin is used by GUI applications where data is managed
> accordingly instead of individual lines

But this format is not documented here at all.
So how can we determine if the implementation is correct?

> > > +
> > > +
> > > +What:                /sys/class/firmware-attributes/*/attributes/last_error
> > > +Date:                March 29
> > > +KernelVersion:       5.18
> > > +Contact:     "Jorge Lopez" <jorge.lopez2@hp.com>
> > > +Description: 'last_error' is a read-only file that returns WMI error number
> > > +             and message reported by last WMI command.
> >
> > Does this provide much value?
> > Or could this error just be logged via pr_warn_ratelimited()?
> 
> It is specially needed to determine if WMI calls reported an error.
> This property is similar to the one provided by both Dell and Lenovo
> drivers

I don't see similar functionality for the other drivers.
Instead they seem to just return the error codes from the attribute
callbacks.

This may be useful but it does not seem *necessary* for the first
version.


Feel free to only submit the patch with the documentation for the next
revision. Then we can nail down the interface and initial functionality
and you don't always have to adapt the code to the changing interface.

Thomas

Re: [PATCH v6 4/4] Introduction of HP-BIOSCFG driver [4]

[Jorge Lopez]

Hi Thomas,

Please see my comments below.

> > > > HP BIOS Configuration driver purpose is to provide a driver supporting
> > > > the latest sysfs class firmware attributes framework allowing the user
> > > > to change BIOS settings and security solutions on HP Inc.’s commercial
> > > > notebooks.
> > >
> > > Here it says "notebooks", below "PC's". Does it also support
> > > non-notebook machines?
> >
> > The initial release of the driver will be supported for business notebooks.
> > Although the driver is not targeted for non-notebooks machines, the
> > driver was tested on non-notebooks in the event a decision is made to
> > targets them
>
> If it is not intended to support both, maybe the documentation could
> consistently use "notebook".

Ok.
>
> > > > +             "sure-start"-type specific properties:
> > > > +
> > > > +             audit_log_entries:
> > > > +                                     A read-only file that returns the events in the log.
> > > > +
> > > > +                                     Audit log entry format
> > > > +
> > > > +                                     Byte 0-15:   Requested Audit Log entry  (Each Audit log is 16 bytes)
> > > > +                                     Byte 16-127: Unused
> > > > +
> > > > +             audit_log_entry_count:
> > > > +                                     A read-only file that returns the number of existing audit log events available to be read.
> > > > +
> > > > +                                     [No of entries],[log entry size],[Max number of entries supported]
> > >
> > > sysfs is based on the idea of "one-value-per-file".
> > > The two properties above violate this idea.
> > > Maybe a different interface is needed.
> > >
> >
> > Both properties report a single string separated by semicolon.  This
> > is not different from listing all elements in a single string
> > separated by semicolon.
>
> The documentation does not mention semicolons.

It should have been documented.  I will update the docs.

>
> The nice thing about descoping functionality is that we don't need to
> worry about their details now.
> Instead it can be added later without haste as the core functionality
> can already be used by the users.
>
> > > Are these properties very important for the first version of this
> > > driver? If not I would propose to drop them for now and resubmit them
> > > as separate patches after the main driver has been merged.
> > >
> > We want the initial driver to have all predefined properties available
> > first.   There are plans to add future properties and features which
> > will be submitted as patches.
>
> With "properties" do you mean the bios settings?
> I agree that all these are good for the initial driver.

Yes.  All those properties are part of BIOS setting and security
related features.
>
> But the audit log, detailed error codes, etc... do not seem integral for
> the functioning of the driver or for users.

Error codes can be replaced as pr_warn() log when error is not zero.
Audit_log on the hand, it is part of the initial features we need.to
have.

>
> > > > +             HP specific class extensions
> > > > +             --------------------------------
> > > > +
> > > > +What:                /sys/class/firmware-attributes/*/authentication/SPM/kek
> > > > +Date:                March 29
> > > > +KernelVersion:       5.18
> > > > +Contact:     "Jorge Lopez" <jorge.lopez2@hp.com>
> > > > +Description: 'kek' is a write-only file that can be used to configure the
> > > > +             RSA public key that will be used by the BIOS to verify
> > > > +             signatures when setting the signing key.  When written,
> > > > +             the bytes should correspond to the KEK certificate
> > > > +             (x509 .DER format containing an OU).  The size of the
> > > > +             certificate must be less than or equal to 4095 bytes.
> > > > +
> > > > +
> > > > +What:                /sys/class/firmware-attributes/*/authentication/SPM/sk
> > > > +Date:                March 29
> > > > +KernelVersion:       5.18
> > > > +Contact:     "Jorge Lopez" <jorge.lopez2@hp.com>
> > > > +Description: 'sk' is a write-only file that can be used to configure the RSA
> > > > +             public key that will be used by the BIOS to verify signatures
> > > > +             when configuring BIOS settings and security features.  When
> > > > +             written, the bytes should correspond to the modulus of the
> > > > +             public key.  The exponent is assumed to be 0x10001.
> > >
> > > The names of the files 'SPM', 'kek' and 'sk' are cryptic.
> >
> > SPM - Secure Platform Manager
> > kek -  Key-Encryption-Key (KEK)
> > sk - Signature Key (SK)
> >
> > Those abbreviations were used because they are industry standard and
> > reduce the  size of the commands.  Any suggestions?
>
> Maybe mention the long names once in the documentation "Description".

Ok.  I will do so.
>
> > > > +
> > > > +
> > > > +What:                /sys/class/firmware-attributes/*/authentication/SPM/status
> > > > +Date:                March 29
> > > > +KernelVersion:       5.18
> > > > +Contact:     "Jorge Lopez" <jorge.lopez2@hp.com>
> > > > +Description: 'status' is a read-only file that returns ASCII text reporting
> > > > +             the status information.
> > > > +
> > > > +               State:  Not Provisioned / Provisioned / Provisioning in progress
> > > > +               Version:  Major.   Minor
> > > > +               Feature Bit Mask: <16-bit unsigned number display in hex>
> > > > +               SPM Counter: <16-bit unsigned number display in base 10>
> > > > +               Signing Key Public Key Modulus (base64):
> > > > +               KEK Public Key Modulus (base64):
> > >
> > > This also violates 'one-value-per-file'.
> > > Can it be split into different files?
> >
> > I will split the information in multiple files.

The data reported by status files is gathered by a single WMI called
(statusbin) and then reported by adding multiple headers (ie Feature
Bit Mask:).   Do we still need to split the status lines?  Instead of
making one call, the driver would be making multiple calls to
'statusbin' routine and then report the appropriate item for the file.
  The additional complexity is unnecessary.

> >
> > > This would also remove the need for the statusbin file.
> > >
> > Status bin is used by GUI applications where data is managed
> > accordingly instead of individual lines.
>
> Can the GUI applications not use the split files?

The GUI applications could use the split lines but he data is just a
blob of binary data of sizeof  struct
secureplatform_provisioning_data.  The lack of headers on the left
handside ((ie Feature Bit Mask:) will eliminate having to split the
data read and make multiple calls to the driver.

>
> > > For the values:
> > >
> > > Status: I think symbolic names are better for sysfs:
> > >         not_provisioned, provisioned, etc.
> > > Feature Bit Mask: Use names.
> > > Keys: It would be nicer if these could be shown directly in the files
> > >       that can be used to configure them.
> > >
> > > As before, what is really needed and what can be added later?
> >
> > Status is needed when the user enables Secure Platform Manager in BIOS
> > and  KEK and/or SK are configured.
>
> Ok.
>
> > >
> > > > +
> > > > +
> > > > +What:                /sys/class/firmware-attributes/*/authentication/SPM/statusbin
> > > > +Date:                March 29
> > > > +KernelVersion:       5.18
> > > > +Contact:     "Jorge Lopez" <jorge.lopez2@hp.com>
> > > > +Description: 'statusbin' is a read-only file that returns identical status
> > > > +             information reported by 'status' file in binary format.
> > >
> > > How does this binary format work?
> >
> > Yes.  Status bin is used by GUI applications where data is managed
> > accordingly instead of individual lines
>
> But this format is not documented here at all.
> So how can we determine if the implementation is correct?

The data gathered by 'statusbin' routine is  struct
secureplatform_provisioning_data.  The validation is done in two ways.
the driver validates the return code from WMI call, and the other is
by inspecting the data reported by 'status' with some additional
headers..

> > > > +
> > > > +
> > > > +What:                /sys/class/firmware-attributes/*/attributes/last_error
> > > > +Date:                March 29
> > > > +KernelVersion:       5.18
> > > > +Contact:     "Jorge Lopez" <jorge.lopez2@hp.com>
> > > > +Description: 'last_error' is a read-only file that returns WMI error number
> > > > +             and message reported by last WMI command.
> > >
> > > Does this provide much value?
> > > Or could this error just be logged via pr_warn_ratelimited()?
> >
> > It is specially needed to determine if WMI calls reported an error.
> > This property is similar to the one provided by both Dell and Lenovo
> > drivers
>
> I don't see similar functionality for the other drivers.
> Instead they seem to just return the error codes from the attribute
> callbacks.

Ok.  last_error can be replaced as pr_warn() log when error value is not zero.
>
> This may be useful but it does not seem *necessary* for the first
> version.
>
>
> Feel free to only submit the patch with the documentation for the next
> revision. Then we can nail down the interface and initial functionality
> and you don't always have to adapt the code to the changing interface.
>

Ok.  I will submit the documentation by it self with the next revision.

Jorge