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? 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. 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
