14 Jan 2011 mjg59   » (Master)

EFI implementation bugs

I'm working on improving various bits of Apple hardware support, which includes trying to make EFI booting on Macs more sensible. One of my test machines is an 11" Macbook Air, which is a beautiful piece of hardware. If you want something small and light that's approximately a proper computer rather than a netbook, there's nothing else in the x86 market to touch it. Nothing.

So it's a shame that while Apple employs hardware designers who are absolutely the best in their field, their firmware developers are utterly incompetent. The EFI spec describes a protocol called GOP (Graphics Output Protocol) which allows the operating system to find out things like the screen resolution, framebuffer location and stride. This machine kindly passes everything back correctly, except for stride being wrong. Like, utterly wrong. Implausibly wrong. Obviously, terrifyingly wrong. So wrong that if you trust it, your screen image looks like it's been involved in some sort of awful pasta making accident. But never mind, that's a single line workaround.

But there's far, far worse. EFI has three modes of operation - boot services, runtime services, and runtime services with a virtual memory map. Boot services are, as the name implies, intended to be used by the bootloader. They're contained within memory marked with a type of either BOOT_SERVICES_CODE or BOOT_SERVICES_DATA. Once the bootloader has loaded the OS, just before handing over to it, it calls ExitBootServices() and the firmware is then at liberty to clear those areas of memory. The OS never executes boot services code and can use the memory that was allocated to them.

So then we have runtime services. EFI is, depending on how you want to look at it, either saner or much less sane than traditional BIOS access. The firmware gives you a bunch of function pointers and you then simply call them with native calling convention (this, incidentally, is why it's pretty much impossible to run a 32-bit OS on 64-bit EFI, or a 64-bit OS on a 64-bit system that happens to have 32-bit EFI). To begin with the firmware assumes flat physical mapping, which isn't entirely ideal when you're an OS with virtual address space - so there's a SetVirtualAddressMap() call which lets the OS pass a memory map to the firmware, and from then on everything just works.

Except on this machine. On this machine, you call SetVirtualAddressMap() and the kernel faults because it's just tried to execute code from a region of address space that's marked as non-executable. Closer examination revealed that, yes, this area of address space is marked as RAM and so the kernel's doing the right thing. Except, obviously, the right thing generally doesn't involve crashing the machine at boot time, so there was something else up.

That something else turned out to be SetVirtualAddressMap() calling into boot services code. The boot services code that's not supposed to be touched after ExitBootServices() has been called. The boot services code that's flagged as BOOT_SERVICES_CODE and was therefore mapped as RAM by us because, well, nothing's there any more. The boot services code that we're ignoring exactly as the spec says we should.

So, a quick change to the bootloader to pass us an e820 map[1] that marks the boot services regions as reserved, a quick change to the kernel to mark BOOT_SERVICES_CODE regions as executable and we're in business. Except that when we call SetVariable() to configure the bootloader, the firmware tries to read from an address that's approximately 54TB above anything else.

BlApple.

[1] Oh, yes, despite E820 being an x86 BIOS-specific thing, we use it for the in-kernel representation of the address map under EFI as well. So despite the EFI memory map being available to the kernel, the bootloader has to construct something that looks like an E820 map, losing information in the process. So even though it's been given the E820 map, the kernel has to look through the EFI memory map in order to find the EFI runtime services section in order to mark it executable. This is, arguably, insane, but so is the entirety of EFI so that's ok then.

Syndicated 2011-01-13 23:57:43 from Matthew Garrett

Latest blog entries     Older blog entries

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!