On Mon, 18 May 2020 at 14:26, Grant Likely <[email protected]> wrote:
> > > On 12/05/2020 20:21, Heinrich Schuchardt wrote: > > Am May 12, 2020 5:15:26 PM UTC schrieb Grant Likely < > [email protected]>: > >> > >> > >> On 06/05/2020 20:09, Heinrich Schuchardt wrote: > >>> On 5/6/20 3:18 PM, Grant Likely wrote: > >>>> > >>>> > >>>> On 05/05/2020 17:41, Heinrich Schuchardt wrote: > >>>>> On 05.05.20 17:44, Grant Likely wrote: > >>>>>> Hi all, > >>>>>> > >>>>>> I'm considering doing a quick point-release for EBBR to address > >> the > >>>>>> change to RuntimeServicesSupported in UEFI 2.8 Errata A. From > >> 2.8final > >>>>>> to 2.8_A, RuntimeServicesSupported changed from being a variable > >> to data > >>>>>> in a system table entry. U-Boot and Linux have been updated to the > >> UEFI > >>>>>> method. EBBR needs to be changed to match. > >>>>>> > >>>>>> There are patches on this list under discussion now. Once that is > >>>>>> complete and the patches merged, how does everyone feel about an > >> EBBR > >>>>>> v1.0.1 release before the end of May? > >>>>>> > >>>>>> At this moment, the v1.0.1 changes would include: > >>>>>> > >>>>>> e47952b (HEAD -> master, glikely/master) Specify details of how a > >> DTB is > >>>>>> passed to the OS > >>>>> > >>>>> Thanks for updating the patch. > >>>>> > >>>>>> c155e96 Update spec to address UEFI 2.8 Errata A > >>>>> > >>>>> The patch looks correct. This is what I stumbled upon looking at > >> the > >>>>> rest of the runtime chapter: > >>>>> > >>>>> The 'Runtime Variable Access' sub-chapter mentions only > >> SetVariable() as > >>>>> optional while the table above it specifies all variable services > >> as > >>>>> optional. Could we start the sub-chapter with a sentence > >>>>> > >>>>> "All variable services at runtime are optional." > >>>>> > >>>>> to avoid misunderstandings. > >>>>> > >>>>> The `RuntimeServicesSupported` value flag in the > >>>>> `EFI_RT_PROPERTIES_TABLE` should be set correctly for all runtime > >>>>> services. Mentioning this requirement specifically for > >> SetVariable() > >>>>> might be misleading. > >>>> > >>>> This is a bit tricky. In past conversations I was pushing toward > >> making > >>>> GetVariable()/GetNextVariableName() required and only SetVariable() > >>>> optional, but there wasn't concensus at that time. The text as it > >> stands > >>>> it kind of a mix on whether or not GetVariable() is required or > >> merely > >>>> recommended. > >>>> > >>>> For the point release that we do soon, I could tidy up the text a > >> bit, > >>>> but I'd like some thoughts on where EBBR should go for the next > >> major > >>>> revision. GetVariable() should be straight forward to implement > >>>> GetVariable at runtime by using a RAM-cached value. I don't believe > >> any > >>>> work has been done to support that in U-Boot. > >>> > >>> See this patch series that is not yet merged: > >>> https://patchwork.ozlabs.org/project/uboot/list/?series=167069 > >>> > >>> In the series non-volatile variables are persisted in a file on the > >> EFI > >>> system partition. > >>> > >>> With the patch series SetVariable() is enabled at runtime. We would > >> need > >>> a systemd service for updating the variables in the file store before > >> a > >>> reboot but that would not be really conforming to the UEFI spec which > >>> mandates immediate update of the store. > >> > >> At that point may as well just write the file from userspace as a > >> "variable-update-on-disk" mechanism. Simpler than SetVariable() to > >> implement and more robust. > > > > In my daily routine GRUB is the only program that tries to update UEFI > variables when the GRUB configuration is updated. The other program that > might be nice to work with is efibootmgr. > > > > If you want to work with such standard software, you have to provide > SetVariables(). Whether the data is written before returning success as > required by the UEFI spec or by a later process is of less importance in > these scenarios. Anyway I have not found any solution that will not either > need a runtime driver for an exclusive storage medium in the firmware or a > helper program in the OS for persisting variables. > > > > > > > >> > >>> For the other variable services the patch series provides a compliant > >>> solution. > >>> > >>> Ilias Apalodimas has a draft patch series for using OP-TEE and MM for > >>> managing variables. But storage in the RPMB partition of an eMMC > >> device > >>> would only work at boottime. Just what you described at last years > >>> Embedded Linux conference > >> (https://www.youtube.com/watch?v=VnsF3uRZzNk). > >> > >> There are paths for making it work. Could use the OP-Tee supplicant to > >> get Linux to do the RPMB writes. Alternately, could store the variable > >> updates in SRAM and require a warm reboot of the normal world to > >> persist > >> changes. > > > > What will happen if an EFI application not offering an OP-TEE supplicant > calls SetVariable() relying on OP-TEE after ExitBootServices? > > To possible options are: > - If the supplicant isn't running at the time of the call, SetVariable() > returns a failure > - Hold the values as pending until the supplication starts. > > Whichever direction we go, we should get it encoded into either EBBR or > UEFI. > > > The problem with warmstart memory is that memory discovery or timing > training using writes, or simply a firmware erasing all memory may result > in failure. > > Warmstart memory does 100% require the platform reliably being able to > preserve warmstart memory. I don't see that as any different from any of > the other things we require the platform to do correctly. We've got > influence over TF-A on up for a lot of these platforms. Warmboot > requirements can be speced out, and platforms that are not capable must > then not use a warmboot approach. > > Isn't this mean indirectly that we need a form of requirements equivalent to SBBR/SBSA ? -> EBBR/EBSA? Are there any hardware that can be used as "mailboxes" between the past and next environments of a warm boot? Would it be a TPM corner use case? A secure storage warmboot exchange area? > > > > Best regards > > > > Heinrich > > > >> > >>> Takahiro Akashi last year presented alternative patches that would > >>> enable reading variables at runtime. He recently suggested to use > >>> capsule updates to update variables and has submitted patches for > >>> capsule updates > >>> (https://patchwork.ozlabs.org/project/uboot/list/?series=172907). > >>> > >>> If we do not have SetVariable() at runtime, I do not see much value > >> in > >>> QueryVariableInfo(). So we shouldn't make that service compulsory. > >> > >> Agreed > >> > >> Okay, I'm leaning toward making GetVariable()/GetNextVariableName() at > >> some point in the future, but leaving SetVariable()/QueryVariableInfo() > >> > >> optional. However, I won't do anything in this direction for the point > >> release later this month. I'll just clean up the text to be a bit > >> clearer. > >> > >> g. > >> _______________________________________________ > >> boot-architecture mailing list > >> [email protected] > >> https://lists.linaro.org/mailman/listinfo/boot-architecture > > > _______________________________________________ > boot-architecture mailing list > [email protected] > https://lists.linaro.org/mailman/listinfo/boot-architecture > -- François-Frédéric Ozog | *Director Linaro Edge & Fog Computing Group* T: +33.67221.6485 [email protected] | Skype: ffozog _______________________________________________ boot-architecture mailing list [email protected] https://lists.linaro.org/mailman/listinfo/boot-architecture
