Hey all,
I was chatting with Marcin Juszkiewicz about U-Boot on ARM wrt its "generic UEFI boot" feature where it can execute UEFI applications. We use this capability for Fedora on ARM platforms to go from the utterly barebones and weird initialization processes for various boards to a UEFI-like environment so we can boot Fedora somewhat normally.
It occurred to me during that conversation that it might be possible to use this to simplify what we need to care about for x86 too. Last year, the Red Hat Bootloader team wanted to start a deprecation process for BIOS[1] and the Fedora Cloud WG has been interested in it for longer[2].
At least from the Cloud WG side, it's been determined that completely removing BIOS support is functionally impossible for the next few years because of AWS and smaller cloud providers not universally supporting UEFI (and we are still trying to convince them to change their minds on this...). And I still have plenty of hardware with broken UEFI implementations that require CSM boot to support Linux.
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).
[1]: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/... [2]: https://pagure.io/cloud-sig/issue/345
Am 21.05.2023 um 15:36 schrieb Neal Gompa ngompa13@gmail.com:
Hey all,
I was chatting with Marcin Juszkiewicz about U-Boot on ARM wrt its "generic UEFI boot" feature where it can execute UEFI applications. We use this capability for Fedora on ARM platforms to go from the utterly barebones and weird initialization processes for various boards to a UEFI-like environment so we can boot Fedora somewhat normally.
It occurred to me during that conversation that it might be possible to use this to simplify what we need to care about for x86 too. Last year, the Red Hat Bootloader team wanted to start a deprecation process for BIOS[1] and the Fedora Cloud WG has been interested in it for longer[2].
At least from the Cloud WG side, it's been determined that completely removing BIOS support is functionally impossible for the next few years because of AWS and smaller cloud providers not universally supporting UEFI (and we are still trying to convince them to change their minds on this...). And I still have plenty of hardware with broken UEFI implementations that require CSM boot to support Linux.
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).
Would be interesting to have a proof of concept, e.g. a server VM image.
However, when I look at the ARM SBC UEFI, some improvement would be desirable. At the moment, there is only a crumpled UEFI image flying across the screen, without any intervention option (which is OK for SBC, but probably not for a „real“ server).
-- Peter Boy https://fedoraproject.org/wiki/User:Pboy PBoy@fedoraproject.org mailto:PBoy@fedoraproject.org
Timezone: CET (UTC+1) / CEST /UTC+2)
Fedora Server Edition Working Group member Fedora Docs team contributor and board member Java developer and enthusiast
On Sun, May 21, 2023 at 9:58 AM Peter Boy pboy@uni-bremen.de wrote:
Am 21.05.2023 um 15:36 schrieb Neal Gompa ngompa13@gmail.com:
Hey all,
I was chatting with Marcin Juszkiewicz about U-Boot on ARM wrt its "generic UEFI boot" feature where it can execute UEFI applications. We use this capability for Fedora on ARM platforms to go from the utterly barebones and weird initialization processes for various boards to a UEFI-like environment so we can boot Fedora somewhat normally.
It occurred to me during that conversation that it might be possible to use this to simplify what we need to care about for x86 too. Last year, the Red Hat Bootloader team wanted to start a deprecation process for BIOS[1] and the Fedora Cloud WG has been interested in it for longer[2].
At least from the Cloud WG side, it's been determined that completely removing BIOS support is functionally impossible for the next few years because of AWS and smaller cloud providers not universally supporting UEFI (and we are still trying to convince them to change their minds on this...). And I still have plenty of hardware with broken UEFI implementations that require CSM boot to support Linux.
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).
Would be interesting to have a proof of concept, e.g. a server VM image.
However, when I look at the ARM SBC UEFI, some improvement would be desirable. At the moment, there is only a crumpled UEFI image flying across the screen, without any intervention option (which is OK for SBC, but probably not for a „real“ server).
U-Boot does have a UEFI shell, though for our purposes, it's not that important. U-Boot would merely allow us to jump into an environment that executes the boot manager EFI binary (grub2, rEFInd, sd-boot).
If it's possible, it's something Fedora Cloud would probably adopt pretty quickly.
Am 21.05.2023 um 16:06 schrieb Neal Gompa ngompa13@gmail.com:
On Sun, May 21, 2023 at 9:58 AM Peter Boy pboy@uni-bremen.de wrote:
Am 21.05.2023 um 15:36 schrieb Neal Gompa ngompa13@gmail.com:
Hey all,
I was chatting with Marcin Juszkiewicz about U-Boot on ARM wrt its "generic UEFI boot" feature where it can execute UEFI applications. We use this capability for Fedora on ARM platforms to go from the utterly barebones and weird initialization processes for various boards to a UEFI-like environment so we can boot Fedora somewhat normally.
It occurred to me during that conversation that it might be possible to use this to simplify what we need to care about for x86 too. Last year, the Red Hat Bootloader team wanted to start a deprecation process for BIOS[1] and the Fedora Cloud WG has been interested in it for longer[2].
At least from the Cloud WG side, it's been determined that completely removing BIOS support is functionally impossible for the next few years because of AWS and smaller cloud providers not universally supporting UEFI (and we are still trying to convince them to change their minds on this...). And I still have plenty of hardware with broken UEFI implementations that require CSM boot to support Linux.
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).
Would be interesting to have a proof of concept, e.g. a server VM image.
However, when I look at the ARM SBC UEFI, some improvement would be desirable. At the moment, there is only a crumpled UEFI image flying across the screen, without any intervention option (which is OK for SBC, but probably not for a „real“ server).
U-Boot does have a UEFI shell, though for our purposes, it's not that important. U-Boot would merely allow us to jump into an environment that executes the boot manager EFI binary (grub2, rEFInd, sd-boot).
If it's possible, it's something Fedora Cloud would probably adopt pretty quickly.
I'm curios. I would like to grab it and try to create an experimental Server VM.
-- Peter Boy https://fedoraproject.org/wiki/User:Pboy PBoy@fedoraproject.org
Timezone: CET (UTC+1) / CEST /UTC+2)
Fedora Server Edition Working Group member Fedora Docs team contributor and board member Java developer and enthusiast
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?
How does u-boot do storage access in that case? Go call BIOS INT13h? Or use its own device drivers?
Last time I checked there have been a few gaps, no virtio-scsi driver for example.
take care, Gerd
On Mon, May 22, 2023 at 6:57 AM Gerd Hoffmann kraxel@redhat.com 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.
How does u-boot do storage access in that case? Go call BIOS INT13h? Or use its own device drivers?
Last time I checked there have been a few gaps, no virtio-scsi driver for example.
I don't know. I imagine with U-Boot using a similar build process to the kernel that it does have its own equivalent of drivers for platform configuration.
Hi,
On 5/22/23 06:01, Neal Gompa wrote:
On Mon, May 22, 2023 at 6:57 AM Gerd Hoffmann kraxel@redhat.com 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" .
So "hardware bug", but once you fix all those bugs, it becomes straightforward just to toss TFA + EDK2 on it and run a full blown UEFI implementation providing all the infrastructure to make things like secure/measured boot, firmware updates, persistent variables, TRNGs, RTCs, etc all "just work". And then once all that works, it becomes possible to consider ACPI in the same bucket and avoid a bunch of kernel drivers for clock, power, battery, thermal, etc management.
How does u-boot do storage access in that case? Go call BIOS INT13h? Or use its own device drivers?
Last time I checked there have been a few gaps, no virtio-scsi driver for example.
I don't know. I imagine with U-Boot using a similar build process to the kernel that it does have its own equivalent of drivers for platform configuration.
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@redhat.com 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.
I think this is a worthwhile effort if someone has the time to fill in the blanks, come up with a PoC, and test it with various versions of BIOS, it would accelerate deprecation of BIOS. BIOS holds us back when making decisions around boot stack, bootloader, firmware upgrade tools, etc.
You may have to port u-boot to different versions of BIOS though.
For example this chainloading technique was considered as a solution to make Chromebooks + Coreboot chainload a UEFI loader to install vanilla Fedora images, but the disadvantage is you'd have to port u-boot to every Chromeboot:
https://github.com/eballetbo/chromebooks
On the other hand chainloading a UEFI loader works great for Asahi even without the efi vars so...