* Standard FW update package structure - use PLDM? @ 2021-06-02 4:18 Deepak Kodihalli 2021-07-08 11:42 ` Patrick Williams 0 siblings, 1 reply; 3+ messages in thread From: Deepak Kodihalli @ 2021-06-02 4:18 UTC (permalink / raw) To: openbmc Hi, 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. 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? - 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. [1] https://www.dmtf.org/sites/default/files/standards/documents/DSP0267_1.1.0.pdf [2] https://github.com/openbmc/phosphor-dbus-interfaces/blob/master/xyz/openbmc_project/Software/Version.interface.yaml#L19 Thanks, Deepak ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Standard FW update package structure - use PLDM? 2021-06-02 4:18 Standard FW update package structure - use PLDM? Deepak Kodihalli @ 2021-07-08 11:42 ` Patrick Williams 2021-07-12 12:07 ` Deepak Kodihalli 0 siblings, 1 reply; 3+ messages in thread From: Patrick Williams @ 2021-07-08 11:42 UTC (permalink / raw) To: Deepak Kodihalli; +Cc: openbmc [-- Attachment #1: Type: text/plain, Size: 4937 bytes --] 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 [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Standard FW update package structure - use PLDM? 2021-07-08 11:42 ` Patrick Williams @ 2021-07-12 12:07 ` Deepak Kodihalli 0 siblings, 0 replies; 3+ messages in thread From: Deepak Kodihalli @ 2021-07-12 12:07 UTC (permalink / raw) To: Patrick Williams; +Cc: OpenBMC Maillist Hi Patrick, On Thu, Jul 8, 2021 at 5:12 PM Patrick Williams <patrick@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 ^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2021-07-12 12:08 UTC | newest] Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-06-02 4:18 Standard FW update package structure - use PLDM? Deepak Kodihalli 2021-07-08 11:42 ` Patrick Williams 2021-07-12 12:07 ` Deepak Kodihalli
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).