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."
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.
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.
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."
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.
That's how you learn not to have sex on top of your PC tower, with router next to it, and with no additional furniture for support in the end game.
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.
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
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*
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.
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?
Try google...
No sig today...
I'll wait for the pre-pre-bootloader.