Slashdot Mirror
Lenovo UEFI Bug Only Likes Windows and RHEL
New submitter Nagilum23 writes "It looks like Lenovo only knows of Windows and RHEL where their Thinkcentre M92p desktop is concerned. While investigating UEFI boot issues, Matthew Garrett found the PC's firmware actually checks the descriptive string for the operating system, and will prevent unlisted operating systems from booting. Garrett writes, '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. ... 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."
Note that this isn't a SecureBoot issue. Lenovo is aware of the problem and looking into it.
You keep using that word. I don't think it means what you think it means.
It's not a bug if it's by design, and this is clearly intended behavior.
I don't see how you can consider this a "bug"? You don't just "accidentally test a string for a specific value". This is clearly intentional operation, not a bug.
I work for the Department of Redundancy Department.
Given that RHEL is probably their biggest competator that move could be considered a counter to - I would say you need to put down your anti-ms tinfoil hat, your brain is overheating.
It's probably a support engineer related decision - "We don't want to have to deal with questions/complaints regarding unsupported operating systems that have gotten installed... so we'll prevent them from being installed."
Neither malice or ms-induced maice, but rather just an idiotic solution to an annoying issue that they probably have to periodically deal with.
Glad I don't buy Lenovo. I tend to prefer FreeBSD and Hackintosh'ed as my non MS OS.
Self proclaimed typo king, and inventor of the bear destroying coffee table (patent not pending).
It's nothing to do with Secure Boot, just dodgy BIOS-writing again.
From TFS: "There's no reason at all for the firmware to be parsing these strings."
This is basically on a par with Windows 3.1 looking for MS-DOS signatures and refusing to boot otherwise (though that had an illegally anticompetitive reason), with BIOS's like the one I just forced an update from my supplier for (by threatening to return a significant number of laptops) which consisted of a BIOS checking for a certain value on disk being 00 before it would boot from that disk (a value which corresponds to 00 only on unencrypted Windows NTFS-formatted disks) and refusing to boot Truecrypt'd disks or anything with a non-NTFS primary partition (very common on certain HP and Dell models, that particular "bug"), and the like of which I've seen DOZENS of times in my own purchases because of:
STUPID BIOS WRITERS.
There is no reason to ever test that string, and certainly none to use it as a conditional to boot. It has nothing to do with any advertised UEFI feature whatsoever. The fact that the UEFI code even bothers to interrogate that string for anything other than displaying it to the user tells you that the manufacturer doesn't care about, and doesn't test, anything but Windows to the point they will hard-core their machines to only run Windows. They don't care about UEFI at all, or secure booting, or anything - just that it works when they run Windows.
Makes you kinda wonder who would ultimately be behind putting such an unnecessary and counter-productive decision into a machine's BIOS really.
UEFI is pretty much a case of fixing what isn't broken, yet with any software project its bound to have bugs in the first few iterations.
And, oh boy does it. name brand motherboards that brick when flashed, systems that don't power off correctly, systems that take minutes to post, the usual issues with incorrect ACPI table entries, the list goes on.
Basically, its replacing one fairly stable code base, that the motherboard vendors often got wrong, with a completely new untested one that is 10x as complicated. You do the math.
Linus had another rant about it recently called "The abomination called EFI".
BTW: Gigabyte has a number of traditional motherboards that can boot GPT partitions, effectively removing the _ONE_ useful new feature in EFI.
Because I'm lazy, I'll just copy and paste a comment I made in another thread about TPM
Ever since TPM was created, we're always just a few bits and bytes away from having it leveraged against us, by them.
And by "us" I mean "the computer users."
By "them" I mean "the hardware manufacturers and software/media companies."
Example: The newest motherboards don't *need* the ability to disable trusted boot. Heck, it'd have been easier to not include it!
We're more or less at the mercy of a small number of companies and their design decisions.
I recently found out, while looking at new laptops, that Lenovo & HP like to put whitelists of wireless cards into the BIOS.
Someone hacked the BIOS and other cards will work, but for whatever reason, Lenovo/HP doesn't want you to use a storebought card.
[Fuck Beta]
o0t!
Most likely: the firmware is outsourced, and the outsources implements it to the letter, without applying any thinking.
A successful API design takes a mixture of software design and pedagogy.
As a user of ThinkPads for nearly as long I have a TP I cannot install a miniPCI wireless upgrade into without hacking my system because it is not an approved part for my specific ThinkPad. Even a miniPCI from another ThinkPad won't always work.
"A person is smart. People are dumb, panicky dangerous animals and you know it." - K
There is a reason for this:
The mini-PCI card is just the radio. The antenna is in the rest of the laptop (usually around the screen). The FCC only certifies them for certain radio+antenna pairings, and so they cannot get certification if they don't put in some mechanism to stop you from using uncertified pairings.
It's stupid yes, but the idea behind the policy is to allow the sale of high-power radios while keeping it within exposure limits. (the reason being is the same power going into an omnidirectional antenna safely can not only exceed but blow-out-of-the-water the exposure limits if put into a directional antenna. think bulb vs laser)
For large sets, this will be our guide even unto death, for the LORD will work for each type of data it is applied to...