Slashdot Mirror
Linux Foundation's Secure Boot Pre-Bootloader Released
hypnosec writes "The Linux Foundation's UEFI Secure Boot pre-bootloader for independent Linux distros and software developers has finally been released. Announcing the release of the secure boot system James Bottomley noted that the signed pre-bootloader was delivered by Microsoft on February 6th. Bottomley has released two validated files: PreLoader.efi and HashTool.efi. Bottomley has also created a bootable mini-USB image that provides 'an EFI shell where the kernel should be and uses Gummiboot to boot.' Just last week the pre-bootloader had to be rewritten to accommodate booting of all versions of Linux."
It'll take a week or two, and then they'll report that it blew up their computer, crashed the Internet, and impregnated their teenage daughter.
This is great news for Linux distributions, and a small victory in the losing battle for openness.
But in the spirit of openness, hopefully bootloaders for NetBSD, OpenBSD, and FreeBSD will also be eventually signed.
Everyone should be able to install and run whatever they want on their own computers.
Yay! Now I can finally ask Microsoft for permission to boot my Linux machine! I've been eagerly awaiting this for years and years.
Oh, I can just disable in the EUFI, you say? Yes, I'm fully confident that situation will persist going into the future. Because that's how these things go.
All the time Microsoft have control, they will always have control.
Why don't people LEARN from history from how they operate?
This will all go horribly wrong, mark my words.
And I still do not understand how Microsoft get to control this.
Will dell systems be able to use this or will MS try to block this on dell that they now own a part of?
MS don't own Dell yet. But that is irrelevant - they can change the rules any time they want too {embrace period}
If your mainboard requires you to use SecureBoot, does this mean you are also forced to boot using EFI instead of some legacy BIOS fallback?
I did not have the best experiences with using EFI in actual EFI mode and not some BIOS fallback mode. My laptop (a eeePC 1215B) refused to boot the windows install in EFI mode and had some wifi problems on Linux; everything works perfectly in BIOS land); I had similar experiences with a Lenovo S205 of a colleague.
Requiring a prompt does cripple the bootloader when compared to others that are somehow exempt from it.
Twitter supports and protects racists - by smearing their critics with the "Hate Speech" label.
Now that this has been achieved, whats the status of Win8 / Ubuntu dual boot via Wubi installer ?
What is the current procedure to get this set up ?
I've heard somewhere that trying to override UEFI bricks some Samsung laptops. Anything about this?
I think that it could depend on manufacturers correctly implementing UEFA. You can always depend on bugs. Remember "THERE ALWAYS IS ANOTHER BUG" that you have not discovered yet.
they now offer theirs...
--
Linux user since 1991
Seriously, when Microsoft is paid for the key and they own the key into our computers, we've lost. Simple solution: Avoid ARM-based machines as long as Microsoft requires that no way exists to disable Secure Boot. By buying into this shit, we're just setting ourselves up to be fucked in the ass by Microsoft. I can't say anything good about the Linux Foundation for playing ball with these assholes either. Pre-bootloader, my ass--more like pre-pre-boot-extra-complexity-nightmare, thanks to Microsoft. Having to use this would be a disgrace; that alone should be enough to get people to buy more compatible hardware (but won't be).
That sort of doesn't make sense, the kernel is in full control of the whole physical memory, and once you boot the kernel, it's perfectly free to recreate its state and that of all running processes.
Ezekiel 23:20
You sort of dont know how hibernate works.
"His name was James Damore."
I'll never by this crapware, I can live with UEFI, what is neat is booting from file-system instead of MBR ... but did we really need UEFI for this ?!? ... less bugs ... less code ... less money wasted.
They could have well used http://www.coreboot.org/Welcome_to_coreboot
But I'l never buy a device that has a mandatory boot-lock in it (or sell) (if such devices exist) ... of cours as "experts" we could badmouth them ...
But we are a minority
http://blog.hansenpartnership.com/linux-foundation-secure-boot-system-released/#comment-4096
"Why Microsoft is allowed to use its relationships to OEMs in this way seems to fly in the face of anti-trust law and the latter circumstance is what is objectionable and should be pursued."
Microsoft surely knows that Secure Boot won't affect savvy nerds from converting to Linux. They also surely know that Linux is still growing organically, relying on word-of-mouth and firsthand try-before-you-buy experience.
You are seriously delusional. "Converting" to Linux is not, has never been and will never become a threat to Microsoft. Right now Microsoft is pressured on other fronts, such as desktop PC losing relevance, not being on the boat on mobile and not competing effectively in the tablet game.
You are trying to wage last decades battle. Microsoft does not feel threatened by Linux on the desktop *at* *all*. Get real. The threats to Microsoft do not come from conversions in the x86 space, the come from vertical players and mobile, like Chromebooks, tablets, smartphones.
Note how *all* of these emerging platforms have more restricted app models, and especially *boot* models. Microsoft is simply evolving their primary platform to match the features and security (from closed and semi-closed gardens) of the threatening platforms.
The threat to Microsofts desktop business is *not* Linux. Even though Linux has evolved in that space and on the surface appears to be able to go head-to-head, Microsoft Windows is still *much* more mature than any desktop Linux. Consider for instance group policies, restart manager, volume shadow service, various troubleshooting guides, shims for both application and device compatibility etc. The real threat is that the desktop become irrelevant.
If the desktop is perceived as less secure than an online counterpart, Microsoft will be losing. They *need* to ensure secure boot. It is not a anti-Linux move at all. You are flattering yourself. And being stupid.
Reading slashdot one-liner: (irm http://rss.slashdot.org/Slashdot/slashdot).rdf.item | fl title,desc*
... why Microsoft is the gatekeeper for what OS's are allowed to boot on the computers I buy.
Install Ubuntu and run Windows under VirtualBox, or vice versa if you're a gamer.
I honestly don't understand why anyone dual boots anymore. I just seems inconvenient, in my opinion.
You've never used a Hypervisor, have you?
cpghost at Cordula's Web.
Then enlighten me, oh exalted one!
Ezekiel 23:20
True. Except that it can be used to bypass secure boot:
1. Boot secure OS.
2. Hack it, get root.
3. Write hibernate image to the drive containing your hacked kernel, which includes disabling of the code to delete the image after use.
4. Trigger reboot.
5. Pwnage.
It'd take some very impressive skill to do that - it isn't something you could just make a script-kiddie toolbox for. The only way to prevent this is for the kernel to use TPM hardware to sign the boot image. As this isn't yet an option, it's debated if Secure Boot linux should also disable hibernation, in order to be strictly compliant, even though it introduces much user annoyance to provide protection against an attack that would be near-impossible for even the best hacker to pull off.
Virtualbox is a hypervisor. Unless you ment a bare-metal hypervisor, but if you did I"m sure you would have indicated that as apparently you know a lot about what is and isn't a hypervisor.
Some things need low-level hardware access to work that a VM can't do. Try running a triple-headed accelerated monitor setup from a VM. No easy thing. There's also a substantial memory overhead in virtualisation - if you've only got a laptop with a gig or two of ram, then you can't afford to throw 500MB of that away holding Windows in memory to host your Linux VM or vice versa.
Why not our own key signing cert? Myself and many others would gladly pay to help run such a service for the community. Why hand the litereal keys to the kingdom to the very person whos been trying to destroy you for years?
Nobody ever brings this up but me. Guess who else is in the UEFI group?
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
To quote Wikipedia "The board of directors includes representatives from eleven "Promoter" companies: AMD, American Megatrends, Apple, Dell, HP, IBM, Insyde Software, Intel, Lenovo, Microsoft, and Phoenix Technologies."
No its not just Microsoft.
Only the State obtains its revenue by coercion. - Murray Rothbard
This is /. so nobody cares who else may be part of UEFI.
All that matters is blaming Microsoft and praising Apple.
In a sense, they do not own a piece of Dell. From what I understand, they contributed some dough as a loan and I have not heard they will have anyone on the board. Dell cannot live on the desktop market, in the server market they cannot ignore Linux.
This doesn't stop MS from using its usual bag of dirty tricks, but if Dell has any sense and balls, he'll keep MS away from actually running the business.
2-3 days a week, actually. Gentoo/Funtoo host and various guests.
Having to reboot my system to use another OS is inconvenient.
Whatever was the problem with the standard BIOS that we've had for decades? Having the PC's most "hardware-near" firmware locked down only to run code permitted by a third party seems like an extremely bad idea. The whole point of a computer is that it obeys MY instructions blindly and perfectly.
I know, I've heard the argument for security, but has anyone ever even seen real, actual BIOS malware? As far as I'm concerned, that only exists in theory.
In what situation would you need hardware accelerated access to two operating systems? Choose a host OS you use most and boot up your Guest OS on ome of those displays. Honestly I've never seen the value in multiple monitors. On linux we have Virtual Desktops for a reason.
Also I don't know anyone who would ever need to dual boot on a system with only 1GB of RAM. And if they did it was for gaming, and they wouldn't be limited by RAM as thry would have adequate hardware. And again, if they are gamers on a laptop, why the hell are they dual booting? Just spin up an OS under VirtualBox or similar ona Windows host.
I still fail to see any legitimate reason to dual boot in 2013.
True. Except that it can be used to bypass secure boot:
1. Boot secure OS.
Easy, assuming Microsoft operating systems are defined as a "secure OS", which they are for purposes of secure boot, despite all evidence to the contrary.
2. Hack it, get root.
Easy, assuming a Microsoft OS again...
3. Write hibernate image to the drive containing your hacked kernel, which includes disabling of the code to delete the image after use.
No need to disable such. Once you're at the stage of "waking" into a hacked kernel to boot, you can just write a new image each reboot, becoming how you always boot from then on. In any case, the only real trick here, regardless of which way you decide to handle reboots, is writing a hibernate image and hacking the on-disk kernel in the image. Is this really any more difficult than hacking a kernel in memory? Indeed, isn't it easier?
4. Trigger reboot.
Yup... trivial... once you get past step 3, the machine is pwnt...
It'd take some very impressive skill to do that - it isn't something you could just make a script-kiddie toolbox for.
Anything that you can do, you can make a script-kiddie toolbox for. The person who makes the toolbox obviously has more impressive skills than a script-kiddie, but that's pretty much always the case. This is not the easiest hack in the world, but I would say calling this "near-impossible" is extreme hyperbole.
"Convictions are more dangerous enemies of truth than lies."
True. Except that it can be used to bypass secure boot: 1. Boot secure OS. 2. Hack it, get root.
Why exactly have you included steps 3 and 4? The way I see it, you can jump from 2 straight to 5!
Ezekiel 23:20
Honestly I've never seen the value in multiple monitors.
Everyone stopped reading right here. Seriously.
More pixels for less money than single monitor solutions. You were talking about value, right? Then why is it that you didnt even try the value calculation?
"His name was James Damore."
Why exactly have you included steps 3 and 4? The way I see it, you can jump from 2 straight to 5!
rootkit.
Reading slashdot one-liner: (irm http://rss.slashdot.org/Slashdot/slashdot).rdf.item | fl title,desc*
Having to get, what amounts to approval, from Microsoft to run linux on new hardware.
Sorry, but this is fucking disgusting!
I noticed you mentioned Chromebooks...
Those are x86 systems based on Linux (though not really a "Linux distro" thank goodness). ChromeOS is really starting to gain traction now, and it could reinvent the PC the way iOS/Android reinvented the smartphone and tablet.
The important thing about ChromeOS and Android and the moribund Linux desktop distro class is not that they use Linux or FOSS but that they are things that MS doesn't own, yet they can run on standard x86 hardware. The issue is whether any non-MS OS will be a hassle to install on a PC.
I think both you and the grandparent are being myopic about the Linux distro issue. Yes, the slipshod distro scene is almost laughable as a threat against Windows on the desktop. But that is not the only type of alternative and Google-backed stuff is quite credible. There ought to be a Godwin's law for PCs: Someone in a discussion about computers is bound to fixate inappropriately on desktop Linux.
You do know that s2disk supports encryption?
man s2disk:
" The uswsusp system supports encrypting the image written to disk and features a splash system, see uswsusp.conf(8) for more information"
encrypt
If the "encrypt" parameter is set to 'y', the s2disk and resume tools will use the Blowfish encryption algorithm to encrypt/decrypt the image. On resume and suspend
you will have to supply a passphrase. By using a pregenerated RSA key, you can avoid having to type a passphrase on suspend. See the "RSA key file" option for more
information.
man uswsusp.conf
" RSA key file
If this option points to a valid RSA key, which can be created with suspend-keygen, the s2disk tool will generate a random key for the Blowfish encryption that will
be passed to the resume tool within the image header with the help of the RSA cipher. Consequently you only need to type a passphrase on resume."
To me it looks like there is no security issue with supporting restoring state from hibernate and secureboot.
Obviously I don't know what's going on here at all. I saw "delivered by Microsoft" and decided that I'm not interested in whatever it is. Should I bother to look into whatever this is about any further than that?
Wubi doesn't support UEFI. Once it does, it can use the same signed bootloader that Ubuntu currently uses.
One monitor with 8 virtual desktops has more screen real estate than 3 physical monitors for the cost of one monitor.
You can only focus on one screen at a time anyway, so what is the purpose of cocking your head over to look at something when you could simply switch virtual desktops?
I keep 8 available on my desktop workstations and 6 on my laptop.
True. Except that it can be used to bypass secure boot: 1. Boot secure OS. 2. Hack it, get root. 3. Write hibernate image to the drive containing your hacked kernel, which includes disabling of the code to delete the image after use. 4. Trigger reboot. 5. Pwnage.
OK, I get where you're coming from, but you fail to see that Secure Boot and TPM are completely pointless endeavors, and they're FULL of holes because the OSes are FULL of holes. If there's a mistake in the kernel code that allows a root level exploit to happen then it can simply be re-exploited each time you boot your system, see? No need to mess with the boot-up files. Even if your CPU is running encrypted instructions of signed programs once you find some data that triggers a buffer overflow, you can simply use return oriented programming to build the exploit. This means your exploit is built out of "op codes" of data that jump from one existing piece of signed and encrypted code to another -- You don't even need to know what the code is that's executing, you just log the changes in state the locations perform, and these become your (complex) operations with which to build the exploit. This already exists, it's not hypothetical. Return Oriented Programming is made out of existing code, even if it's signed and encrypted. SecureBoot is pointless so long as kernels have mistakes that allow unexpected stack smashing, or heap function pointer overwriting. There doesn't seem to be any way to prevent the mistakes, since your human race tends to make mistakes. SecurityTheaterBoot is a more apt. name for it.
Ah, but if the kernels could be written correctly -- with no mistakes -- then there would be no exploit vectors to exploit, and thus absolutely no reason for Secure Boot to exist. It's pointless from a security perspective, it serves primarily to make it harder for users to install alternate OSs. That's all. SecureBoot should be considered harmful and avoided if possible.
It'd take some very impressive skill to do that - it isn't something you could just make a script-kiddie toolbox for.
NO, that's just wrong. Do you even know what you're talking about? Yes, it takes more skill than a script-kiddie currently has, but it just takes one skilled hacker to crack the system and add the exploit to an exploit tool kit then the script-kiddie toolbox would contain the impressive exploit.
What? Exploits aren't impressive anymore once they've been automated? Gimme a break man. This happens all the time, it's HOW script kiddies even exist. Ugh, sorry, but your words reek of ignorance -- It's like you don't even comprehend what your words imply (by your logic script kiddies wouldn't exist).
The only way to prevent this is for the kernel to use TPM hardware to sign the boot image. As this isn't yet an option, it's debated if Secure Boot linux should also disable hibernation, in order to be strictly compliant, even though it introduces much user annoyance to provide protection against an attack that would be near-impossible for even the best hacker to pull off.
"Only" -- That word shouldn't be used lightly, because it tries hard to make you a fool, every time. What if we put Linux in the BIOS firmware. The PC turns on and is running Linux. Firmware can check its hash / fingerprint matches the install image on boot, like it does already, (even CMOS checksums for integrity), without requiring anyone to be in bed with a flawed PKI model run by Microsoft. If we simply give users an option in the BIOS boot menu that says: "Enable OS install on next boot", and it would flash part of the firmware with the /boot/ data. That would be TONS simpler than entering a long hex code that they're going to fuck up, and to bypass this unencrypted method of booting securely would require entering BIOS and changing a setting (or cracking BIOS security) -- Which is exactly the same as with Secure boot.
If the OS w
Assuming the key used to sign my pretty new Ubuntu,Fedora,Windows,Whatever-(pre)-bootloader finds - through whatever means of social engineering, bribing or disgruntled janitor - his way to the notorious IT-entrepreneur Mal Wareauthor, who uses it to sign boot-rootkits.
As I understood it, a key used for such nefarious purposes would be blacklisted. Now, will my platform vendor update my key-DB remotely? Will the updated DB be in the next firmware-update? That would pretty much kill the Computer for every single installation of the signed OS, until someone tells the victim how to disable secure boot.
Oh, and every install-medium with a blacklisted signature would be useless too, but that's fine. I can always recycle useless optical discs as coasters, and make new ones from Images. I guess Microsoft would provide one in such a case too.
It looks to me, as if blacklisting a leaked key isn't something I would like to be responsible for. Did I overlook something?
2. Hack it, get root.
Easy, assuming a Microsoft OS again...
I'd ask you to prove how easy it is, but I know that you are a full of shit troll.
Try google...
No sig today...
Am I the only one who thinks the presence of a "some new bullshit protocol compliant" bootloader is more worthless than the new protocol?
The open source community should not be aiming to be compliant with anything like this.
I'll wait for the pre-pre-bootloader.
Once you realise that SecureBoot isn't designed to protect you, or your OS, it all begins to make sense. SecureBoot has been created to kill off the likes of DAZ Loader. That's all there is too it.
2. Hack it, get root.
Easy, assuming a Microsoft OS again...
Yeah you swallow that anti-MS koolaid. If it's so easy how about you tell us how to you can just hack windows 8 and get root? oh right you can't.