Message-ID: <CAOOmCE-gipT5r1ABCkqkfFCdssKEwHhvz47yYnHa1fy74jAsFQ@mail.gmail.com>
Date:   Mon, 15 May 2023 09:12:30 -0500
From:   Jorge Lopez <jorgealtxwork@...il.com>
To:     Ilpo Järvinen <ilpo.jarvinen@...ux.intel.com>
Cc:     hdegoede@...hat.com, platform-driver-x86@...r.kernel.org,
        LKML <linux-kernel@...r.kernel.org>, thomas@...ch.de
Subject: Re: [PATCH v12 10/13] HP BIOSCFG driver - spmobj-attributes

On Thu, May 11, 2023 at 4:23 AM Ilpo Järvinen
<ilpo.jarvinen@...ux.intel.com> wrote:
>
> On Wed, 10 May 2023, Jorge Lopez wrote:
>
> > On Tue, May 9, 2023 at 8:48 AM Ilpo Järvinen
> > <ilpo.jarvinen@...ux.intel.com> 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@...com>
> > > >
> > > > ---
>
>
> > > > +     } 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)?
>

Point taken.  Replaced 'buffer' variable name to 'authbuf'

> > > > +              * 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.
Done!

> > >
> > > > +
> > > > +     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).
>
A comment will be added.

> 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 will update the function as indicated.

>
> --
>  i.

Powered by blists - more mailing lists