Hi,
On 8/10/23 13:34, Ard Biesheuvel wrote:
> On Thu, 10 Aug 2023 at 12:32, Hans de Goede <hdegoede@xxxxxxxxxx> wrote:
>>
>> Hi Ard,
>>
>> On 8/10/23 11:28, Ard Biesheuvel wrote:
>>> As currently implemented, mixed mode support on x86 depends on special
>>> Linux/x86 specific logic in the bootloader that is not covered by the
>>> UEFI specification: it relies on the so-called EFI handover protocol to
>>> invoke a special 32-bit entrypoint into the EFI stub that 64-bit Linux
>>> builds expose if they were configured with CONFIG_EFI_MIXED=y (and
>>> CONFIG_EFI_HANDOVER_PROTOCOL=y)
>>>
>>> When EFI mixed mode was introduced, booting via the EFI stub was a
>>> prerequisite, as the stub code captured the context that was restored
>>> again when invoking firmware services, both at boot time and at runtime.
>>> (segment selectors, GDTs, IDTs etc). However, since commit 96738c69a7fc
>>> ("x86/efi: Avoid triple faults during EFI mixed mode calls"), the
>>> runtime logic no longer uses any of this preserved context, and simply
>>> invokes the firmware services in compatibility mode instead.
>>>
>>> Given that the EFI handover protocol was never implemented except in
>>> distro forks of GRUB, mainline GRUB does not support it. However, its
>>> legacy x86 boot code will happily boot a 64-bit kernel from a 32-bit
>>> build, and given that booting via the EFI stub is no longer needed, it
>>> can also invoke the 32-bit EFI runtime services without problems. And
>>> even Debian's GRUB fork, which implements the EFI handover protocol for
>>> native boot, will happily boot in mixed mode with all the EFI stub
>>> pieces ripped out.
>>>
>>> This means that the complex and messy EFI mixed mode support in the EFI
>>> stub is redundant, and can be removed.
>>
>> How do you see this working, esp. wrt upgrade paths for distros which currently have a patched grub which will execute the EFI stub when EFI booting, both for 32 bits and for 64 bit grub builds ?
>>
>> If I understand this correctly the 32 bit grub UEFI binaries will need to boot through the x86 boot protocol now instead of using the EFI stub. Will the current (distro patched) UEFI grub binaries be able to detect stub support is missing and then automatically fall back to the x86 boot protocol? I doubt that the current EFI handover / stub support patches in grub actually do this.
>>
>
> As mentioned in the commit log, Debian's GRUB already does this.
Right in my memories Debian's GRUB actually never uses the stub at all, not even in 64 bit mode. At least IIRC one of the times I had issues with UEFI booting using the x86 boot proto on a 64 bit UEFI machine was actually with Debian and swapping Debian's grub for Fedora's grub fixed things.
Maybe they have separate linux and efilinux commands for grub, one to boot using the x86 boot proto and one to use the efistub ?
> However, as far as I can tell, its mixed mode support never enters via
> the stub, so I imagine Fedora's GRUB behaves differently in this
> regard.
I believe that Fedora's grub does use the stub when booting on both 32 bit and 64 bit UEFI. Is there an easy way to verify this ? I guess one cannot just add a printk to the stub ...
>> AFAICT this would mean that if this lands in lets say 6.7 and that lets say Fedora 39 then moves to 6.7 once approx. 6.7.4 is out all Fedora 40 x86_64 installs done on low-end machines using 32 bit UEFI will then stop booting ?
>>
>
> Of course, this is not the intent.
>
>> And this will also completely break booting 64 bit kernels on 32 bit UEFI using systemd-boot.
>> systemd-boot exclusively relies on the UEFI stub, since the whole concept of system-boot is to do as little as possible and rely on UEFI for pretty much everything. As such I also consider it quite unlikely that systemd-boot will ever get support for the x86 boot protocol.
>>
>
> I don't think it will. I didn't realize systemd-boot actually went
> ahead with this, although I did get pulled into some discussions about
> this a while ago.
systemd did went ahead with this, support for this was merged here:
https://github.com/systemd/systemd/pull/22550
> So, to be clear, mixed mode boot using systemd-boot is a supported
> configuration on Fedora?
We offer systemd-boot as an alternative bootloader and some people are using it. Also there are discussions in Fedora to outright switch to systemd-boot for UEFI installs because of its much simpler and smaller code base.
>> Another thing to consider is that booting through the stub tends to be more reliable then using grub. There is a reason why Fedora has been patched grub to use the stub even long before 32/64 bit mixed mode support was implemented. I've more then once seen 64 bit UEFI systems where upstream grub would fail to boot the system, where as a grub patched to handover booting to the EFI stub would boot. And since the often low qualitty of 32 bit UEFI BIOS-es I'm worried that some of them likewise will fail to boot when using the x86 boot protocol.
>>
>
> I'd argue that the less we involve the boot services on such systems,
> the better it is.
>
>> I'm sorry, but to me breaking grub distro upgrade paths and completely loosing support for systemd-boot seems like an unacceptable regression.
>>
>> I can understand the desire to remove this hairy code, but the diffstat shows this only removes about 800 lines. Now if we were talking 10 kloc or some such we could maybe look into some sort of migration path.
>>
>> IMHO the balance between amount of cleanups versus the severity of the regressions / lost functionality tips the scale to the regressions being worse then the positve effect of the code cleanup. So based on my current understanding of this I'm against the proposed change.
>>
>
> Fair enough, thanks for the input.
>
> I think we all agree that we should not regress or block the upgrade
> path for existing installations that rely on this.
Thanks, that is good to hear.
> The question is
> really for how much longer this needs to be supported, as I imagine
> the set of machines relying on this (and keeping up with the latest
> distro) is shrinking quickly.
Some of these systems are point-of-sale systems running enterprise Linux distros because their vendors/users expect to be able to use them for a long long time.
These use some Bay Trail CPU models for which Intel also offers an extended support lifetime.
So I'm fraid that these will likely be with us for a long time, sorry.
Regards,
Hans
