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."
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 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.
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.
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.
On x86, you can -- for now. On ARM, you can't -- at least if it is Windows 8 certified.
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.
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.
It is not written into the UEFI spec. In fact, the UEFI specification makes no such statements with respect to it being possible to disable secure boot, only how it is supposed to work. That was done deliberately.
The only reason you can even turn off secure boot on hardware now is because Microsoft caught shit for the first pass of their guidelines that left it up to OEMs whether or not users would be able to turn off secure boot. Had they left like that you can guarantee that Samsung et. al. would have locked every laptop and desktop they shipped with Windows 8 and you would never actually own your PC again.
I bet Samsung is more pissed that Microsoft changed it so they had to allow for unlocks than they are at their own developers.