Slashdot Mirror
UEFI Secure Boot Pre-Bootloader Rewritten To Boot All Linux Versions
hypnosec writes "The Linux Foundation's UEFI secure boot pre-bootloader is still in the works, and has been modified substantially so that it allows any Linux version to boot through UEFI secure boot. The reason for modifying the pre-bootloader was that the current version of the loader wouldn't work with Gummiboot, which was designed to boot kernels using BootServices->LoadImage(). Further, the original pre-bootloader had been written using 'PE/Coff link loading to defeat the secure boot checks.' As it stands, anything run by the original pre-bootloader must also be link-loaded to defeat secure boot, and Gummiboot, which is not a link-loader, didn't work in this scenario. This is the reason a re-write of the pre-bootloader was required and now it supports booting of all versions of Linux." Also in UEFI news: Linus Torvalds announced today that the flaw which was bricking some Samsung laptops if booted into Linux has been dealt with.
The redesigned bootloader has already been submitted to Microsoft for singing and once the signed version is received, The Linux Foundation is planning to provide it for free.
Why in hell did the world give Microsoft control over computer bootup hardware?
That's just insane.
"I've got more toys than Teruhisa Kitahara."
... no story here, move along.
I love stacking my barbecues in the shed at the end of summer - you can't beat a bit of grill on grill action.
Who would have thought that just randomly poking memory of a laptop would brick it. Long ago Samsung told me that it was just fine to be doing this, and that there would not be any problems (I based the samsung-laptop driver on code that Samsung themselves gave me.)
Hmm... so the firmware is so retarded that bad values in RAM can permanently break the hardware?
That sounds safe. Hope that thing comes with ECC RAM!
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...
It was Samsung firmware at fault. Thier fault. Place blame correctly.
So the hibernation functionality had to be removed because it could be used to boot an unsigned operating system, but this is A-okay?
So is there need of secure boot?
linus spoke
Well, actually, another alternative is for motherboard manufacturers to continue to make motherboards that boot the same way as they have for some time. So older, fully functional operating systems can continue to boot.
Of course, this would allow us to continue to use those fully functional OSs, and remove a goodly portion of the incentive to upgrade... so one might, if one were cynical, imagine that there is a corporate motive at work here.
I've fallen off your lawn, and I can't get up.
The reason Microsoft gets away with this is because they have dominance in the market and we little users have not taken the initiative to purchase hardware from companies that respect our freedom. In fact there is only one company that has shown any real concern here. ThinkPenguin is the only company you can get a system form with Linux and know that there aren't any proprietary driver/firmware dependencies. The company doesn't sell ANY devices which are not compatible with 100% free versions of Linux. Humorously this is only partially done for ethical reasons. The founder recognized the major problem new users face with Linux is proprietary software. That was while working for a commercial distribution which included a lot of proprietary software. ThinkPenguin now is leading the way on the hardware front mostly thanks to the fact they have made the adoption of Linux by more novice users much easier. Just imagine what they could do if the larger community stopped complaining and started buying Linux friendly hardware.
The implementation in Samsungs UEFI shows some weird behavior. Error code EFI_INVALID_PARAMETER should only be returned, if one of the given pointers to variables is NULL and pointing to an invalid memory section. Samsungs implementation also throughs this error, if the given memory blocksize is not exactly 128 bytes, so for example (like the Linux-efivars module does) 1024 bytes. The Linux module does not expect the strange error code (it checks for NULL pointers itself) and does not report any UEFI variables, no boot entries, no nothing. The installer accepts that and installs the Linux boot entry into the first slot, where actually the boot entry for the setup is located - overwriting that entry! Setup is dead since Linux took its boot entry.
It does look like the Samsung implementation is doing weird things and Linux is doing weird things in return because it is expecting it to follow standards...
EULA : By reading the above message, you agree that I now own your soul.
So ... does this mean Windows installs are just as vulnerable to a malicious piece of code poking bits to the wrong memory addresses and bricking the laptop? since it's an UEFI problem, it should be OS-agnostic.
Good old "BootServices->LoadImage()".
so why the need to use secure boot if windows is so good ?
He who pre-loads the pre-loads pre-loads what he wishes.
I had a giggle, but sorry, bait not taken.
We expect a slightly higher quality of trolling on this site. A little bit of effort please.
Fuck secureboot.
It must die, not be worked around.
Later on in the thread someone said that clearing NVRAM is enough to fix the brick, ie. either remove the NvRAM battery or otherwise prevent it from refreshing the NvRAM for 30 seconds and you're golden. Granted, that still requires opening up the whole laptop.
Has anybody seen confirmation that Samsung will be repairing affected user's machines under warranty? Definitely a design fault, it should be impossible for software to brick hardware.
Can't you just disable secure-boot if you don't want a distro tainted by Microsoft?
I don't know where people get that idea from. If you read the kernel people are just disabling the driver because the code is so utterly retarded. Samsung haven't done shit about it as is typical for Samsung.
It's fault of whoever designed this crap in the first place (Microsoft?). My opinion is that it does NOT serve any useful purpose, abd it doesn't improve overall security of a PC. It only causes problems. The only purpose of this thing is to reinforce Microsoft lock-in on PC consumer market.
ThinkPenguin is a ray of hope. Unless Linux finds a reasonable level of support from hardware makers it's going to keep getting more difficult to counter the strategies of Microsoft, Apple and co. An alternative to buying from ThinkPenguin (since shipping is likely to be a put-off for international orders) is to purchase individual components from those manufacturers who don't restrict their hardware with Windows only drivers or are particularly uncooperative with the FOSS community. This won't directly sway the issue of Secure Boot, but still the FOSS community does number in the tens of millions at least, and so coordinated action can send strong signals, provide it can unite together. Anyone knows of a updated online database for hardware (and their makers) that plays well with FOSS?
There's nothing wrong with secureboot as long as you, as the owner of the computer, can install the keys for your OS. Indeed, you should even have the option to only install your own keys (i.e. to remove the installed keys, ideally with the ability to backup), in case you want to make sure nobody installs another operating system than the one you have chosen.
The Tao of math: The numbers you can count are not the real numbers.
The concept of 'SecureBoot' is inherently unable to accommodate user keys very well. The reason being that abilitiy to write the keystore from the OS in a straightforward manner makes it, by definition powerless. Now it could be mucked with so that for desktop systems you request some one-time passphrase from firmware setup and then use that in the OS to push your key. For servers you could use ability to authenticate to serive processor as a key (complication being that it would have to be a credential beyond the reach of IPMI KCS type interfaces, since that's not securable. Ultimately though, the whole concept of secureboot as the mechanism to always protect the boot seqence is flawed. Thinking about the larger picture proves this out. The more precisely a security mechanism can model the authentic intent of the authorized user, the better. SecureBoot as defined can only model the vendors intent, which has to be fairly wide open. Some people have said that this could protect the integrity of SELinux, but then again malicious policy data could be fed in. You could argue that perhaps they can at least be tamper-evident with an audit log, which is critical but not ambitious enough. What they should have emphasized was a mechanism where the frimware and OS work together with the TPM. The authorized OS takes ownership of the TPM and from then on the boot process be protected in that way. Offline attacks can be meaningly mitigated to a significant degree, which SecureBoot really cannot. The OS would require passphrase to sign kernel, initrd, and loader configuration file. The model wouldn't scale up beyond that, but the likes of LUKS could actually meaningfully take it from there to assure tamper-proof fielsystem and hibernate memory images.
XML is like violence. If it doesn't solve the problem, use more.
Just because a developer puts out a *workaround* to avoid exacerbating a problem, does not mean they were the ones to make the mistake first. Notably, I personally know of UEFI implementations where in any way messing with the method to get into setup is impossible from the running OS. It is perfectly possible and reasonable to have a frimware that can keep itself whole and allow a user to be confident that no matter what the OS does, they can trivially reset to defaults. I know developers that exceedingly careful about the efi variable space and how it musnot t impact the ability to recover.
XML is like violence. If it doesn't solve the problem, use more.
I just hope this doesn't end up like ACPI, where everything is broken and only companies with secret specs can be made to work easily.
Linux followed the IEFI standard. Samsung did not. Unambiguous foul on samsung.
More specifically, Samsung tried to implement version 2 of the standard and advertised it as version 2, but accidentally left in code which required version 1 behavior. Additionally, if an OS implemented version 2, when Samsung's firmware got confused, it didn't throw the proper error message, but instead returned it's own address to be overwritten. So at least two failures on Samsung's part. Linux simply followed the standard as written.
> ... the risk of allowing corporations to inhibit
> competition was less threatening than the risk
> of allowing the government to regulate such
> behavior. It reflects the laissez-faire notion that
> corrupt elected officials are more dangerous
> than corrupt corporate executives.
The nature of government is that they force you to do what they command, whether you want to or not.
But you don't have to do business with non-government corporations. (It's not like you are forced to buy health care.)
For this reason, corrupt elected officials are more dangerous than corrupt corporate executives.
Everyone keeps mentioning Microsoft like they thought up this whole UEFI thing. Well guess who else is also a "promoter" company.
AMD, American Megatrends, Apple, Dell, HP, IBM, Insyde Software, Intel, Lenovo, Microsoft, and Phoenix Technologies.
Only the State obtains its revenue by coercion. - Murray Rothbard
Will BSD based OSs, such as PC-BSD, boot as well?
Its called "disable" and is written into the UEFI spec. You don't have to run it. This has as much impact as those TPM chips that everyone here claimed would kill Linux back in 2005 or so.
Only the State obtains its revenue by coercion. - Murray Rothbard
Yes- h-node.org is pretty good although there are problems with using it to find compatible/friendly hardware. Like all other databases for GNU/Linux it suffers from the fact manufacturers swap chipsets and model numbers don't equal chipsets. The chipsets are what really matter because that is what GNU/Linux has to support driver wise. It is better than nothing though since without it you would be completely lost. However I wouldn't want to use it unless there were no other options available.
Also- doesn't ThinkPenguin have European & US operations? They mention a UK warehouse on the about page in addition to there US operations.
Ok, I can type more than that for my comment.
Blogging because I can...
Haha I wish! I'm in India and getting it shipped is a no-go. I hope they open a store or franchise here in the future.
I can't think of as sweeping a monopoly as that of MS, for any other branded global product! People seriously should get out of the Microsoft gravity well. :-P
A handful of nerds will never even be noticed when hundreds of millions of normal people continue to buy without any knowledge
While there might be a good use for something like SecureBoot, answering to a manufacturer (whether it be Microsoft or anyone else) only makes avoidance or removal the only good decisions.
Same thing goes with TCPA/TCG equipment.
Twitter supports and protects racists - by smearing their critics with the "Hate Speech" label.
...and you wonder why people haven't all gone Linux. I didn't understand a word you said in the snippet above.
You mean those Windows 8/RT licenses for devices that few consumers are buying? The OEMs got suckered because they did not have he spine to tell Microsoft where to go. Now they realize they made a mistake, but the problem is already in existence. The OEMs should make a pair of firmwares for each device, and give the purchaser the choice, not let Microsoft dictate.
You are being MICROattacked, from various angles, in a SOFT manner.
I definitely commend MS for attempting to get back in market, but this was wrong way to do it. Reality is, more people may buy hardware manufacturers hardware made for MS if it can be made Linux bootable otherwise MS will just continue to loose market share. As we have already seen with MS tablets, no one wants a slimmed down windows 8 OS, they want the full OS so they can use what they been use to using for years. I believe MS does have a big chance at market share here in tablets, but only if it runs windows 8 fully(users can do what they want like hey been use to, not limited by the surface tablets). MS has biggest advantage here I believe if they go this route, since all gamers and office users are use to windows to begin with. The thing MS does need to give up to get back into this century is to make windows 8 free as an OS. That will allow them to compete fully in tablet industry, allowing people dual boot Linux and windows 8 for an example, or even as a virtual Image. As it stands we have moved from industrial age to computer age for awhile now, only open source has survived because of active development. We have seen time and time again how people who do not move their program/OS to opensource, have eventually been outdated within a few years with something new, vs an opensource release where programmers can voluntarily help improve it, thus making it exist even to do this. IE: Linux, apache, bind ... just to name a few.
MS needs to make something of value, not try to prevent people doing things, there are far to many programmers in this world today to undo anything restrictive, it makes sense to go the former route. A bigger question is how would MS like it if Linux manufacturers went on to secure the boot loader to prevent MS from ever running, would they like that? Would it affect their revenue? Would it be anti-competitive? Of course. I think they big picture here is "Do unto others and you would have done unto you".
So Apple does UEFI, too?
I don't know why PC vendors have allowed Microsoft to control their hardware. The hardware should be released as-is, and the software to fit the hardware. It's completely backwards.
It will. You bet it motherfucking will.
Any standard that requires more than 2 hours to implement will be broken beyond belief in every possible way by OEMs, and anyone who believes otherwise is delusional.