* Re: Update tools (fwupd, swupdate, ...)
2020-05-08 14:16 ` Lee Fisher
@ 2020-05-11 13:02 ` Patrick Williams
0 siblings, 0 replies; 4+ messages in thread
From: Patrick Williams @ 2020-05-11 13:02 UTC (permalink / raw)
To: Lee Fisher; +Cc: openbmc
[-- Attachment #1: Type: text/plain, Size: 2740 bytes --]
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
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 4+ messages in thread