Standard FW update package structure - use PLDM?

[Patrick Williams]

On Wed, Jun 02, 2021 at 09:48:18AM +0530, Deepak Kodihalli wrote:
> The PLDM FW update spec [1] defines a structure to package firmware
> images - primarily to identify target devices and to associate them
> with software versions. This is done via metadata in the package, and
> the metadata itself is defined in terms of generic concepts (like
> UUIDs, PCI vendor IDs, version strings etc). For devices that do
> support PLDM, the 'UpdateAgent' (typically the BMC) uses this package
> structure plus a set of standard PLDM commands to talk to the devices
> to perform FW update.

I think historically how we arrived at our own format was that the
predominant format at the time (I've even forgotten the name) required
you to buy a physical copy of the spec and there were only proprietary
tools available to build images in that format with.  Creating our own
[open source] tool was, in effect, a violation of the "buy a copy of the
spec" license being imposed by that organization.

Great that PLDM is now defining a spec in the open...

> For platforms that enable FW update of multiple entities through the
> BMC (this could be a mix of the BMC itself and other PLDM/non-PLDM
> devices), I think the current OpenBMC mechanism involves the use of a
> VersionPurpose [2] interface in order to map FW images to devices. A
> couple of problems with this approach:
> - Can this enumeration cover all possible device types?

I've discussed this in a few places, but maybe not the mailing list, and
it is something that needs to be solved in the near-term anyhow.

Summary of thoughts:

    1. I don't want to add any more devices to the enumeration list[1]
       and would like to deprecate at least PSU.

    2. I'd like to see something defined along the lines of device tree
       compatible strings, along with a well-defined schema, to indicate
       which devices an image can be applied to.

The current design of the enumerations is rather limited.  A specific
problem with it already is that a VersionPurpose=BMC doesn't actually
mean that the image is appropriate for *this* BMC.  Many vendors have
two models, and images signed by the same key, but want to be able to
prevent the image from Model A to be flashed onto Model B hardware.

I haven't read this spec, but it sounds like the PLDM spec is similarly
aligned with a Compatible concept in that PCIe IDs and/or IANA
identifiers can be used.  On the surface it seems to me like we could
create our existing Software.Version objects using a PLDM-format image
and derive the new Compatible objects from these identifiers.

> - How does this fit with PLDM?
> 
> Instead of the VersionPurpose based approach, how about using the PLDM
> FW update package structure as the standard to target devices and to
> associate devices with versions, even for non-PLDM devices? This means
> FW images uploaded to the BMC will be packaged in the PLDM FW update
> format. I don't think this is a violation of the PLDM FW update spec
> (also checking with PMCI WG). For non-PLDM devices, this means using
> just the package structure, not PLDM commands.

I don't see anything wrong on the surface with enhancing our
`ImageManager` concept[2] implementation to support PLDM-format also.
Should this code go into phosphor-bmc-code-mgmt though rather than become
intrinsic to PLDM?  It seems to me like the `ItemUpdater` for PLDM
devices is the only part that needs to be in the PLDM codebase.

I do have questions on how PLDM handles digital signatures and image
verification.  I suspect that it would be insufficient for many users
such that we wouldn't want it to be the primary image packaging method.
Fundamentally, my feeling of insufficiency is around vendor-provided
images:

    If I have a FooCorp NIC installed in my system, which supports PLDM
    update, and FooCorp releases a new image on their website, do I:

        a. Want my user to be able to download FooCorp's image and
           install it directly using their PLDM update file?
        b. Want my user to only install an image that I've qualified
           on in our configuration and additionally signed with *my* keys?

For some vendors (a) is their designed answer and for some (b) is.
Allowing the BMC to take a raw PLDM update image and directly send it
to the NIC satisfies (a).  Using the OpenBMC signed tarball scheme
satisfies (b), since the BMC will reject the tarball if it isn't signed
with keys already trusted by the system and the NIC will reject the
embedded PLDM image if it wasn't signed with FooCorp's keys trusted by
the hardware.

1. https://github.com/openbmc/phosphor-dbus-interfaces/blob/master/yaml/xyz/openbmc_project/Software/Version.interface.yaml#L19
2. https://github.com/openbmc/phosphor-dbus-interfaces/blob/master/yaml/xyz/openbmc_project/Software/README.md#overview
-- 
Patrick Williams
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20210708/35e5dbe1/attachment.sig>