Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <20230309201022.9502-1-jorge.lopez2@hp.com> <20230309201022.9502-5-jorge.lopez2@hp.com>
 <6da33dcc-0526-4398-bf35-655b64d07e20@t-8ch.de> <CAOOmCE_kzVnUr9WoPAEu-e+E5=-RfHUCjj6U7kL_yhqKHsP84g@mail.gmail.com>
 <f68304f0-c533-434d-9f74-92327cd4a002@t-8ch.de>
In-Reply-To: <f68304f0-c533-434d-9f74-92327cd4a002@t-8ch.de>
From:   Jorge Lopez <jorgealtxwork@gmail.com>
Date:   Mon, 3 Apr 2023 14:33:53 -0500
Message-ID: <CAOOmCE8aQ3YOyheC_U27FtV1xcMgV73eNsr9aooboqijaHENaA@mail.gmail.com>
Subject: Re: [PATCH v6 4/4] Introduction of HP-BIOSCFG driver [4]
To:     =?UTF-8?Q?Thomas_Wei=C3=9Fschuh?= <thomas@t-8ch.de>
Cc:     hdegoede@redhat.com, platform-driver-x86@vger.kernel.org,
        linux-kernel@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

Hi Thomas,

Please see my comments below.

> > > > HP BIOS Configuration driver purpose is to provide a driver support=
ing
> > > > the latest sysfs class firmware attributes framework allowing the u=
ser
> > > > to change BIOS settings and security solutions on HP Inc.=E2=80=99s=
 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 notebo=
oks.
> > 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 si=
ze],[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/*/authenticati=
on/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 config=
ure the
> > > > +             RSA public key that will be used by the BIOS to verif=
y
> > > > +             signatures when setting the signing key.  When writte=
n,
> > > > +             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/*/authenticati=
on/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 configu=
re the RSA
> > > > +             public key that will be used by the BIOS to verify si=
gnatures
> > > > +             when configuring BIOS settings and security features.=
  When
> > > > +             written, the bytes should correspond to the modulus o=
f 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/*/authenticati=
on/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 / Provisionin=
g in progress
> > > > +               Version:  Major.   Minor
> > > > +               Feature Bit Mask: <16-bit unsigned number display i=
n hex>
> > > > +               SPM Counter: <16-bit unsigned number display in bas=
e 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/*/authenticati=
on/SPM/statusbin
> > > > +Date:                March 29
> > > > +KernelVersion:       5.18
> > > > +Contact:     "Jorge Lopez" <jorge.lopez2@hp.com>
> > > > +Description: 'statusbin' is a read-only file that returns identica=
l status
> > > > +             information reported by 'status' file in binary forma=
t.
> > >
> > > 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/l=
ast_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 err=
or 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 ze=
ro.
>
> 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