On Wed, 11 Mar 2020 at 07:55, AKASHI Takahiro <takahiro.aka...@linaro.org> wrote:
> 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.g...@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. > Sorry, my point was not valid. Let's check all cases. If the storage is accessible from untrusted world: - single storage for firmware and the OS: we can't orchestrate access to storage between OS and Firmware. - dedicated storage for firmware (eMMC for firmware, SSD for OS): exclusive access can be achieved (not mounted by LInux and no common controller), we may be able to avoid one boot cycle and do the update directly. > If the storage is only accessible from TrustZone, the update is conducted by TrustZone code which has exclusive access to device, so update can happen at runtime. We don't want to work on this at this stage. And may be not in the long term: I think this is a vendor opportunity to differentiate and it feels way too complex to make it generic. > > > 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@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.o...@linaro.org | Skype: ffozog > > _______________________________________________ > > boot-architecture mailing list > > boot-architecture@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.o...@linaro.org | Skype: ffozog _______________________________________________ boot-architecture mailing list boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture
