1 2 next »

1. Further problems with UEFI
2. In brief

Kernel Log: Further problems with UEFI

by Thorsten Leemhuis

Some UEFI systems that are shipped with Windows always use a secondary installation of the bootloader which is intended as a fallback; this prevents a correctly installed UEFI Linux from starting up. Also: Google has released its BadRAM patches after all, a Linus Torvalds has appeared on Google+, and Lennart Poettering has posted further material on systemd on his blog.

Matthew Garrett continues to work his way through the jungle that surrounds the (U)EFI/(Unified) Extensible Firmware Interface, which replaces BIOS functionality and has been a common Kernel Log topic over the past few weeks (for example 1, 2). For instance, he has developed patches that combine the kernel's x86 and IA64 EFI implementations to remove duplicate code and create an architecture-independent solution that is suitable for ARM and MIPS platforms.

On his blog, the kernel developer describes one more (U)EFI problem. He first praises the fact that EFI offers mechanisms which prevent the bootloaders for different operating systems from getting in each others' way: the bootloader for each operating system must be stored in a separate, vendor-specific area of the EFI system partition (for example EFI/microsoft), and must then be registered in the "EFI boot variables" in NVRAM. This allows the hardware's UEFI boot code to display a menu during boot so that users can choose from the installed operating systems.

However, since version 2.3, the UEFI specification allows the UEFI boot code to look for a bootloader in a certain place on the EFI system partition (such as EFI/boot/bootx64.efi on x86-64 systems) if no systems have been specified in the EFI boot variables, in the same way as it does to boot from removable media. If no bootloader exists in this location, the current versions of Windows install their bootloader there as a fallback. This is designed to allow Windows to start even if the EFI boot data in NVRAM has been lost.

However, Garrett has already mentioned repeatedly when blogging about other problems that many hardware vendors only test their systems with Windows. The developer said that it's utterly unsurprising to discover that some systems appear to ignore the EFI boot variables and just look for the fallback bootloader when booting the operating system. On systems that come with Windows installed, the fallback is likely to be the Windows bootloader; consequently, a correctly installed version of Linux can then simply not be started using the UEFI mechanisms.

The only solution Garrett says he can can up with would be to implement a "stub bootloader" that is installed together with Linux. It could scan the vendor-specific directories on the EFI system partition for any other bootloaders, and present them as a menu when the system starts up.

Kernel version status

A week ago, Greg Kroah-Hartman released long-term kernel versions 2.6.32.43 and 2.6.33.16, as well as stable kernel version 2.6.39.3. Two of the versions come with the usual "All users of the [...] kernel series must upgrade" message, advising users to switch to the new version without indicating whether the new versions fix any security holes.

Next: In brief

1 2 next »