Update tools (fwupd, swupdate, ...)

Patrick Williams patrick at stwcx.xyz
Mon May 11 23:02:09 AEST 2020


On Fri, May 08, 2020 at 07:16:34AM -0700, Lee Fisher wrote:
> On 5/7/20 9:16 PM, Andrew Jeffery wrote:
> 
> > On Fri, 8 May 2020, at 03:33, Adriana Kobylak wrote:
> These days, you should not buy a Linux system if it isn't supported by
> FWupd.
> 

As an end user, I Like fwupd.  It recently told me about a firmware
update for my mouse that I didn't realize even had firmware.  Alright,
everything has firmware but I would have never looked for a security
firmware update to my mouse.

> If OpenBMC doesn't support FWUpd they'll need to duplicate most of the
> infra that FWUpd has.
> 
> Having OpenBMC support FWupd would be a very good security feature.

I would be curious about how fwupd plans to support enterprise-level
deployments in the long term.  As it stands right now, I don't see a lot
of value for fwupd for any large system deployment.  I bet most large
deployments already have their own firmware update infrastructure
anyhow.

Some features that seem to be missing from a large deployment
perspective:

- Private repository.
    * When we are in development we have unannounced systems with
      unannounced hardware (IO cards, processors, etc.).  We couldn't
      push our images to a public repository at that point, but would
      want to update the same way we eventually would in production.

- Individual signing keys.
    * Even if an image comes from a vendor, for security reasons we
      would want to sign it with our own signing keys.

- Large-scale roll-back.
    * fwupd does have roll-back at an individual system level.  Can you
      can you do it for a whole deployment?  (It seems like roll-back
      only works if the end-device has room to save the roll-back
      image?)

- Continuous deployment techniques:
    - Test cluster deployment.
        * How do I create a test cluster that gets firmware updates
          earlier for qualification purposes?
    - Blue-green deployment.
        * How do I limit the roll-out updates so my whole deployment
          doesn't get updated at once?

I can understand how it would look promising from a hardware vendor
perspective and when I worked at a hardware vendor I often wondered
"why can't we get our customers to update to our latest and greatest
code quicker?"  The answer is that an organization of any size and
history has been bitten by a firmware update at some point and put in
their own processes and infrastructure for managing firmware updates.
Unless fwupd can facilitate those processes, there probably won't be
much uptake from large deployments.  Even if it can, there ends up being
some legacy infrastructure that would need to be migrated from.

-- 
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/20200511/39d325db/attachment.sig>


More information about the openbmc mailing list