On 6/15/23 15:00, Jeremy Linton wrote: > Hi, > > On 5/22/23 06:01, Neal Gompa wrote: >> On Mon, May 22, 2023 at 6:57 AM Gerd Hoffmann <kraxel@xxxxxxxxxx> wrote: >>> >>> Hi, >>> >>>> But could we use U-Boot to fill in this gap so these systems still >>>> work? We'd then treat x86 like ARM (if no UEFI, use U-Boot UEFI). >>> >>> How does u-boot handle EFI variables in that case? >>> >> >> Unless the variable store is disabled, I believe it's written to a >> file? That seems to be how it works on ARM. > > Usually with u-boot the runtime service is simply unavailable, which > tends to break all kinds of things in subtle ways. > > More recently though there have been patches merged to support runtime > services in the uboot/uefi shim by trapping to lower level firmware > which has always had runtime components available (unlike uboot), ex > PSCI. So, if you have runtime variable storage with uboot its most > likely being handled by Trusted Firmware A > (https://www.trustedfirmware.org/). > > That said TFA has all the same problems as EDK2 on some of these > platforms WRT variable storage because its not generally possible to > share something like an emmc/etc device between the Linux kernel and the > firmware. Meaning the firmware needs to have a dedicated device, used to > store the variables. Usually some SPI flash, but not always. I don't > think anyone has managed to get a workable runtime service that writes > the variable store to a file on a shared FS outside of maybe some tech > demos. The problem is that the low level firmware need to understand and > be able to read/write something like the ESP + USB/SD/MMC and then > release it while keeping a volatile copy around long enough for a OS > specific service to then take over persistence of the data. Its brittle > and OS dependent as every single OS in existence then needs to have the > service ported and active. The closest solutions I'm aware of are things > like the older rpi3 EDK2 ports which wrote the variable store back to > the firmware image itself on the ESP. But this doesn't really provide > non-volatile runtime storage either because power loss/whatever causes > updates done while the OS is running to be lost. It also technically > violates the relevant specs as well since it fails to be "tamperproof" . My understanding is that _reading_ variables can be made to work, but SetVariable() will invariably return EFI_UNSUPPORTED. On some WoA systems the solution is a special driver that communicates with the trusted execution environment (TEE). This meets the “tamperproof” requirement (quotes because unless it is in a proper secure element it isn’t really tamperproof), but it means that the OS must use nonstandard methods to access these variables. For WoA this is not a problem because the vendor can just provide a driver for Windows to use, but for Linux it means that the kernel will need a whole bunch of drivers. -- Sincerely, Demi Marie Obenour (she/her/hers) _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
