The Extensible Firmware Interface - an introduction [LWN.net]

The Extensible Firmware Interface - an introduction

Posted Aug 11, 2011 12:09 UTC (Thu) by etienne (subscriber, #25256)
Parent article: The Extensible Firmware Interface - an introduction

I wonder why it should be better to have a "higher level" boot-loader, i.e. something which should run on a (reduced) operating system, instead of "as near as bare-metal" boot-loader.

Basically I see these problems:
- If the BIOS is really setting a minimum OS, it needs to initialise all the managed devices (wait for SATA and USB enumeration to complete), work that needs to be completely forgotten and restarted by Linux a bit later (unless Linux trusts EFI descriptions - USB3 PCI card on USB2 aware EFI).
- If booting from CDROM/DVD needs to still work, everything this minimum OS has initialised has to be undone, and the memory below 1 Mbyte has to be untouched.
- If booting from removable (USB) device shall still be supported, you still have the problem to tell Linux from which device it has booted (multiple possible root file-system present)
- If EFI analyses partitions, it limits the partition system that can be installed (removable devices)
- If EFI analyses file-systems, it limits the file-systems that can be used (removable devices)
- If EFI displays characters, it limits the fonts, font sizes and number of characters (UTF-8) that can be used.
- If EFI does more than put an ethernet frame on the wire and get an ethernet frame from the wire, and can do TCP, it means a lot of information has to be exchanged in between EFI and Linux (IP address, DHCP data...)
- EFI do not solve the problem that "the Linux kernel has been upgraded since last boot", so shall we boot the older kernel because it is a resume operation, or shall we boot the latest kernel because that is a full boot operation, or are we in recovery mode and should boot an older but known to work kernel?

I am not sure that all those are improvement, compared to having a boot-loader on the first sector of one of the disk, boot-loader that can be upgraded by standard package management.
OK, the "old BIOS" is not perfect and each version has some bugs, and it does not provide a standard way to put an ethernet frame on the wire (ethernet card no more have a FLASH memory for their own BIOS driver), and you can't know which keyboard region is installed, but being lower level it has proven to be quite flexible.

Disclaimer: my pet project is the Gujin boot-loader.

(Log in to post comments)

The Extensible Firmware Interface - an introduction

Posted Aug 22, 2011 14:05 UTC (Mon) by etienne (subscriber, #25256) [Link]

> EFI relies on a dedicated partition; that should not put any limit on the other partitions.

It seems to me like obvious, if you want your Linux on the same disk as the EFI partition, they have to use the same partition system (standard MBR partition or GPT or even others).

Also, because EFI needs its own partition, what happens in the context of multiple disks?
- What if you have two disks with each an EFI partition, none of those disk being the primary disk (BIOS disk 0x80)?
- What if those disks are software RAID-0?
- What if those disks are RAID-1 and contains only half of the files?
- What if each disk contains different Linux distribution and need to boot even if the other disk is not present (hard disk swapping bay)?
- What if you have to use a special partition index to boot your USB thumb drive (BIOS restriction)?
- What if one disk is extremely unreliable (hardware failure or partitions overlapping) and you want to try to recover its content by booting another clean distribution?
- What if there were bugs in BIOS/EFI during the transition to 4 Kbytes per hardware sectors? Is the partition table in 512 bytes or 4096 bytes sector?
- What if you have a 2048 bytes/sector disk (DVD-RAM) with Linux installed but there cannot be partitions (no partition supported by Linux on CD/DVD, just "superfloppy")?

The problem is not simple with "the first sector of the first disk is loaded and executed at boot", but adding EFI seems to me like making it more complex.

I have seen people using quite a few cold-swappable hard disks to boot multiple operating systems, to support real applications on different setup but the same PC. There is large Post-it notes on each disk...

The Extensible Firmware Interface - an introduction

Posted Aug 22, 2011 14:11 UTC (Mon) by marcH (subscriber, #57642) [Link]

> It seems to me like obvious, if you want your Linux on the same disk as the EFI partition, they have to use the same partition system (standard MBR partition or GPT or even others).

And? Please give a sample use case which actually demonstrates a limitation.

Concerning all the other points I got bored reading before I could find any problem new to EFI.

The Extensible Firmware Interface - an introduction

Posted Aug 22, 2011 14:56 UTC (Mon) by etienne (subscriber, #25256) [Link]

> Please give a sample use case which actually demonstrates a limitation.

No partition table that EFI will understand?

The Extensible Firmware Interface - an introduction

Posted Aug 22, 2011 15:40 UTC (Mon) by mjg59 (subscriber, #23239) [Link]

Your EFI bootloader must always be in either an MBR or GPT partition.

The Extensible Firmware Interface - an introduction

Posted Aug 22, 2011 22:37 UTC (Mon) by marcH (subscriber, #57642) [Link]

I think this is exactly the limitation that etienne is trying to demonstrate.

However I still do not really see how this is a limitation *in practice*.

The Extensible Firmware Interface - an introduction

Posted Aug 23, 2011 9:56 UTC (Tue) by etienne (subscriber, #25256) [Link]

> However I still do not really see how this is a limitation *in practice*.

Lets take a real life example: the situation right now is that the first sector of the first disk is loaded, after that the ROM BIOS hopes for the best after jumping to the first instruction of the MBR.
The "first disk" is where the BIOS can be a bit configured, there is most of the time a boot menu where you can select what the "first disk" is, and if the first disk is not readable (disk broken or any other reason), then the next disk is tried.
Something nobody planned 30 years ago happens: disk sector sizes are going to increase from 512 to 4096 bytes per sector.
With current systems you hopefully will still have the first sector loaded (for any sector size one can imagine) and one can hope that at least the first 512 bytes are correctly loaded, and it should be sufficient for the bootloader to manage the situation (I tried to make that possible with Gujin, but cannot test because those disks are still under NDA).
Now, I believe EFI will handle 512 and 4096 bytes/sector at the SATA interface, but in few years there may be something else - and because EFI is IHMO too "intelligent", to boot you will not just need to upgrade a package in your distribution, but you will need to upgrade your BIOS.

The Extensible Firmware Interface - an introduction

Posted Aug 23, 2011 10:50 UTC (Tue) by marcH (subscriber, #57642) [Link]

I miss how this is an answer to the previous question in the thread but anyway:

> ..., but you will need to upgrade your BIOS.

And? I have actually solved real boot problems (USB-ZIP/FDD/HDD, PXE,...) by upgrading BIOSes, this is not a pie in the sky. Note that, from the vendor's perspective it will be much cheaper to develop an upgrade in C (EFI) as opposed to assembly (BIOS).

If your PC is too old for maintenance then you will do what most people do in such cases: you will buy a new PC with an updated EFI/BIOS/whatever. Consider this very similar case: how many people actually try to shoehorn a brand new & big SATA drive into an old & slow pre-SATA PC? Practically none.

Working on a Windows 7 PC right now I often envy Apple, am tired of backward-compatibility and wish it were much more often thrown out of the window...

The Extensible Firmware Interface - an introduction

Posted Aug 23, 2011 13:20 UTC (Tue) by etienne (subscriber, #25256) [Link]

I think we can agree to disagree on that one:
- for me, if it is possible to do in hardware, Linux should try to support it in software (because we do not know what will be the future).
- for you, if the number of people doing strange things is statistically insufficient, there is no point in trying to support it (because anyway we will have new PC including the evolution if it is good enough).

I would agree with you saying the world would be a simpler place if we did not have all those "strange" configurations to support, if the users would use their computer and OS for what it was designed for.