RFC: EBBR specification update

AKASHI Takahiro takahiro.akashi at linaro.org
Wed Mar 11 06:56:53 UTC 2020


Regarding capsule update,

On Tue, Mar 10, 2020 at 09:45:28PM +0100, Francois Ozog wrote:
> Le mar. 10 mars 2020 à 21:15, Heinrich Schuchardt <xypron.glpk at gmx.de> a
> écrit :
> > On 3/10/20 5:02 PM, Francois Ozog wrote:

(snip)

> > > VI - UEFI update capsules
> > > Following my view in 0) I think this shall be made mandatory
> >
> > The UEFI specification provides multiple possibilities to update:
> >
> > UpdateCapsule() runtime service - This runtime service is quite hard to
> > implement if there is no storage that is off limits for the operating
> > system.
> >
> We do not favor that. There is no way to trust code that could have been
> compromised in memory.

I'm not sure of the point here, but UpdateCapsule has ability of
verifying a capsule file, and so as long as the system is securely
booted, UpdateCapsule should work as expected. The issue is, as Heinrich
suggested, that we can't assume an "exclusive" access to the device
on which firmware resides akin to a problem in SetVariable at runtime.

> It would mean doing an update of uboot from OPTEE so
> it does not look good as only uboot of a platform knows how to update
> itself.
> 
> >
> > Directory \EFI\UpdateCapsule - A file placed on this directory on the
> > boot device is considered a capsule. This is much easier to implement.
> >
> > Essentially you could also use BootNext to run any binary for updating.
> >
> > I suggest to go for the directory method of capsule updating.
> >
> That’s the goal for the moment. Yet a whole bunch new to be clarified. We
> are working on a document to be commented.

As some of you may know, I'm going to submit a RFC patch series for UEFI
capsule support on U-Boot in a week or so (maybe). With this patch,
we will support "Capsule-on-Disk" only (but without authentication
implemented).

One of my concerns here is about "variable update via a capsule" as
an alternative of "SetVariable at runtime," where values to be set
for variables will be exported as a capsule file and all the updates
will take place after rebooting. This is very useful on systems
where SetVariable is not available at runtime for some reasons.
Some idea has been proposed by Peter[1], but the discussion has been
stalled for a long time.

[1] https://lists.linaro.org/pipermail/boot-architecture/2018-October/000883.html

Thanks,
-Takahiro Akashi


> >
> > >
> > > Section 2.6 of UEFI spec 2.7 mentions
> > > At some point in time we will need to propose UEFI specification update
> > for:
> > > - anti-bricking anti rollback expected behavior
> > > - abstract capsules for "start transaction", "commit", "rollback" when
> > > we will be dealing with system wide transactional updates.
> > > There is probably a lot to state here but I am just starting the
> > discussion.
> > >
> > > VII - UEFI watchdog
> > > Following my view in 0) I think this shall be made mandatory
> >
> > I could imagine the following scenarios where a watchdog is helpful:
> >
> > * A/B scenario: this would require a variable to be updated that
> >    switches between A and B
> > * booting via network (retry)
> >
> Yes: would you consider HTTP booting as an option (not in EBBR though but
> in Uboot)?
> 
> >
> > Watchdogs are available both in EDK II and U-Boot.
> >
> Problem is that a leading industrial OEM reported inconsistency in
> implementation and too small (5 minutes) delay . The exact problem yet need
> to be fully described by the vendor so that it be solved.
> 
> >
> > Best regards
> >
> > Heinrich
> >
> > >
> > > In addition to its definition, it should also integrate consistent
> > > parameters to define total duration covered as well as number of
> > > failed consecutive updates to be triggered as well as how it is
> > > delivered (powercycle, NMI, secureIRQ...)
> > >
> > > Cheers
> > >
> >
> > _______________________________________________
> > boot-architecture mailing list
> > boot-architecture at lists.linaro.org
> > https://lists.linaro.org/mailman/listinfo/boot-architecture
> >
> -- 
> François-Frédéric Ozog | *Director Linaro Edge & Fog Computing Group*
> T: +33.67221.6485
> francois.ozog at linaro.org | Skype: ffozog
> _______________________________________________
> boot-architecture mailing list
> boot-architecture at lists.linaro.org
> https://lists.linaro.org/mailman/listinfo/boot-architecture


More information about the boot-architecture mailing list