Re: [PATCH v12 10/13] HP BIOSCFG driver - spmobj-attributes

[Ilpo Järvinen]

On Wed, 10 May 2023, Jorge Lopez wrote:

> On Tue, May 9, 2023 at 8:48 AM Ilpo Järvinen
> <ilpo.jarvinen@xxxxxxxxxxxxxxx> wrote:
> >
> > On Fri, 5 May 2023, 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.
> > >
> > > Many features of HP Commercial notebooks 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 BIOSCFG 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 HP-specific firmware sysfs attributes such Secure
> > > Platform Management and Sure Start. Each section provides security
> > > feature description and identifies sysfs directories and files exposed
> > > by the driver.
> > >
> > > Many HP Commercial notebooks 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 notebooks 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 cryptographic signature-based authorization
> > > string that the BIOS will use to verify authorization to modify the
> > > setting.
> > >
> > > Linux Security components are under development and not published yet.
> > > The only linux component is the driver (hp bioscfg) at this time.
> > > Other published security components are under Windows.
> > >
> > > Signed-off-by: Jorge Lopez <jorge.lopez2@xxxxxx>
> > >
> > > ---


> > > +     } else {
> > > +             /*
> > > +              * UTF-16 prefix is append to the * buffer when a BIOS
> >
> > What is "the * buffer" ?
> 
> It is the data stored in 'buffer' variable which is composed of three
> strings concatenated together to be submitted to BIOS via WMI call.
> 'Buffer' will looks something as    [size attribute][attribute][size
> value][value][auth size][auth payload]
> size is the length in bytes,  attribute/value/auth are string represented in u16

Even after this explanation I don't understand why it's called "the * 
buffer". Is that common terminology in this domain (in which case it's 
fine, I just haven't come across such term before)?

> > > +              * admin password is configured in BIOS
> > > +              */
> > > +

[...snip...]

> > > +/*
> > > + * status_show - Reads SPM status
> > > + */
> > > +static ssize_t status_show(struct kobject *kobj, struct kobj_attribute
> > > +                 *attr, char *buf)
> > > +{
> > > +     int ret, i;
> > > +     struct secureplatform_provisioning_data data;
> > > +
> > > +     ret = statusbin(kobj, attr, &data);
> > > +     if (ret < 0)
> > > +             goto status_exit;
> >
> > Can you calculate strnlen() from buf at this point, or is the result
> > garbage? Should you return ret instead here?
> 
> It should return the error instead.
> >
> > > +
> > > +     sysfs_emit(buf, "%s{\n", buf);
> > > +     sysfs_emit(buf, "%s\t\"State\": \"%s\",\n", buf,
> > > +                spm_state_types[data.state]);
> > > +     sysfs_emit(buf, "%s\t\"Version\": \"%d.%d\",\n", buf, data.version[0],
> > > +                data.version[1]);
> > > +
> > > +     /*
> > > +      * state == 0 means secure platform management
> > > +      * feature is not configured in BIOS.
> > > +      */
> > > +     if (data.state == 0)
> > > +             goto status_exit;
> > > +
> > > +     sysfs_emit(buf, "%s\t\"Nonce\": %d,\n", buf, data.nonce);
> > > +     sysfs_emit(buf, "%s\t\"FeaturesInUse\": %d,\n", buf, data.features);
> > > +     sysfs_emit(buf, "%s\t\"EndorsementKeyMod\": \"", buf);
> > > +
> > > +     for (i = 255; i >= 0; i--)
> > > +             sysfs_emit(buf, "%s %u", buf, data.kek_mod[i]);
> > > +
> > > +     sysfs_emit(buf, "%s \",\n", buf);
> > > +     sysfs_emit(buf, "%s\t\"SigningKeyMod\": \"", buf);
> > > +
> > > +     for (i = 255; i >= 0; i--)
> > > +             sysfs_emit(buf, "%s %u", buf, data.sk_mod[i]);
> > > +
> > > +     /* Return buf contents */
> > > +
> > > +     sysfs_emit(buf, "%s \"\n", buf);
> > > +     sysfs_emit(buf, "%s}\n", buf);
> > > +
> > > +status_exit:
> > > +     return strnlen(buf, PAGE_SIZE);
> > > +}
> >
> > Emit buf into buf? There's sysfs_emit_at(), however,
> >
> > while I'm far from sysfs formatting expert, this feels something that
> > tries to expose more than one thing over same sysfs file. Shouldn't they
> > be each in their own files?
> 
> This concern was brought up in earlier reviews but it was decided to
> allow returning the information as a single json file.
> Because the information is part of the same structure and received in
> a single WMI call, separating the components into multiple files can
> cause the data read in one field to be stale by the time is read.

Okay, makes more sense. Maybe add a comment that the return is a json 
string because that's not very obvious (I only realized now when you told 
me).

The other point is still valid though, you should keep length in a 
variable and use sysfs_emit_at() to avoid printing buf into buf on 
every line.


-- 
 i.