Standard FW update package structure - use PLDM?

[Deepak Kodihalli]

Hi Patrick,

On Thu, Jul 8, 2021 at 5:12 PM Patrick Williams <patrick at stwcx.xyz> wrote:

> 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.

Right, I had something similar in mind.

> > - 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 envisioned the PLDM codebase to act both as ImageManager and
ItemUpdater. Phosphor-bmc-code-mgmt could still implement image
signature verification.

> 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.

The OpenBMC signed tarball scheme could still be used and it could
contain a PLDM format FW package? My intent with the PLDM format was
to solve the 'Compatible Devices' problem, and specifically for a case
where the device may actually not support PLDM messages for FW update.

Thanks,
Deepak