More in the series of bizarre UEFI bugs
Nov. 14th, 2012 11:49 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
mjg59A (well, now former) coworker let me know about a problem he was having with a Lenovo Thinkcentre M92p. It booted Fedora UEFI install media fine, but after an apparently successful installation refused to boot. UEFI installs on Windows worked perfectly. Secure Boot was quickly ruled out, but this could still have been a number of things. The most interesting observation was that the Fedora boot option didn't appear in the firmware boot menu at all, but Windows did. We spent a little while comparing the variable contents, gradually ruling out potential issues - Linux was writing an entry that had an extra 6 bytes in a structure, for instance[1], and a sufficiently paranoid firmware implementation may have been tripping up on that. Fixing that didn't help, though. Finally we tried just taking the Windows entry and changing the descriptive string. And it broke.
Every UEFI boot entry has a descriptive string. This is used by the firmware when it's presenting a menu to users - instead of "Hard drive 0" and "USB drive 3", the firmware can list "Windows Boot Manager" and "Fedora Linux". There's no reason at all for the firmware to be parsing these strings. But the evidence seemed pretty strong - given two identical boot entries, one saying "Windows Boot Manager" and one not, only the first would work. At this point I downloaded a copy of the firmware and started poking at it. Turns out that yes, actually, there is a function that compares the descriptive string against "Windows Boot Manager" and appears to return an error if it doesn't match. What's stranger is that it also checks for "Red Hat Enterprise Linux" and lets that one work as well.
This is, obviously, bizarre. A vendor appears to have actually written additional code to check whether an OS claims to be Windows before it'll let it boot. Someone then presumably tested booting RHEL on it and discovered that it didn't work. Rather than take out that check, they then addded another check to let RHEL boot as well. We haven't yet verified whether this is an absolute string match or whether a prefix of "Red Hat Enterprise Linux" is sufficient, and further examination of the code may reveal further workarounds. For now, if you want to run Fedora[2] on these systems you're probably best off changing the firmware to perform a legacy boot.
[1] src/include/efi.h: uint8_t padding[6]; /* Emperically needed */, says the efibootmgr source code. Unhelpful.
[2] Or Ubuntu, or Suse, or…
Every UEFI boot entry has a descriptive string. This is used by the firmware when it's presenting a menu to users - instead of "Hard drive 0" and "USB drive 3", the firmware can list "Windows Boot Manager" and "Fedora Linux". There's no reason at all for the firmware to be parsing these strings. But the evidence seemed pretty strong - given two identical boot entries, one saying "Windows Boot Manager" and one not, only the first would work. At this point I downloaded a copy of the firmware and started poking at it. Turns out that yes, actually, there is a function that compares the descriptive string against "Windows Boot Manager" and appears to return an error if it doesn't match. What's stranger is that it also checks for "Red Hat Enterprise Linux" and lets that one work as well.
This is, obviously, bizarre. A vendor appears to have actually written additional code to check whether an OS claims to be Windows before it'll let it boot. Someone then presumably tested booting RHEL on it and discovered that it didn't work. Rather than take out that check, they then addded another check to let RHEL boot as well. We haven't yet verified whether this is an absolute string match or whether a prefix of "Red Hat Enterprise Linux" is sufficient, and further examination of the code may reveal further workarounds. For now, if you want to run Fedora[2] on these systems you're probably best off changing the firmware to perform a legacy boot.
[1] src/include/efi.h: uint8_t padding[6]; /* Emperically needed */, says the efibootmgr source code. Unhelpful.
[2] Or Ubuntu, or Suse, or…
Re: Breach of MS guidelines?
Date: 2012-11-15 06:24 pm (UTC)I was thinking that because this prevent the user booting the OS of their choice (even after adding keys and what have you) then it would still be a breach. Guess that would require MS to take action, and I wouldn't expect that to happen any time soon.
I'm just dumbfounded that anyone would do that kind of string check in a place like this. Maybe to check for 0 chars. Maybe even to do a little alphanumeric sort. But "if (string!=magicLetterSequence) then { error }" Really?
Someone really needs a slap.
Really worrying if this kind of crap shows up in other firmware.
Re: Breach of MS guidelines?
Date: 2012-11-16 11:07 am (UTC)Still better than some regular BIOS doing:
"if (opcode_at_mbr+0x0C != microsoft_mbr_opcode) then { not_bootable }"
Comparing strings is bad, comparing hexadecimal values of opcodes is really bad...
Re: Breach of MS guidelines?
Date: 2012-11-16 03:46 pm (UTC)- Microsoft gets to say: we are not an ugly monopoly we explicitly say that the "industry standard" we impose is open
- They also get to say: we are not the bad guy who forces a poor HW maker to be too close to the "industry standard"
And
- They get to ruin your day forcing you either to demonstrate that you are the kind of client rich and powerful enough to force an high priced "enterprise" linux on your machine, or use what they want, or "get lost" (but it's not their fault)...
Re: Breach of MS guidelines?
Date: 2012-11-26 10:23 pm (UTC)The game is:
- we will sign any shim, as long as we like it
- we don't like GPL, so it must not be GPL
- ah, you need to sign the legal paper that we created if you want to us to sign shim. You are free to use the service, why, you have something to hide?
- it must not be anywhere near GPL, we don't like it too and we leave it vague (to our discretion)
- the rules are legal once you sign them
- hardware suppliers do what they want, we don't force them in any way to boot only one OS
and, the best part of it is:
- hackers will sign anything and get away with it
The game is called 'additional security', don't forget.
I think I have asked before 'will Microsoft sign?' and the answer depends on the details. I will probably sign somewhere around 2016 (four years for all the legal proceedings should be enough to make something new up).