×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

New Secure Boot Patches Break Hibernation

Unknown Lamer posted about a year ago | from the intentional-side-effects dept.

Bug 196

hypnosec writes "Matthew Garrett published some patches today which break hibernate and kexec support on Linux when Secure Boot is used. The reason for disabling hibernation is that currently the Linux kernel doesn't have the capability of verifying the resume image when returning from hibernation, which compromises the Secure Boot trust model. The reason for disabling the kexec support while running in Secure Boot is that the kernel execution mechanism may be used to load a modified kernel thus bypassing the trust model of Secure Boot." Before arming your tactical nuclear flame cannon, note that mjg says "These patches break functionality that people rely on without providing any functional equivalent, so I'm not suggesting that they be merged as-is." Support for signed kexec should come eventually, but it looks like hibernation will require some clever hacking to support properly in a Restricted Boot environment.

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

196 comments

Why is this a story again? (3, Insightful)

Anonymous Coward | about a year ago | (#42721527)

A patch that is not going to be merged into the kernel proper breaks hibernation with secure boot in Linux...some editor is trying desperately hard to get a flame war started. If you're really that desperate for ideas try something creative, like creating a fake petition to have Minecraft converted from Java to C#. It's not hard to start a flame war.

Fucktard.

Certificates can be revoked (5, Interesting)

tepples (727027) | about a year ago | (#42721571)

A patch that is not going to be merged into the kernel proper breaks hibernation with secure boot in Linux

Perhaps the fear is that if the patch is not merged, Microsoft will revoke the certificates that have been used to sign mainstream GNU/Linux distributions.

Re:Certificates can be revoked (1)

benjymouse (756774) | about a year ago | (#42721659)

Perhaps the fear is that if the patch is not merged, Microsoft will revoke the certificates that have been used to sign mainstream GNU/Linux distributions.

My thoughts too. I'm sure that MS has requirements that you will have to meet for MS to allow you to sign a bootstrapper, like e.g. requiring that the user is prompted and alerted to the fact that the system is booted to an alternate OS. Otherwise (if they allowed silent boots to non-Windows OSes) they would risk a rootkit simply silently booting a Linix and then Windows within a compromised VM. However, it is hard to see how an attack using the Linux hibernation and/or kexec vectors could lead to a compromised Windows system.

Or perhaps MJG just realized that some Linux distros (Fedora, Red Hat) now claim to use secure boot to enhance system security but not all bases have been covered.

In other words, if a system was compromised, the malicious software could reboot to a kernel with a rootkit using kexec. The compromise would not survive a system reboot, but it could allow a rootkit to hide itself and maybe even simulate a software-initiated reboot to bypass secure boot and ensure that the rebooted kernel is still compromised.

Re:Certificates can be revoked (2)

Rockoon (1252108) | about a year ago | (#42721901)

A compromised system could simply always hibernate even when the user requests a proper shutdown, and then fake the appearance of a real bootup upon power up.

While you would not expect such an elaborate design as a form of mass public malware, consider how effective this would be with a more targeted attack.. the trusted boot process nullified to trivially.

Re:Certificates can be revoked (-1)

Anonymous Coward | about a year ago | (#42721843)

They won't. Stop FUDing.

Re:Certificates can be revoked (3, Insightful)

Trogre (513942) | about a year ago | (#42721929)

Is no one else here alarmed at the unreasonable amount of power Microsoft has over the future of GNU/Linux on Secure Boot platforms?

That alone should be cause enough to lobby hardware manufacturers to have secure boot abolished and to hell with those little "Works with Windows 8" stickers.

Microsoft have already mandated that systems with ARM platforms MUST NOT have an option to disable Secure Boot. Therefore the only software that will boot on these systems is software that Microsoft has blessed. I know they would love nothing more to dictate such terms on x86 hardware too. I predict that within five years, notwithstanding active opposition RIGHT NOW, they will do exactly this.

This, like climate change, is something I really, really hope I am wrong about but fear that I am not.

Re:Certificates can be revoked (2)

vux984 (928602) | about a year ago | (#42722083)

Microsoft have already mandated that systems with ARM platforms MUST NOT have an option to disable Secure Boot.

if they ship with Windows 8 RT.

There is nothing stopping asus/acer/google/ and who ever else out there from releasing ARM platforms with secure boot configured any way they like.

Perhaps, at worst, we are reaching a point int time where if you want a Windows PC you will buy one, and if you don't want a windows PC you will buy one without windows.

And the people looking to take a windows PC and convert it to a linux pc... well they're will always be someone you can take it to to flash an open bios or otherwise 'unlock it'.

Re:Certificates can be revoked (5, Interesting)

Nerdfest (867930) | about a year ago | (#42722315)

I just bought a very nice laptop from System76. Good price/performance, fantastic Linux comparability, and no Microsoft tax. I figured I might as well put my money where my mouth is on supporting vendors that have good support for Linux.

Re:Certificates can be revoked (1)

recoiledsnake (879048) | about a year ago | (#42722175)

Microsoft have already mandated that systems with ARM platforms MUST NOT have an option to disable Secure Boot. Therefore the only software that will boot on these systems is software that Microsoft has blessed.

That's just plain wrong. Samsung can ship Android tablets just fine without it even having Secure Boot.

Last I heard, Samsung shipped a lot of "ARM platforms" with Android and Windows 8 PCs and Windows RT tablets just fine so that means jack shit.

Re:Certificates can be revoked (1)

Trogre (513942) | about a year ago | (#42723003)

Perhaps I should have been clearer:

Microsoft have already mandated that systems with ARM platforms MUST NOT have an option to disable Secure Boot, in order to qualify for Windows 8 hardware certification.

Source [microsoft.com] :
Mandatory. Enable/Disable Secure Boot. On non-ARM systems, it is required to implement the ability to disable Secure Boot via firmware setup. A physically present user must be allowed to disable Secure Boot via firmware setup without possession of PKpriv. A Windows Server may also disable Secure Boot remotely using a strongly authenticated (preferably public-key based) out-of-band management connection, such as to a baseboard management controller or service processor. Programmatic disabling of Secure Boot either during Boot Services or after exiting EFI Boot Services MUST NOT be possible. Disabling Secure Boot must not be possible on ARM systems.

Re:Certificates can be revoked (1)

shutdown -p now (807394) | about a year ago | (#42723065)

Unlike Intel, the market of ARM hardware does not have Microsoft as a dominant player - indeed, its market share there is minuscule. If you want to buy an ARM device that runs Linux, you've got plenty of choices, from Chromebooks to various Android tablets to dedicated GNU/Linux devices. I very much doubt that Linux kernel developers (or the community as a whole) really care that much about the ability to install Ubuntu on their Surface.

To many X86 servers do not boot Windows (1)

Joe_Dragon (2206452) | about a year ago | (#42722241)

To many X86 servers do not boot Windows for them to try to push that kind of lock down.

Re:To many X86 servers do not boot Windows (4, Insightful)

0123456 (636235) | about a year ago | (#42722365)

To many X86 servers do not boot Windows for them to try to push that kind of lock down.

Yeah, so? Your $1,000 server motherboard will still be able to run Linux. Doesn't help the rest of us.

If you give Microsoft the power to control what software will and won't run, then they will use it, sooner or later. It's a fscking retarded idea.

Re:To many X86 servers do not boot Windows (1)

exomondo (1725132) | about a year ago | (#42723185)

If you give Microsoft the power to control what software will and won't run, then they will use it, sooner or later. It's a fscking retarded idea.

And how exactly would one do that? You mean every motherboard manufacturer is going to build every one of their products locked to Windows 8?

Re:To many X86 servers do not boot Windows (0)

Anonymous Coward | about a year ago | (#42723361)

Not yet - wait until Windows 9..

Then every motherboard producer that want a MS certification HAS to implement secure boot.
And it would not surprise me a bit if by then they want the same restrictions on X86 as they managed to push on ARM devices.

The box of pandora is already open..
Just wait and see.

Re:Certificates can be revoked (1)

Smauler (915644) | about a year ago | (#42722685)

Is no one else here alarmed at the unreasonable amount of power Microsoft has over the future of GNU/Linux on Secure Boot platforms?

This is one of the reasons why I'm very behind what Valve are doing now - they are pushing for OS independent systems. Yes, they have DRM. They also provide a service better than your games on disks too. I'm absolutely hoping they'll push steam hard, and bring linux with them.

The only reason I use Windows is for games. If there was another place I could get new, big games, I'd switch in a heartbeat. I'm far from loyal to microsoft - I doubt anyone is.

Re:Certificates can be revoked (2)

exomondo (1725132) | about a year ago | (#42723167)

Perhaps the fear is that if the patch is not merged, Microsoft will revoke the certificates that have been used to sign mainstream GNU/Linux distributions.

Microsoft doesn't control the certificates, VeriSign does, Microsoft can't just 'revoke' certificates and stop SecureBoot from loading them, they don't control any of that.

Re:Certificates can be revoked (1)

Anonymous Coward | about a year ago | (#42723367)

Dream on my friend, just dream on...

Re:Why is this a story again? (1)

Anonymous Coward | about a year ago | (#42721575)

Hey, HEY! My system doesn't hibernate, it passes out from exhaustion. Call me when we get a kernel level fix for that. /s

lm-sensors (3, Funny)

tepples (727027) | about a year ago | (#42721597)

My system doesn't hibernate, it passes out from exhaustion.

You could try setting up lm-sensors [tuxtweaks.com] . Or is your motherboard not supported [lm-sensors.org] ?

Re:Why is this a story again? (1)

Lakitu (136170) | about a year ago | (#42721725)

A patch that is not going to be merged into the kernel proper breaks hibernation with secure boot in Linux...some editor is trying desperately hard to get a flame war started. If you're really that desperate for ideas try something creative, like creating a fake petition to have Minecraft converted from Java to C#. It's not hard to start a flame war.

why would that start a flame war? Java and C# are basically equivalent.

Re:Minecraft converted from Java to C# (1)

Anonymous Coward | about a year ago | (#42722117)

That's long overdue!

Re:Why is this a story again? (1)

Anonymous Coward | about a year ago | (#42722521)

If you're really that desperate for ideas try something creative, like creating a fake petition to have Minecraft converted from Java to C#. It's not hard to start a flame war.

You can't start a flame war with near-universal agreement.

There'd be like 10 people, around the world, who would argue with that idea, and 6 of them are VB programmers.

Re:Why is this a story again? (1)

Curate (783077) | about a year ago | (#42722533)

I agree this article is flame bait, because the patch in question does NOT break hibernation. It only breaks resume from hibernation.

Meh. Hybernation is overrated (0)

ravenswood1000 (543817) | about a year ago | (#42721529)

Who needs it anyhow, hehehe.

Re:Meh. Hybernation is overrated (2, Insightful)

Anonymous Coward | about a year ago | (#42721601)

No, "Secure" Boot is overrated. Very few people have any need for it; mostly a tool for corporate entities to strong-arm others in to complying with their every whim.

Re:Meh. Hybernation is overrated (-1)

Anonymous Coward | about a year ago | (#42722511)

Ohh you put quotes around secure. That's cute.

Making root not root? (1)

Myria (562655) | about a year ago | (#42721557)

Seriously? A patch to block root users from running kernel images? This is like how it works in Windows: applications not running as root aren't allowed to unsigned kernel code. What's the point of making root not root?

Is he going to disable the 50 other ways in which root programs could take over the kernel, too?

Re:Making root not root? (5, Informative)

Rockoon (1252108) | about a year ago | (#42721611)

You really dont seem to understand the technologies involved.

Hibernation does a complete dump of the memory and thread state of the system to disk, and when the computer is later booted a well behaved loader sees the dump and restores the memory and thread states from disk.

The problem is that anyone with physical access can fuck with the memory dump in between the hibernation and the restore, thereby injecting untrusted code into the supposedly trusted environment.

But thanks for giving us your ignorant opinion.

Sign the hibernation file (3, Interesting)

tepples (727027) | about a year ago | (#42721653)

The problem is that anyone with physical access can fuck with the memory dump in between the hibernation and the restore

Anyone with physical access can probably reset the BIOS password and turn off secure boot. But barring that, perhaps one solution is to sign the memory dump with a key stored in the TPM.

Re:Sign the hibernation file (3, Informative)

Rockoon (1252108) | about a year ago | (#42721811)

Anyone with physical access can probably reset the BIOS password and turn off secure boot.

The point of secure boot is to make possible a chain of proof attesting that everything that gets loaded into ring0 has not been modified. Clearly if you can disable the chain of proof then you can disabled the chain of proof, but you cannot do so invisibly, which is the entire point of secure boot.

Re:Sign the hibernation file (3, Insightful)

0123456 (636235) | about a year ago | (#42722371)

The point of secure boot is vendor lockin. The point of Linux is to not be locked to a vendor.

Re:Sign the hibernation file (0, Informative)

Anonymous Coward | about a year ago | (#42723227)

I wish people wouldn't resort to ridiculous hyperbole when the underlying argument is reasonable.

The point of secure boot is not vendor lock-in, it's the chain of proof, as the GP attested. There are some reasons why this has downsides for FOSS, but that's the purpose.

When you say shit like this you sound like the people who say the point of DRM is to control your computer or remove your fundamental freedoms, when in actuality the point of DRM is to promote sales through reducing piracy. Whether or not it's successful, that's its point.

A more effective vendor lock-in would probably have no signed 3rd party bootloader.

Re:Sign the hibernation file (1)

VortexCortex (1117377) | about a year ago | (#42723303)

Anyone with physical access can probably reset the BIOS password and turn off secure boot.

The point of secure boot is to make possible a chain of proof attesting that everything that gets loaded into ring0 has not been modified. Clearly if you can disable the chain of proof then you can disabled the chain of proof, but you cannot do so invisibly, which is the entire point of secure boot.

So, uh, wouldn't we just then perform a SHA512 hash of the dumped hibernation memory? A salted hash is good enough to detect tampering if you're not concerned about hiding the data in the dump. A loader would then perform the same salted hash of memory as it's loading it and abort if the resulting hash doesn't match the on-disk hash. Of course the same code signing chain technology Secure Boot employs can be used to sign the salt & hash to ensure the dump's integrity.

OK, here's the thing: Is there any kernel level exploit in the OS? If the answer is yes, then return oriented programming can be used to create malware that runs even when the code is signed and encrypted -- It'll just use the existing valid code of the system to create itself. You don't even need to know exactly what the encrypted code does, you just have to observe the state changes of the system and develop your malicious return oriented "op-codes" out of the places you can jump to. There's no need to even tamper with the boot sector because said malware can simply re-exploit the OS after it's booted up.

An OS has to create a trust chain to maintain it after control leaves secure boot -- Really, all we needed was the ability to flash the BIOS with the OS bootloader, and give people the option to "allow OS installs on next boot" in the boot options menu. Way fucking easier than performing some ceremonious mental masturbation encryption key entry in BIOS, that end users are BOUND to fuck up on the first try. Secure boot has no more security that putting the OS bootloader on the MOBO, and it's 100 times more complex.

"Make everything as simple as possible but not simpler." -Albert Einstein.
Secure Boot is Epic Fail on all fronts except for pushing MS's proprietary FAT file system into every OS on the planet. I won't use it, and consider UEFI harmful. Also CoreBoot Already Exists, [coreboot.org] so that's what I use even on x86 systems to boot instantly to Linux. You can mount your whole /boot/ on the MOBO if it's got enough space... Up and running in milliseconds. Screw security theater boot, there is really no valid "point" for it to exist.

Re:Sign the hibernation file (1)

recoiledsnake (879048) | about a year ago | (#42722219)

RTFA, for chrissake.

The reason behind disabling hibernate functionalities is that currently the Linux kernel doesn’t have the capability of verifying the resume image when returning from hibernation, which compromises the Secure Boot trust mode

The stupidity, confusion, lies and just plain FUD in every secure boot thread on Slashdot is just plain amazing.

fuckin w ma memry dump - by Slashalicious (-1)

decora (1710862) | about a year ago | (#42721759)

Fuckin w ma memry dump!

Fucking w ma memry dump!

All the hoes and all the dos be fucking w ma memry dump!

Up in here we got a little song we like to play!

Its called fuckin with my memry dump , fuckin with my memry dump, fucking with my memry dump

All the bboys know the punks who fucking with my memry dump

memry dump, memry dump, fucking with my memry dump

fuck fuck fuck fuck fuck fuck fuckin

with my mememememememememry

fuckin fuckin fuckin with my memry memry memry

fuckin with my memry dump, fuckin with my memry dump, fucking with my memry dump, fuckin w my memry dump

hump yeah! hump there. hump yeah! hump there.

Re:Making root not root? (0)

Anonymous Coward | about a year ago | (#42722669)

Yes or at least he's trying in all the other patch he's started.

- if (!capable(CAP_SYS_RAWIO))
+ if (!capable(CAP_SYS_RAWIO) || !capable(CAP_COMPROMISE_KERNEL))

- if (!capable(CAP_SYS_ADMIN))
+ if (!capable(CAP_SYS_ADMIN) || !capable(CAP_COMPROMISE_KERNEL))

- if (acpi_rsdp)
+ if (acpi_rsdp && capable(CAP_COMPROMISE_KERNEL))

Good first step (2)

detain (687995) | about a year ago | (#42721567)

I think this patch, while it probably wont be something we want in the kernel in the long run, at least is bringing attention to more people that we need to work on kexec and hibernation to better support the secure boot trust model. It offers a solution that does keep a system following the secure boot trust model, and once some people are able to keep a system following that model, they will to keep following the secure boot model but insist on all the old features working again. Hopefully there is enough of this type of push towards getting kexec and Hibernate improved so his patchs ultimately become obsolete.

Re:Good first step (1)

Junta (36770) | about a year ago | (#42721861)

The SecureBoot model is, frankly, a joke. As soon as you leave the realm of vendor provided OS content, it provides nearly zero protection. Hibernation can't fit into the SecureBoot model, the memory image cannot possibly be signed by the OS vendor private key. kexec could be hypothetically modified to require a signature be passed, but userspace could *look* just like something kexec would produce. Fullscreening qemu-kvm comes to mind...

Re:Good first step (1)

cryptizard (2629853) | about a year ago | (#42722903)

You could sign the hibernate image with a key that is sealed by the TPM.

Re:Good first step (1)

lingon (559576) | about a year ago | (#42723195)

Unless you passed the entire memory image trough the TPM, how are you going to accomplish this without compromising the key to the operating system?

Re:Good first step (1)

benjymouse (756774) | about a year ago | (#42723307)

Unless you passed the entire memory image trough the TPM, how are you going to accomplish this without compromising the key to the operating system?

Let's see. How about computing a hash of the memory and pass that through the TPM?

I mean, like it is *always* done when digitally signing something.

Re:Good first step (1)

lindi (634828) | about a year ago | (#42723315)

When you sign an image you actually just first calculate a hash of the image and then sign that hash. It is easy to send the hash to the TPM. The key does not need to exit the TPM at any point.

Why?? (0)

Anonymous Coward | about a year ago | (#42721577)

"... it looks like hibernation will require some clever hacking to support properly in a Restricted Boot environment."

I'm not sure why that's the case - Windows has no problem with hibernating under secure boot last I checked.

Re:Why?? (1)

norpy (1277318) | about a year ago | (#42721631)

Because presumably windows verifys the kernel image as it's loading hyberfil.sys into memory, did you not even read the summary?

The leap that TFS needs you to make is that with an unverified hybernation image you can simply remove the disk, overwrite it with an unsigned and modified kernel image and then have the hybernation process load it into memory for you from the trusted boot chain.

Re:Why?? (2)

Junta (36770) | about a year ago | (#42721887)

The practical answer to that concern would be why is the kernel so damn special. You could hijack any number of equally important processes, security wise. init, sshd, apache, any shell, web browser, whatever. Replacing kernel pages in reality isn't really that important if you have access to the entire suspend image...

Re:Why?? (1)

Rockoon (1252108) | about a year ago | (#42723147)

The practical answer to that concern would be why is the kernel so damn special.

You can argue that a particular OS is sloppy in its userland security, but its a bit odd to argue that the kernel isnt worthy of being protected because of that sloppy userland security.

Re:Why?? (3, Insightful)

lingon (559576) | about a year ago | (#42723209)

No, I think he's straight on. Secure boot stems from a broken threat model: that kernel access is extremely important. I know about userspace security, but the kernel already secures userspace without secure boot and proper privilege separation secures the kernel. Secure boot is a way of securing the system from root, which is futile (look at SELinux, for example).

This is primarily a technology for vendor lock-in. Always has been, always will be.

Re:Why?? (1)

tlhIngan (30335) | about a year ago | (#42723159)

The practical answer to that concern would be why is the kernel so damn special. You could hijack any number of equally important processes, security wise. init, sshd, apache, any shell, web browser, whatever. Replacing kernel pages in reality isn't really that important if you have access to the entire suspend image...

Because the kernel has complete control. Sure you can compromise ssh/init, but those are userland processes and any other userland process can verify those images are what they should be.

But breaking into the kernel and injecting your rootkit that way means no userland process can verify that the binaries running are NOT compromised. Plus, the kernel has hooks into every process so it can do things that no process itself can do without kernel assistance. So if you wanted a key logger, the kernel can hide it very well.

It's a good point - Linux should be embracing trusted boot technology for higher security operations - we already know of BIOS based OS attacks. Heck, there's one that legitimately installs itself on every hard drive running Windows - if you buy a PC with support for LoJack and have it install itself into the BIOS, everytime the BIOS initializes LoJack, it checks for its files. If not, it hooks itself into Windows so it auto-installs on a new hard drive for computer tracking. Given the vulnerabilities in that module, or other BIOSes, it's possible for a Linux system to be compromised and no one noticing.

Sure, it was invented by Microsoft, and Microsoft (on x86) enforces the user's ability to do an untrusted boot. But Linux has signed bootloaders which allow the user to boot their own self-signed kernels. Given this, why shouldn't Linux have the ability to continue a chain of trust?

It's only a matter of time before some smartass designs some Stuxnet like thing that impacts Linux systems. Maybe most users don't care, but having a server that doesn't boot because the kernel failed the signature check might be necessary for security purposes. Hell, if your financial systems run Linux (including credit card processing systems...)... wouldn't it be nice as an admin to know their ssytems haven't been compromised surreptitiously?

The microsoft problem (0)

Anonymous Coward | about a year ago | (#42721609)

Some of you ignorant little cunts are still giving them money. Fuck you.

Re:The microsoft problem (1)

black3d (1648913) | about a year ago | (#42722373)

I promise I'll stop doing so as soon as someone produces a more accessible user-friendly OS and a more feature-complete Office suite.. If you're not actively contributing to either of these then you're not helping make the problem go away.

Re:The microsoft problem (0)

Anonymous Coward | about a year ago | (#42722431)

Yeah?

And what do you contribute? That might make up for your being part of the problem by giving that collection of dicks more money.

Re:The microsoft problem (1)

black3d (1648913) | about a year ago | (#42722437)

I'm not the one complaining. As I said, provide me with an alternative and I'll stop giving them money. Otherwise it's really just a lot of hot air and noise.

Re:The microsoft problem (0)

Anonymous Coward | about a year ago | (#42722559)

I dont have time to make someone elses dream come true, I do give people money that lets me get shit done

meh (0)

magic maverick (2615475) | about a year ago | (#42721619)

Hibernate doesn't work with the latest Ubuntu versions anyway. 1) they turned it off 'cause it might not work, 2) it doesn't work. It works fine with Debian though on the same computer.
I think I might switch to Mint or something.

So when I install Linux... (-1)

Anonymous Coward | about a year ago | (#42721643)

..I lose basic features like hibernation?

Typical.

Fuck Secure Boot (5, Insightful)

Anonymous Coward | about a year ago | (#42721671)

It's my goddamn computer, my goddamn hardware, and it's MINE. I will run any fucking operating system I goddamn well please on it, and if Microsoft doesn't like that, they can FUCK THEMSELVES right in the GODDAMN EAR.

Re:Fuck Secure Boot (5, Insightful)

UltraZelda64 (2309504) | about a year ago | (#42722059)

Why the downmods? Yeah, maybe the AC was just trolling, but his overall point I actually agree with. If anything, it should've been modded +1 "Funny" for the "fuck themselves in the god damn ear" part.

Re:Fuck Secure Boot (0)

girlintraining (1395911) | about a year ago | (#42722833)

Since Slashdot's purchase, there's been numerous signs of a "shift" in moderation, of which the only two explanations are an external force (say, new management) or a shift in the opinions and attitudes of the entire userbase.

You can guess what my money's on.

Re:Fuck Secure Boot (1)

recoiledsnake (879048) | about a year ago | (#42722123)

It's my goddamn computer, my goddamn hardware, and it's MINE. I will run any fucking operating system I goddamn well please on it, and if Microsoft doesn't like that, they can FUCK THEMSELVES right in the GODDAMN EAR.

Or you can just disable it...

Re:Fuck Secure Boot (3, Funny)

grcumb (781340) | about a year ago | (#42723201)

It's my goddamn computer, my goddamn hardware, and it's MINE. I will run any fucking operating system I goddamn well please on it, and if Microsoft doesn't like that, they can FUCK THEMSELVES right in the GODDAMN EAR.

Or you can just disable it...

What, and miss the chance of seeing Ballmer fuck himself in the goddam ear?

Shyeah....

Re:Fuck Secure Boot (2)

blueg3 (192743) | about a year ago | (#42722345)

It's only yours if you buy it. I suggest not buying hardware with Secure Boot, if it bothers you so much. But then, all x86 hardware with Secure Boot is required to have the option to disable that feature. So, you could take that route, too.

Re:Fuck Secure Boot (0)

0123456 (636235) | about a year ago | (#42722385)

But then, all x86 hardware with Secure Boot is required to have the option to disable that feature.

Until Windows 9, anyway.

'Microsoft Boot' is probably the biggest threat to Linux right now, and I'm amazed that anyone not paid by Microsoft would ever defend it.

Re:Fuck Secure Boot (0)

Anonymous Coward | about a year ago | (#42722529)

You know you make this place absolutely disgusting when you accuse anyone who disagrees with you of being a paid shill, right?

Re:Fuck Secure Boot (1)

blueg3 (192743) | about a year ago | (#42722885)

I hadn't heard of Microsoft's involvement at all until the article on Slashdot that they were starting to mandate UEFI Secure Boot.

As far as I know, that UEFI standard is older than their involvement. Older still is repeated calls in the security research community for some kind of signed boot process to enable a ground-up signed system. The major motivations for which were to create more reliable antimalware and to do remote attestation. (More reliable antimalware meaning anitmalware that can prove that every layer below it isn't compromised. It's basically impossible to detect sufficiently advanced malware that's running at a lower level than you are.) That's where I remember it from. So I don't buy that it's a scheme ginned up by Microsoft to do something that it's currently not actually being used to do.

I'm sure there are all sorts of terrible things that Secure Boot can be used to accomplish if you wrap the tinfoil around your head tightly enough. I'll even admit that some marketing guy in Microsoft may well end up getting them to use it for one or more of those things. But Secure Boot is actually useful, so I'll refrain from complaining about it until Microsoft actually does something evil.

Why are you wasting time? (0)

Anonymous Coward | about a year ago | (#42721703)

Why the fuck is SecureBoot even a priority AT ALL?

This shit is not going to go away if you play ball with Microsoft, which is precisely what Linux is expending valuable resources doing.

SecureBoot is not an important feature. It doesn't make your computer work better, or faster, or in a more stable fashion. Nobody needs or wants it. I cannot for the life of me understand why Linux is so fucking obsessed with supporting it properly, as if it's somehow going to improve Linux market share in the future. If Linux ever threatens Windows in any meaningful way, Microsoft would just make up a bullshit reason to yank the signing certs and kill everything that way instead (and by then, you can be damned well sure that SecureBoot will be MANDATORY on all x86 systems- why? Because everyone went along with it, that's why).

I could have sworn the entire community was up in arms about this crap, and how important it was to educate users about it.

You want to educate users about SecureBoot?

Don't support it. Collectively tell them why they need to go into their UEFI config utility and turn it off. Tell them if they can't do that, then they should return their computer as defective- because it obviously is.

Playing ball with Microsoft is the stupidest, most fucking boneheaded thing I have heard from the Linux community in a very, very long time. If I were Linus, I'd grow a pair of balls and yank ALL traces of SecureBoot support in the kernel, then tell Microsoft and all their UEFI buddies to fuck off. Then maybe the hardware manufactures would realize just how big of a mess they've gotten themselves into, and reverse course on SecureBoot for x86. But that's never going to happen because everyone is just acting like it's life right now and that's something they need to support. WTF?

because linux has always run on shit hardware (1)

decora (1710862) | about a year ago | (#42721773)

it was the same issue with 'winmodems' back in the 90s. yeah its shit, yeah its stupid, but its whats on sale at Best Buy and what teenagers have when they go to college and learn what "GCC" is.

Re:Why are you wasting time? (1)

stafil (1220982) | about a year ago | (#42721881)

(and by then, you can be damned well sure that SecureBoot will be MANDATORY on all x86 systems- why? Because everyone went along with it, that's why)

Actually it's already kind of mandatory in all new systems, because MS made it a requirement for a system in order to bear the Windows 8-certified logo.

So yeah, if you are a company and want your systems bearing the Win8 certified logo then you have to have Secure Boot enabled and there is absolutely nothing Linux community can do about it.

the logo is weird anyway (-1)

Anonymous Coward | about a year ago | (#42722073)

Why would a company want a Windows 8 logo? I've never seen such a logo on an Apple product, yet Apple's business is doing just fine.

Re:the logo is weird anyway (0)

Anonymous Coward | about a year ago | (#42722403)

Why would a company want a Windows 8 logo?

I don't know about today, but in the past, if you had a Windows logo on the box you got a discount from Microsoft on Windows.This is why all the hardware drivers I worked on had to be Microsoft-approved to ensure we could get big OEM wins.

Re:the logo is weird anyway (0)

Anonymous Coward | about a year ago | (#42722475)

Why would a company want a Windows 8 logo?

I don't know about today, but in the past, if you had a Windows logo on the box you got a discount from Microsoft on Windows.

Additionally, vendors who don't/won't produce "label-compliant" products are less likely to receive "marketing assistance" payments from Microsoft.

Conceptually.. (5, Interesting)

Junta (36770) | about a year ago | (#42721719)

What distinguishes hibernated memory image from, say, an initrd? Practically speaking, a distro has to allow for initrds to boot that aren't signed by the distribution. In fact, what about booting *any* filesystem? Some may suggest that the goal would be to have every binary signed, but what about end-user maintained scripts and config files? SecureBoot as currently defined only about the OS provider signing what they provide and that leaves a whole lot of area for malicious content outside that scope. It's of little comfort that you have assurance that you are running the correct sshd if, for example, you have malicious ssh_config and malicious authorized_keys.

Re:Conceptually.. (0)

Anonymous Coward | about a year ago | (#42721907)

I don't think you grasp the concept.

Code in user land really cannot inter fear with the kernel.

Perhaps root can blow away the kernel and the modules, or firmware, but CANNOT modify them without breaking the cryptographic chain of trust.

Little much matters what happens in the user space, as that stuff does not impact the trust that occurs in the kernel space.
That being said there are plenty of tools to do the same thing in userspace, the kernel audit daemon for one, and now with the kernel protected we can even trust the audit daemon. Routinely verifying the hash of binaries on the system, which most package managers do.... keeping those signatures on another system...

Even kernel drivers that do DMA are suspect now, especially non-signed drivers with binary blobs.... Just wait until the nVidia drivers stop working, that is when people will go all-fuck-retarded on secureboot, especially now gaming is migrating away from windows8.

How can I tell which hardware uses secure boot? (1)

aliquis (678370) | about a year ago | (#42721959)

And what is it needed for? Are there any disadvantages from not having it? Will there be any? What are the advantages?

I want to get a new machine. Will more or less secure boot affect the ability to run OS X?

Feel free to answer, whoever answer doesn't have to answer in detail if they don't want to. And no I won't try to google for it all atm.

Re:Conceptually.. (5, Insightful)

mjg59 (864833) | about a year ago | (#42722001)

The kernel can execute ring 0 instructions. Your initrd can't. The difference is that you could construct an appropriately modified hibernation image that booted an arbitrary kernel - or even an entirely separate OS. In that scenario, your kernel is effectively a new bootloader, except unlike the signed bootloaders it'll happily boot an entirely unsigned OS. That's unlikely to end well.

But, conceptually, you're right. Secure Boot doesn't magically make a system secure, but it *is* a vital part of system security - if you can't trust your kernel, any other security you attempt to build is pretty much pointless.

Re:Conceptually.. (0)

Anonymous Coward | about a year ago | (#42723215)

If the most relevant difference between a compromised "secure boot" system and a compromised "non-secure boot" system is that the former can't boot an unauthorised image of another OS, then this makes me think that "secure boot" is more about preventing the piracy of Windows than it is about adding security to a real-world Linux installation (where the mere presence of "root" nullifies any advantage of "secure boot").

Re:Conceptually.. (1)

mjg59 (864833) | about a year ago | (#42723233)

If it were an anti-piracy measure then there wouldn't be a requirement for you to be able to disable it.

Re:Conceptually.. (1)

Miamicanes (730264) | about a year ago | (#42723311)

> real-world Linux installation (where the mere presence of "root" nullifies any advantage of "secure boot").

You haven't had the misfortune of experiencing Linux on non-x86/AMD64 platforms, I see. Out in the ARM hinterlands, things aren't nearly as friendly. TI, in particular, has some UNBELIEVABLY nasty features baked into their SoC (used by Motorola for Android phones, among other things) that allow the manufacturer to dictate what memory, flash, and i/o ports you can read or modify based upon where the code is executing from... as well as enforce mandatory encryption for flash, so even if you physically desoldered the chips and programmed them independently of the device before soldering them back in, they wouldn't work. There are things that code executing from RAM (or some range of memory addresses) on a Motorola Photon/Electrify/Atrix2 is simply NOT ALLOWED TO DO, and those restrictions are enforced by the SoC and its integrated peripherals themselves.

In other words, on an ARM platform, even ROOT can be shackled and chained into obedience to our corporate overlord masters.

The problem isn't with the hibernation (2)

sethstorm (512897) | about a year ago | (#42721899)

Secureboot is the problem and disabling it(or getting rid of the device for a freer one) is the solution.

Re:The problem isn't with the hibernation (1)

UltraZelda64 (2309504) | about a year ago | (#42722145)

Unfortunately, if you have a Windows 8/RT ARM-based system, disabling Secure Boot cannot be done... so that's not always a solution. Just when we finally get ARM systems useful as general purpose computers to replace x86 instead of being limited to using ARM in pathetic special-purpose systems like routers and cell phones, Microsoft swoops down and fucks everything up. As usual, Microsoft is here using their abusive powers to wreck the day.

Re:The problem isn't with the hibernation (0)

Anonymous Coward | about a year ago | (#42723291)

You're a fucking idiot. We want secure boot. We don't want the lock in.

All this bullshit and we still have problems (1)

kawabago (551139) | about a year ago | (#42722193)

Secure boot isn't. There is no point in hacking our way into Secure boot because it isn't secure, period. There is always a way around every security design and hobbling the industry with a proprietary technology isn't going to help anyone but incumbent large players. Secure Boot is nothing more than an attempt by Microsoft and other entrenched players to exclude smaller companies. The only secure idea at Microsoft is Linux!

It doesn't matter... (1)

Marcion (876801) | about a year ago | (#42722287)

... because hibernate is pointless and never reliably works anyway. Set everything to autosave and get a distro that boots up quickly.

Re:It doesn't matter... (1)

loufoque (1400831) | about a year ago | (#42722527)

While neither suspend nor hibernation work reliably (in particular with wifi, bluetooth, and usb mass storage devices), I still use suspend exclusively instead of turning off my computer.
Whatever application you had open is still open in the exact same state, and that's practical.

Re:It doesn't matter... (0)

Anonymous Coward | about a year ago | (#42722727)

I always use hibernate and I've never had any problems. Furthermore, waking up from hibernation is really fast, much faster than even the quickest usable distro.

Re:It doesn't matter... (0)

Anonymous Coward | about a year ago | (#42722785)

Maybe in your world, but in my world, hibernate works every day 100% reliably (actually usually multiple times per day). Hibernate has been working very reliably on Linux for years. --You are using Linux, aren't you?

Waste of processing power and disk space (0)

Anonymous Coward | about a year ago | (#42722331)

All these security patches are just a waste of disk space. Lots of Bullshit. We should have the option to disable that crap to keep our code running as fast as possible in environments that can't be compromised, or just ones where we don't care if they are. eg. a gaming box.

Restricted Boot Expands M$ Monopoly (-1)

Anonymous Coward | about a year ago | (#42722339)

It is not shocking to see GNU/Linux failing after using Restricted Boot. After all M$ created Restricted Boot [techrights.org] to be defective by design. ACPI [slashdot.org] , M$'s Power Management Poison, is the other culprit in this as it too was created so M$ could keep their monopoly. In reality M$ is running scared as Vista 8 [techrights.org] is failing worse than even Vista 7 just as Vista 7 was more of a fail than Vista. M$ is even getting paid shills such as Oprah and she doesn't even use Vista 8. As Windoze and M$ continue to die they will keep paying shills and astroturfers to give false endorsements for their products. It is past time for the governments of the world to each put their foot down and stand up to M$ and punish them for their illegal behavior.

--
Friends don't help friends install M$ junk
Friends do assist M$ addicted friends in committing suicide.

reply (-1)

Anonymous Coward | about a year ago | (#42722457)

Shanghai Shunky Machinery Co.,ltd is a famous manufacturer of crushing and screening equipments in China. We provide our customers complete crushing plant, including cone crusher, jaw crusher, impact crusher, VSI sand making machine, mobile crusher and vibrating screen. What we provide is not just the high value-added products, but also the first class service team and problems solution suggestions. Our crushers are widely used in the fundamental construction projects. The complete crushing plants are exported to Russia, Mongolia, middle Asia, Africa and other regions around the world.
http://www.mcrushingplant.com
http://www.crusher007.com
http://www.sand-making-machine.com
http://www.china-impact-crusher.com
http://www.cnshunky.com
http://www.bestssj.com
http://www.shunkyen.com
http://www.crusheren.com
http://www.crusher02.com
http://www.portablecrusherplant.net
http://www.csconecrusher.com

Hybernation worked? (0)

Anonymous Coward | about a year ago | (#42722479)

Who knew?

Yes! It's a secure boot patch! (0)

Anonymous Coward | about a year ago | (#42722991)

Any kernel that cannot boot is more secure than one that can...so the patch works! I hope it gets accepted as a security fix for kexec.

Butterfly effect. (1)

formfeed (703859) | about a year ago | (#42723045)

No hibernation means slow boot and slow boot will make linux more cumbersome for new users. If ubuntu (a.k.a. linux) becomes cumbersome for new users they will tell their friends how sucky linux is. And then their friends, despite of unity, will not switch to ubulinux.

I think, I don't have to spell out the possible horrific consequence: 2013 might not be the year of the linux computer.

SecureBoot is a modern version of vendor lockin (3, Informative)

Damouze (766305) | about a year ago | (#42723069)

SecureBoot is nothing more than a modern kind of vendor lock-in, so why support it at all? Haven't the FSS and OSS communities by now gained enough leverage on their own to stimulate the development of software in the direction it should go, namely that essential software, like an OS, a BIOS or a piece of firmware, should be free (in the FSS sense) for use by anyone?

By accepting and even supporting suspicious software and business models such as SecureBoot, aren't the FSS and OSS communities more or less digging their own graves because Microsoft - who admittedly has changed a lot for the better the last few years - owns the very keys their software relies on for proper functioning?

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...