More in the series of bizarre UEFI bugs
Nov. 14th, 2012 11:49 pm![[personal profile]](http://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…
Plan of action
Date: 2012-11-15 07:06 am (UTC)no subject
Date: 2012-11-15 07:14 am (UTC)Re: Plan of action
Date: 2012-11-15 07:29 am (UTC)That takes hardware and patience though, no use to cheat.
--
Michael Shigorin
Re: Plan of action
Date: 2012-11-15 10:31 am (UTC)Legacy boot not a solution
Date: 2012-11-15 10:56 am (UTC)OMG
Date: 2012-11-15 11:28 am (UTC)Don't wait for Lenovo to fix this
Date: 2012-11-15 01:14 pm (UTC)This problem has been discussed for at least the last year and several BIOS revisions haven't helped.
Here we go
Date: 2012-11-15 01:19 pm (UTC)the name >>Windows 8<< here and there in firmware, I wanted to ....".
Re: OMG
Date: 2012-11-15 03:13 pm (UTC)Re: Plan of action
Date: 2012-11-15 04:53 pm (UTC)Re: Plan of action
Date: 2012-11-15 05:24 pm (UTC)work with anything else than one operating system and the manufacturer
did not clearly state that; or a BIOS upgrade cripples all installed
OSes except for one. Legal counsel would be helpful, even if it just
consists of publicly given instructions. The BIOS upgrade case
potentially can be intentional damage to already purchased hardware,
or whatever the lawyers call that.
At least these were the thoughts that passed through my head when I was
choosing to buy some piece of dont-know-what with Win 8 logo,
and it also pushed me many years back to times when I was checking
if the hardware has linux drivers at all.
Breach of MS guidelines?
Date: 2012-11-15 06:03 pm (UTC)I'm staggered that such behaviours is not a breach of the UEFI standard.
Re: Breach of MS guidelines?
Date: 2012-11-15 06:07 pm (UTC)Re: Plan of action
Date: 2012-11-15 06:08 pm (UTC)But above all and with all the UEFI secure boot sh*t - phone the company, email them make their tech support costs go up. Their margins are so low that if even a few of the people who can't get old Windows, Linux etc running on the box keeps phoning and complaining they'll make a loss on the product line.
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.
Error
Date: 2012-11-15 08:17 pm (UTC)Thx!
driving up revenue
Date: 2012-11-15 09:43 pm (UTC)database of badly behaving systems
Date: 2012-11-15 10:38 pm (UTC)Simple solution
Date: 2012-11-15 11:06 pm (UTC)Not sure why they added that boneheaded check though, is there perhaps a support contract that only supports Windows and RHEL?
Re: Simple solution
Date: 2012-11-16 01:04 am (UTC)Re: OMG
Date: 2012-11-16 02:01 am (UTC)Lenovo's not the only one
Date: 2012-11-16 02:57 am (UTC)no subject
Date: 2012-11-16 07:08 am (UTC)Languages
Date: 2012-11-16 07:57 am (UTC)Confused
Date: 2012-11-16 08:07 am (UTC)this stinks!