New Secure Boot Patches Break Hibernation

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.

Comments

Why is this a story again?

[Anonymous Coward]

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.

Re:Why is this a story again?

[Anonymous Coward]

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

Re:Why is this a story again?

[Lakitu]

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:Why is this a story again?

[Anonymous Coward]

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?

[Curate]

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

Re:Why is this a story again?

[Anonymous Coward]

"Java and C# are basically equivalent."

        Guess nausea loves company.

Re:Why is this a story again?

[jones_supa]

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

Maybe that would exactly be the first spark. "Why the hell would you do that?!? They are basically equivalent!!" Then some passionate Java or C# coder would point out that "they are FAR from equivalent, just see how this garbage collection feature is implemented much more nicely..."

Meh. Hybernation is overrated

[ravenswood1000]

Who needs it anyhow, hehehe.

Re:Meh. Hybernation is overrated

[Anonymous Coward]

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

[Noughmad]

At least he didn't call it $ecure Boot.

Re:Meh. Hybernation is overrated

[KiloByte]

No one but Microsoft has any need for it. For starters, it doesn't serve its advertised purpose -- if it did, we'd see drivers getting blacklisted for ring 0 holes left and right, and I'm not aware of Microsoft blacklisting a single one. So it's not about preventing those eevil haxors from haxoring your machine. What is it for, then? Making sure competition to Windows never goes mainstream.

Making root not root?

[Myria]

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?

[Rockoon]

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.

Re:Making root not root?

[Anonymous Coward]

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))

Re:Making root not root?

[citizenr]

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?

This is the precise point of TPM - it takes away control over the computer from user/admin. "Your" computer is not yours anymore.

Good first step

[detain]

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

[Junta]

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

[cryptizard]

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

Re:Good first step

[lingon]

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

[benjymouse]

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

[lindi]

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.

Certificates can be revoked

[tepples]

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

[benjymouse]

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

[Rockoon]

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

[Trogre]

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

[vux984]

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

[recoiledsnake]

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

[Nerdfest]

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

[Smauler]

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

[Trogre]

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:
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

[shutdown -p now]

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.

Re:Certificates can be revoked

[complete loony]

AFAIK only boot loaders like shim have actually been signed by Microsoft. But, you may be right...

Re:Certificates can be revoked

[exomondo]

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

[Anonymous Coward]

Dream on my friend, just dream on...

Re:Certificates can be revoked

[SuricouRaven]

It's not just about the stickers. It's about the OEM volume deals that come with the stickers. Lose the sticker, and the per-unit licensing cost shoots up by a hundred dollars or so, in an industry where the margin is less than that. As it's not practical to mass-market a machine running anything other than Windows (Imagine the return rate by uneducated users - most of them don't even know what an operating system is), that means that when MS demands something the OEMs have no option but to comply.

Re:Certificates can be revoked

[cinky]

While I don't use linux on desktop anymore I still check linux compatibility on all the HW I buy - you never know when you'll need TRK or backtrack. Not to mention if steam for linux/steam box kicks game producers into providing linux ports I might even return to linux desktop some day (in the time of lots of ram and multi-core CPUs it's not such a problem to run windows in a VM for win-only stuff).

Re:Certificates can be revoked

[Anne Thwacks]

Lose the sticker, and the per-unit licensing cost shoots up by a hundred dollars or so,

For a (near) monopoly to do that is a clear breach of EU competition law. Expect someone to realise this will solve Greece's debt problems very soon.

Re:Certificates can be revoked

[benjymouse]

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.

Yes they do. The bootload'ers used for booting Linux are signed by Microsoft. The Linux community *could* work with vendors do have a "Linux" certificate installed in the firmware which would allow other boot-loaders to boot. But given the number of vendors that has been deemed impractical. Instead Linux distros (and Matthew Garett) have created boot loaders/shims which are chain-loaded from Microsofts boot-loader. As such they need a MS key.

Presumably MS has a number of restrictions on how such a boot loader works. For instance, they probably require that the user is being made aware of the fact that they boot a non-Windows OS. If they didn't (and allowed silent boots) a rootkit could simply install itself as a chained, silent OS and then boot Windows from within a VM. A rootkit.

Re:Certificates can be revoked

[SuricouRaven]

The EU already chewed Microsoft up over antitrust once.

Re:Certificates can be revoked

[santosh.k83]

My thoughts exactly. How in the world has Microsoft, one single software firm, managed to usurp power enough to dictate to hardware manufacturers, to users, to institutions and soon enough even to governments is shocking. I for one would be willing to support hardware makers with a slightly pricier hardware if it meant that by doing so, they could get out from MS's unethical monopoly once and for all. Microsoft should concentrate on making compelling software that'd naturally motivate people to go out and buy it, and not worm itself in everywhere like a plague using every kind of legal loophole and arm-twisting there is. They should be alarmed that practically nobody respects them as a company, even though out of sheer inertia the vast majority still continue to use their products. And no, Bill Gates's admirable charity work doesn't condone MS's behaviour even a bit. Ultimately change is in the hands of us users, but I hope change comes before it becomes too late too change due to an unholy confluence of laws, politicians, business, police all colluding together. The signs are clear that all over the world they are willing to happily do so; are we willing to collude together to save the open-mindedness that the Renaissance ushered in, or are we headed towards a second, 'scientific' dark age?

Re:Certificates can be revoked

[hairyfeet]

But again its total flamebait as there has been ZERO word or indication to state a position by MSFT one way or another when it comes to the issue.

Personally I think old Ballmer has too damned much on his plate to give a shit about Linux one way or another ATM, he has pretty much bet the farm as well as his own rep (for what little that is worth) on a strategy that might as well be written in crayon on the back of a napkin, namely "Become Apple" which he is learning, just as HP and RIM learned before him, that such a goal is a hell of a lot easier said than done.

So let's wait until someone has actually done something to be all pissy about, yes? With the company fighting the OEMs and trying to convince a public that honestly doesn't give a fuck that slapping a paint job on a Pinto means it can compete with Porsche I truly believe that Ballmer and Co isn't paying a lick of attention to Linux, hell they would probably be happy if Linux hackers were to make any decent number of WinTabs sales as they have had cut their order for Surface units in half to keep from ending up with a warehouse full of the damned things.

BTW as a final note if everyone wants a reason for Linux guys to get their panties in a twist I'll be happy to give you a topic that will do just that: Everyone is cheering the flaming out of Ballmer's folly but why isn't anybody speaking up when it looks like Google is gonna be just as douchey as MSFT and it some ways even worse? Have you SEEN the new Acer ChromeBook? You have an X86 CPU, hard drive, RAM, etc that are so bog standard it hurts yet is so locked down you can't even run Linux X86 on the damned thing! Even MSFT specified that SecureBoot was to be able to be turned off on X86 so you can take any new X86 Windows machine and be booting any standard Linux LiveCD/USB in moments but the ONLY way to do so with a Chromebook is to pour in a page and a half of CLI gobbledygook and do a lot of finger crossing as you have to wipe the hard drive and nobody knows if doing so will void the warranty or not!

So you want something to get pissed over there ya go, if Google were to take over from MSFT tomorrow things would be WORSE not better. Personally I think if everyone doesn't stand up and have a raging shitfit the future is gonna be game consoles all the way down, you can give up on DIY or on having X86 be a general purpose platform as its gonna be as tightly locked down and controlled as any cellphone and will be just as worthless when the corporate owners abandon support for a model.

While I'm all for getting rid of the MSFT monopoly on X86 I don't want to do so at the cost of what made X86 great in the first place.

Re:Certificates can be revoked

[hairyfeet]

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'.

Or those people along with anyone else who actually cares about open hardware could just put their money where their mouths are and buy AMD who is switching to Coreboot which is a FOSS BIOS/UEFI replacement. After all no need to "flash an open BIOS" if you already have one.

Re:Certificates can be revoked

[Anonymous Coward]

For now...

If we ignore the risk until it we are locked out, it will be too late to do anything to stop it.

Re:Certificates can be revoked

[tepples]

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.

If you're willing to give up all amateur games, you could always switch to a console.

Re:Certificates can be revoked

[exomondo]

Yes they do. The bootload'ers used for booting Linux are signed by Microsoft.

Wrong, they are signed by Verisign with Microsoft's key, that's the whole point, so that motherboards with only Microsoft's key installed can boot into other signed OSes. If Microsoft revokes that key then they revoke the ability to boot their own OS.

Re:Certificates can be revoked

[exomondo]

I take it you simply don't understand SecureBoot, if they revoke the certificate they remove the ability to boot Windows...duh.

Re:Certificates can be revoked

[Bengie]

Secure boot is an open standard that was created by Intel without Microsoft because end users, like IT/admins, wanted it. Microsoft only decided to make use of an existing standard and later gave feedback.

If you don't like secure boot, disable it, or better yet, pressure hardware manufactures to include a cert that is managed by the OpenSource community. You could always just load your own cert as most UEFI setups support that because Microsoft requires the ability to manually load certs in order to be a certified PC Win8 machine.

Save your time and go complain about MS's requirements of Secure Boot on ARM, as MS requires a closed system for that platform.

Re:Certificates can be revoked

[Anonymous Coward]

Ahh, another day, another reason to be smug^W^Wlove AMD.

Seriously though, I love AMD, not for their performance, as much as for their support of consumer interests.

Why??

[Anonymous Coward]

"... 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??

[norpy]

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??

[Junta]

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??

[Rockoon]

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??

[tlhIngan]

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?

Re:Why??

[lingon]

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??

[benjymouse]

No, I think he's straight on. Secure boot stems from a broken threat model: that kernel access is extremely important.

Talk to kernel.org and linuxfoundation.org. I think they'll be sympathetic to you viewpoint that kernel security really is no big deal. Or not.

Secure boot is a way to prevent malicious code from permanently infecting a system and to prevent infection through manipulating OS files on disk. Think rootkit. With a secure boot regime in place, linuxfoundation and kernel.org could have been spared the embarrassment of being root'ed for almost a month without even noticing (and only noticing by a coincidence).

On Windows it has gotten very difficult to infect the kernel permanently, especially on 64 bit where the kernel is loaded from MS signed cabinets and all drivers must be digitally signed to be loaded. The bad guys have now resorted to a technique where they instead boot the system to a small VM which then boots Windows. When Windows is up and running the VM will then memory patch the "guest" Windows to inject malicious code again.

Secure Boot closes that vector. It may not prevent malicious code which has somehow gotten kernel access from modifying the persistent image, but it does mean that the system will refuse to boot should that happen and you'll be alerted to the fact that somethings fishy ig going on.

I know about userspace security, but the kernel already secures userspace without secure boot and proper privilege separation secures the kernel.

kernel.org, linuxfoundation.org and several other sites were root'ed. They suspected that the attackers somehow compromised the system of one of the users and used his access to the systems. However, they must have leveraged a privilege escalation vulnerability, otherwise there is no explanation for how they can go from accessing systems as users to installing rootkits.

Privilege escalation and kernel vulnerabilities happen. There is nothing wrong with security in depth.

Re:Why??

[benjymouse]

Your comments about kernel control and security is spot on. I don't get the "we already got enough security" argument at all. It's like the mantra that Linux somehow is inherently the most secure OS imaginable has gotten the best of some of the community and they actually started believing that there's nothing more to do.

Sure, it was invented by Microsoft, and Microsoft (on x86) enforces the user's ability to do an untrusted boot.

Not sure it was invented by Microsoft. It was specified by UEFI and certainly *pushed* by Microsoft. Parts of the Linux community in an effort to paint everything MS does as inherently bad tried to label Secure Boot bad and then let Microsoft own it. Fortunately that has largely failed.

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?

Given that Linux is being trusted with large part of our infrastructure I'd say that Linux pretty damn well *must* guarantee a chain of trust. I do not want my bank, government, SSL issuers etc. to be operating compromised systems. As this story illustrates there is still some way to go. When Windows boots it *only* trusts MS signed cabinet files where both executable code, resources and configuration resides. I believe that there's also a weakness in Linux where the configuration can be compromised outside the signing support of some distros.

Re:Why??

[Anonymous Coward]

"They suspected that the attackers somehow compromised the system of one of the users and used his access to the systems."

    I heard something about the lazy idiot between the screen and the chair. Secure boot doesn't and can't fix stupid.

Re:Why??

[Anonymous Coward]

"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?"

        Because Microsoft can't be trusted. They've proven it time after time. And they certainly can't be trusted to load a competing OS. What happens when Microsoft doesn't have to support XP and Vista any longer and says/pays/both to OEMs "You know that option to turn off secure boot, forget that." "Oh yea, activate the code to lock all internet connected secure boot computers to secure only". Many OEMs already make getting to the secure boot off option as difficult as possible, likely at Microsoft's bidding. Secure boot is a vendor lock-in toy and that's it. Otherwise, Microsoft could have done this ten years ago. Oh that's right, they might have been cutting their throats with the convicted monopolist status they had.

Re:Why??

[benjymouse]

"They suspected that the attackers somehow compromised the system of one of the users and used his access to the systems."

    I heard something about the lazy idiot between the screen and the chair. Secure boot doesn't and can't fix stupid.

So when a system is compromised for most of a month, potentially putting users who download binaries at risk and certainly putting them at risk of being served malware coctails, you are ok with the admins not discovering it because you blame the user whose account was compromised?

How about blaming Linux security for attackers being able to root multiple systems from a user account.

And do you feel comfortable that just because you can blame a user it is ok that the admins did not notice anything was wrong before some of the malware emitted error messages which should not come from a server system?

Secure Boot could have prevented the compromise from going on for so long. Who is stupid, really?

Re:Why??

[Anonymous Coward]

Your last phrase is false.
Any bug that would allow code to execute through the user->admin barrier would allow code to execute through Any barrier with a similar bug, such as the admin->boot layer.

Who the hell downloads binaries as a (non-windows) user? Chmod +x should be a giant warning flag causing loss of login privileges and a meeting with their supervisor.

If your user is already able to execute arbitrary code on your system THERE IS YOUR PROBLEM.

lm-sensors

[tepples]

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

You could try setting up lm-sensors. Or is your motherboard not supported?

Re:lm-sensors

[jones_supa]

You could try setting up lm-sensors. Or is your motherboard not supported?

So that you could monitor in how much pain it is in?

The microsoft problem

[Anonymous Coward]

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

Re:The microsoft problem

[black3d]

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

[Anonymous Coward]

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

[black3d]

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

[Anonymous Coward]

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

Re:The microsoft problem

[Anonymous Coward]

"a more accessible user-friendly OS"

              Does it have to have sex with you too? there's already more accessible user friendly OSes out there. Stop whining because it's not a windows clone.

"and a more feature-complete Office suite.."

            How many features do you really use? Feature complete is bullshit, as long as it can do what is actually needed then it's good. There's lots of alternatives but most don't work exactly like MSO but achieve similar if not the same results and some thing better results. See stop whining.

And yes, I hear It doesn't work like windows/office all the time. After I remind them that they had to learn them at one time and just sit down and look at the manual, and do it. I swear it's probably the first time they'd done anything outside their career's information envelope in decades, ah drones.

Re:The microsoft problem

[david_thornley]

How about the ability of an OS to use all Windows-compatible software, and the ability to get the computer without OS as cheaply and conveniently as one with Windows?

For many Windows-compatible products, I can do as well or better on Linux (one example: the kernel). For many, there is no satisfactory FLOSS equivalent. This is particularly true of a lot of niche products, which can be crucial to many businesses. Also, many people need something Microsoft-Office-compatible, and there is no such thing. Other office suites might suit them better for their own work, but they need to exchange Word documents with others.

If I need a computer now, and go to a store, I've got a choice of Windows, and maybe MacOSX. I haven't found a local store that stocks Linux or no-OS computers. If I shop on line, I am a lot more likely to get what I specifically want for at least as low a price if I buy it with Windows, wipe it, and install the Linux distro of my choice. I'm not allergic to putting my own desktops together out of components, but I'm not assembling my own laptop.

meh

[magic maverick]

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.

Re:meh

[jones_supa]

I found it odd that they disabled it. I have re-enabled it in all of my Ubuntu systems and it works perfectly. There's much worse bugs in Ubuntu than hibernation support.

Sign the hibernation file

[tepples]

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

[Rockoon]

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

[recoiledsnake]

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.

Re:Sign the hibernation file

[0123456]

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

[Anonymous Coward]

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

[VortexCortex]

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, 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

[Anonymous Coward]

"DRM is to promote sales through reducing piracy "

      No, the point of DRM is to increase profits by removing a potential threat to sales. The point of secure boot is potentially lock hardware to the operating system. The chain of proof is just a selling tactic at best but irrelevant as there are a myriad of ways to compromise a system for those with the will to do so. It's more effective as a wedge to eventually control hardware manufacture. Remember this kind of behavior wouldn't be new for Microsoft.

Re:Sign the hibernation file

[KingMotley]

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.

I think you are on to something there. Just a few minor glitches and you can be a millionaire! Like, how are you going to send your hashed memory dump over to verisign so they can sign your memory dump and send it back to you after reviewing it. And how do you get verisign to do that in less than 3 months? Hibernation is kind of pointless when it takes 8 hours to send the image over the internet, wait 3 months for it to get signed and another 2-3 hours for you to redownload it. That's got to be the slowest hibernation ever.

Other than that, awesome idea.

Re:Sign the hibernation file

[Richard_at_work]

Regardless of the SecureBoot issue, the loading of an unverified resume image is a security issue that should be resolved anyway...

Re:Sign the hibernation file

[Anonymous Coward]

For as long as the owner of a machine with DRM lacks the keys to the machine, the point of DRM is for the vendor to control your computer. Their justification for this is to control society's freedom to share knowledge in order to collect a rent for their knowledge (books, movies, music, images, games). Normally, the user who buys the machine is forbidden to control it, they must first get explicit permission from the DRM keyholders to control their own machine. Society cannot live in freedom when society accepts this form of subjugation. QED it is not hyperbolic to assert that the point of DRM is to control society.

In the case of UEFI secure boot, most implementations of it permit the user to control their computer. The mechanics of controlling the secure boot mechanism are not odious so therefore, it would be hyperbole to assert vendor lock-in as the purpose of secure boot.

Re:Sign the hibernation file

[DarkOx]

No its really not. If you can tamper with the resume image it basically means you had physical access to the machine, or something equivalent if the machine is a VM.

Full disk encryption available on Linux via LUKS can protect the integrity of the resume image. So there is no reason, none, nadda, for the kernel to have some second method to verify the integrity of the suspend to disk image.

If you are not running FDE than anytime a system has been outside of your physical control it should be assumed to be compromised anyway.

Re:Sign the hibernation file

[DarkOx]

Replying to my own post. Okay there is one reason to have some secondary method. That reason would be to prevent the lawful owner of said machine who controls the disk encryption keys from altering the image. Which I don't consider to be a legitimate reason. Its my machine I should be able to load anything into its memory I like; by any method I can make work.

Re:Sign the hibernation file

[sFurbo]

here's no need to even tamper with the boot sector because said malware can simply re-exploit the OS after it's booted up.

I think the point of secure boot is that today, once the system is rooted, you can install a hypervisor and own the system forever. Repairing the original hole does not save an already rooted system. With secure boot, if the hole is repaired, the system cannot be re-rooted, so any exploits that used that hole are now gone.

Re:Sign the hibernation file

[tepples]

From the article:

currently the Linux kernel doesn’t have the capability of verifying the resume image when returning from hibernation

I suggested how to add such "capability of verifying":

perhaps one solution is to sign the [resume image] with a key stored in the TPM.

I'd be willing to explain this suggestion in more detail. What questions do you have?

Re:Sign the hibernation file

[tepples]

With secure boot, if the hole is repaired, the system cannot be re-rooted, so any exploits that used that hole are now gone.

And if hibernation is the only hole, it is repaired whenever the computer fully restarts.

Re:Sign the hibernation file

[tepples]

Full disk encryption available on Linux via LUKS can protect the integrity of the resume image. So there is no reason, none, nadda, for the kernel to have some second method to verify the integrity of the suspend to disk image.

Then to uphold Secure Boot, Linux should disable hibernation unless the hibernation file is stored in FDE.

Re:Sign the hibernation file

[DarkOx]

No it should not. If I don't as the machines owner feel I have the need or desire to preserve a chain of trust; nobody should force me to do so. Security should serve MY interests.

We don't require you to lock your car doors do we? Do most think its a good idea sure, but you don't have to.

Whoosh

[sconeu]

That was the sound of the joke going over your head.

Re:Whoosh

[KingRobot]

Might it be that the sound was a joke going over YOUR head? ;-)

Re:Whoosh

[sconeu]

Quite possibly, but PP seemed quite serious about his response -- with two links, even!

Fuck Secure Boot

[Anonymous Coward]

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

[UltraZelda64]

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

[recoiledsnake]

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

[blueg3]

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

[0123456]

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

[Anonymous Coward]

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

[girlintraining]

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

[blueg3]

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.

Re:Fuck Secure Boot

[grcumb]

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

[Anonymous Coward]

"I suggest not buying hardware with Secure Boot"

          And how long till there isn't any?

Re:Fuck Secure Boot

[celle]

"Microsoft actually does something evil."

      Microsoft already has on numerous occasions, one more is dust in the wind right? As for UEFI Microsoft's involvement has been going on a long time. And who said secure boot had to be default, guess, Microsoft. It could be off and set to on by users, you know the ones who should have control since they're paying for it.

Re:Fuck Secure Boot

[Nimey]

Or it could be that you're just a conspiracy theorist.

Re:Fuck Secure Boot

[QuantumBeep]

The shift is, sadly but truly, because the original Slashdot "how should I mod this post" logic has been overloaded by Reddit's: "UPVOTE DOWNVOTE LOL" version of user moderation.

Why are you wasting time?

[Anonymous Coward]

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?

Re:Why are you wasting time?

[stafil]

(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.

Conceptually..

[Junta]

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..

[Anonymous Coward]

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.

Re:Conceptually..

[mjg59]

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..

[Anonymous Coward]

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..

[mjg59]

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

Re:Conceptually..

[Miamicanes]

> 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.

Re:Conceptually..

[Anne Thwacks]

Perhaps there is a reason why Samsung is No 1?

Re:Conceptually..

[celle]

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

      Yes there is a Microsoft reason to turn it off. Backwards compatibility with older OSes and applications. That and a possible negative response from the DOJ and especially the EU. Of course, a large backlash by the tech public couldn't be ruled out either.

Re:Conceptually..

[Anonymous Coward]

How about kernel modules? Is loading modules allowed in secure boot mode? (or do they have to be signed as well..?)

Re:Conceptually..

[Anonymous Coward]

For now. Let's wait and see what happens as soon as the migration to "secure boot"-enabled hardware is complete.

We are already seeing Android applications limiting their availability to users who have no root access in their phones (e.g. the Sky app). Even while still letting the user boot without the "secure" option, software publishers could choose to only provide their services to users who have "secure boot" enabled. Which is all good, but then I'd like such measures to be labeled as DRM rather than security.

Most importantly, as a Linux user, I don't care about Windows' DRM schemes -- but I'd hate to live in fear of what the requirements for the "Windows 9 logo" will be.

Re:Conceptually..

[Anonymous Coward]

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

Amen brother. And the definition of "root" can also be relativized when in the future a TPM chip shall be used to secure boot the (more) secure seL4 microkernel. I just googled and realized that, of course, the seL4 microkernel guys where already looking into TPM/secureboot.

Linux shall then run in the microkernel's "userspace" and "root exploit" shall have a new meaning, hardly as scary : )

I'm all for more security even if don't necessarily trust yet TPM / secureboot I think it's good to see people trying to fix the utter fiasco we're currently in (tens of millions of zombies box causing havoc: DDoS, credit card fraud, astroturfing, fake votes on petitions, etc.).

Re:Conceptually..

[mjg59]

Disabling secure boot means you can easily lie to the OS about whether or not secure boot is enabled.

Re:Conceptually..

[Anonymous Coward]

The initrd can't directly execute ring 0 code, but it can supply kernel modules that would. However, a signed/secure booted kernel would have to require signed modules, otherwise the chain of trust would be broken.

Re:Conceptually..

[Cassini2]

Better question: Wouldn't Microsoft Windows have exactly the same hybernation-resume problem?

Re:Conceptually..

[Junta]

The kernel can execute ring 0 instructions. Your initrd can't.

Yes it can. It just makes a new 'ring 0' (e.g. qemu). The best SecureBoot can really hope to do is be tamper-evident in certain ways. E.g. if MS dictated that a key issue is contingent upon the application showing a certain logo, then you could educate *some* users that if they see anything but the Windows logo before their Windows system boots, it isn't to be trusted. It's nonsense to push the Secureboot goal further than that. Of course you can eventually display a Windows desktop, no matter how much you try in the SecureBoot methodology, it just can make it obvious. The key part is no feasible way to jump from Vendor assured non-customizable content to end-user sealed/signed/whatever content without the Vendor somehow blessing your key. For example, you think you've done well by LUKS protecting your drive and have Secureboot to say the kernel is *a* valid (note, not necessarily the last one you laid down), but someone injects malicious plymouth theme/tooling to MITM your passphrase to install a trojan prior to boot... Basically, we still have no way to protect against offline atack of disk contents where the authorized user may use the system after the attack is begun.

Re:Conceptually..

[Junta]

Additionally, once 'defeated', secureboot is trivially advertised. It's just a firmware flag that suggests that SecureBoot validation were done. A malicious low level attack could set the flag. That means it is useless as a mechanism to work against the end-user in the scenario where SecureBoot is optional, they can always put a UEFI loader in that falsely advertises SecureBoot before moving on. This design strongly suggests it isn't intended as a DRM feature (or else is among the dumbest ever attempted).

because linux has always run on shit hardware

[decora]

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.

The problem isn't with the hibernation

[sethstorm]

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

[UltraZelda64]

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

[Anonymous Coward]

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

Re:The problem isn't with the hibernation

[Anonymous Coward]

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

Linux can benefit from Secure Boot too.

Re:The problem isn't with the hibernation

[Anonymous Coward]

You'll be happy to know that Samsung is working with the ARM folks to make server CPUs to sell (that I am quite sure will be able to be used on desktop motherboards as well), that don't require Secure Boot.

Knowing Samsung though, expect the price to not be cheap for a few years after release.

How can I tell which hardware uses secure boot?

[aliquis]

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:How can I tell which hardware uses secure boot?

[ChunderDownunder]

Mac os x will run fine on Apple machines!

Re:How can I tell which hardware uses secure boot?

[Anonymous Coward]

Mac os x will run fine on Apple machines!

Knowledge at a typical mac user level.

Thanks for the info/your opinion but it's never needed.

Re:Minecraft converted from Java to C#

[Anonymous Coward]

That's long overdue!

All this bullshit and we still have problems

[kawabago]

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!

Re:All this bullshit and we still have problems

[benjymouse]

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

Right. Why do we bother with security in the first place? Let's just disable security features on every system because they will be circumvented anyway. What an absurd argument.

and hobbling the industry with a proprietary technology isn't going to help anyone but incumbent large players.

Secure Boot isn't proprietary. It is specified bye UEFI where several of the Linux distros have been represented. Not that you'd know from the hyperbole by some of them, MJG included.

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!

Personally I'd like my bank, my government, the military, the SSL issuers to set up their systems so that they'll know if their systems (on which I depend) have been compromised. Have you forgotten that kernel.org, linuxfoundation.org and several other LF operated sites were thoroughly root'ed for a almost a month without them noticing it? It took a coincidence and a mistake on part of the attackers for the admins to discover. Without the mistake, those system could very well have been root'ed to this day.

Secure Boot *directly* addresses that problem: If your system has been compromised, you'll want to know as soon as possible. Secure Boot will refuse to boot a compromised system.

Re:All this bullshit and we still have problems

[DarkOx]

The issue these patches are addressing though have nothing to do with security from the perspective of the machines owner.

I agree a bios that only executes and signed boot loader and boot loader that only executes a signed kernel image *could* be valuable tools to enable an operator to validate the machine has not been compromised. As the machines owner though *I* not anyone else unless I so designate should have the ability and possess the sole authority to sign boot loaders and kernels.

There is no legitimate need to do what these patches do nor add some other method to verify the integrity of resume images. Why because integrity protection of the resume image already exists if the machines owner enables it. Hibernation on Linux works with full disk encryption enabled. Its not possible for anyone who does not control the disk encryption keys ( the machines owner ) to alter that image when disk encryption is in use. There is not legitimate security objective in denying the machines owner and authorized operators the ability alter their own data.

I am not against secure and I think many others are not either, what we are against is measures and thinking like this that clearly have nothing to do with protecting the machine's legitimate owners and operators but instead are about marginalizing other platforms to make a certain vendors more commercially viable, or about directly enforcing the interests of others who have no ownership of the machine over those of its lawful owners and operators.

Tourettes and Rap

[smittyoneeach]

NOT peanut butter & chocolate.

To many X86 servers do not boot Windows

[Joe_Dragon]

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

[0123456]

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

[exomondo]

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

[Anonymous Coward]

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:To many X86 servers do not boot Windows

[Anonymous Coward]

"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?"

        With enough money and/or enough market control anything is possible and in business will be used. It's not like microsoft hasn't done this before(netscape) or have been the only one(intel/amd).

The price of freedom is eternal vigilance.
Give them a crack and they'll wedge themselves through.
example: Read the constitution and papers surrounding it in the context of when they were written for the intent and compare that to currently enforced law and its intent then tell me if we're still following constitution.

Re:To many X86 servers do not boot Windows

[Anonymous Coward]

" With enough money and/or enough market control anything is possible and in business will be used. It's not like microsoft hasn't done this before(netscape) or have been the only one(intel/amd)"

          I forgot microsoft being a convicted monopolist and corrupting the ISO next to netscape. And the ISO debacle was recent so you can't say that microsoft is reformed. Microsoft can NEVER be trusted or reformed and should have already been broken up when they got caught actively lying to the federal court.

Re:To many X86 servers do not boot Windows

[jimicus]

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?

They don't need to.

Linux didn't get where it is today - where more and more non-technical people are trying it every day, where lots of people are saying "actually... this is pretty good. Shame it's terrible for X (where X is something like games) or I'd switch in a heartbeat" overnight. It was a long journey consisting of thousands of baby steps.

For much of that time, very few would even contemplate trying Linux on the desktop.

If - and while it's a big "if", I don't think it's an inconceivable one - Microsoft decide that Windows 9-certified x86 hardware will be locked down to only boot Windows 9 - desktop Linux is set back for as long as it takes to find a clean, reliable, efficient way to resolve this that works on every vendor's motherboard.

The whole point of Secure Boot is that such a thing doesn't exist. Oh, you might find the odd piece of hardware here and there with a flaw in the implementation - it's these flaws that make it possible to do things like jailbreak the iPhone - but because the hardware is so fragmented, the likelihood of finding a clean, efficient way that works on every piece of hardware is slim to nil.

(It also stinks of anti-trust, but apparently that's no longer a worry).

Re:To many X86 servers do not boot Windows

[exomondo]

Well of course you're going to have a hard time with that, success for an operating system requires partnership with hardware vendors or hardware vendors that at least see it as a viable solution. On the desktop, Microsoft has a lot of hardware partners for Windows and Apple simply makes the hardware, in the server market vendors most often choose Linux for their offerings and on mobile Google partnered with various device manufacturers for Android and that's snowballed into many non-partners using it in their products. Sure just about any computing device can run Linux, but without support from hardware partners drivers for all the hardware won't get written for Linux.

There's no reason desktop computer hardware makers - especially non-Microsoft partners - couldn't push Linux if they saw it as viable, just like they do for Android on mobile.

Re:To many X86 servers do not boot Windows

[exomondo]

Not yet - wait until Windows 9..

Then every motherboard producer that want a MS certification HAS to implement secure boot.

Every motherboard manufacturer who wants Windows certification for Windows 8 already needs to do that.

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.

Even if they could do that there is plenty of non-certified hardware and nothing stopping manufacturers from building Linux desktops just like so many do with Android devices - even most Microsoft partners make and sell Android devices.

Re:To many X86 servers do not boot Windows

[jimicus]

There's no reason desktop computer hardware makers - especially non-Microsoft partners - couldn't push Linux if they saw it as viable, just like they do for Android on mobile.

Agreed. But all the evidence so far suggests there are no major hardware makers who see Linux on the desktop as a viable platform.

So if a minor maker does, there's a good chance they'd need to have motherboards customised, pushing prices up significantly.

Furthermore, this eliminates one of Linux's biggest selling points to new users - that you can run it on your own PC, no need to buy something new. In a hypothetical world where the majority of prospective user's x86 PCs are nailed to secure boot only, that advantage is gone.

Re:To many X86 servers do not boot Windows

[exomondo]

Agreed. But all the evidence so far suggests there are no major hardware makers who see Linux on the desktop as a viable platform.

Perhaps it isn't, I mean with major missteps like Windows Me and Vista, Linux still failed to get traction in the consumer market, yet Android dominates the ARM personal computing space.

So if a minor maker does, there's a good chance they'd need to have motherboards customised, pushing prices up significantly.

Such is the way with a niche market, supply and demand. These days people seem to prefer devices with a unification of hardware and software rather than separating them. Smart phones, tablets, gaming consoles and pre-build/pre-configured PCs/Macs are hugely popular because most people use them as a tool and don't want to be tweaking them and configuring them, not to mention these days they are cheap enough and last long enough that 'upgrading' an old PC is less and less necessary.

Re:To many X86 servers do not boot Windows

[tepples]

there is plenty of non-certified hardware and nothing stopping manufacturers from building Linux desktops

Other than running the risk of losing volume discounts on Windows licenses. See my reply to vux984.

Re:To many X86 servers do not boot Windows

[exomondo]

Other than running the risk of losing volume discounts on Windows licenses.

Bullshit, plenty of big name OEMs make Linux laptops, moreover not all OEMs get volume license discounts and further still you don't need to be a Windows licensee to make Linux laptops (a quick google search will show you many that don't).

It doesn't matter...

[Marcion]

... 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...

[loufoque]

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...

[Anonymous Coward]

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...

[Anonymous Coward]

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?

Re:It doesn't matter...

[celle]

"Set everything to autosave and get a distro that boots up quickly."

      And use SSD drives in your machine. If you still have a problem, switch to decaf.

Re:It doesn't matter...

[celle]

"Whatever application you had open is still open in the exact same state, and that's practical."

        Funny X11 used to have this thing called session management, I wonder where that went?

Re:It doesn't matter...

[Marcion]

Good for you, obviously you have been much luckier in your choice of hardware.

Re:It doesn't matter...

[Marcion]

Yeah I do use suspend for short periods, it does work.

Waste of processing power and disk space

[Anonymous Coward]

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.

Re:the logo is weird anyway

[Anonymous Coward]

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

[Anonymous Coward]

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.

Hybernation worked?

[Anonymous Coward]

Who knew?

Yes! It's a secure boot patch!

[Anonymous Coward]

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.

[formfeed]

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

[Damouze]

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?

Re:SecureBoot is a modern version of vendor lockin

[Anonymous Coward]

They can control software direction much better than ever before. But we're talking about hardware, and the hardware guys are all afraid to say no to MS.

It's called "boiling frogs"

[Anonymous Coward]

Matthew, this is one thing which astonishes me. I'm a big fan of yours. You're exceptionally intelligent (believe me, there's no whiff of irony on my part here). Still, you are able to focus so narrowly on secure boot *on its technical merits alone*.

Yes, it's one crucial link in the security chain. A security chain whose other links don't even exist yet or are made out of cardboard (and will be in the foreseeable future).

Had Microsoft proposed to make secure boot mandatory for the "classical platform" right away, the stink would have been enormous. So they prefer to boil the frogs slowly. Cf. the non-Intel platforms for a glimpse into future plans.

My take: secure boot, from a strictly technical perspective a good idea (although the implementation is gruesome, as many of the things this industry comes up with). From a "social" perspective it's utter fail, just for nothing (or just for lining Microsoft's pockets).

Still, Matthew I thank *you* for the work you are doing. Without, who knows: we might not be able to boot any free OS next year.

Re:the logo is weird anyway

[celle]

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

      Just call it bribes and be done with it. Or maybe even kickbacks, etc.

Pick one that is important to you...

[Randall311]

Secure Boot or Hibernation.

Re:Pick one that is important to you...

[Anonymous Coward]

Or just use Windows. It's not the first time when a new technology emerges and it takes 10 years for the OSS community to make it work properly.

There may be benefits to SecureBoot...

[Anonymous Coward]

While I don't like the paying model of SecureBoot and its implications for OpenSource (but I'm sure this shall be sorted out), I do really appreciate the idea of having a the ring0 containing only trusted code.

One can dream of a future a little safer: a microkernel formally verified to be immune from buffer overflow, null pointer exceptions, etc. like seL4 in the ring0 installed using SecureBoot.

That would be quite a good start: from there you could run Linux on top of it (eg Linux already runs fine on top of the seL4 microkernel).

Honestly I'm giving up hibernation for a more security: not because someone physically exploiting my machine scares me but because I think that, by now, people should begin to understand that security is more important than the rest.

Just hang on a minute while I...

[destruk]

I need to upload this 8GB "Hibernation File" and then reboot the computer so I can gain access to it through this security hole... It'll just take me a minute or two to do that. So how stupid do they think people are to even advertise this 'major threat' ?

Once Linux PCs are mail order only

[tepples]

and if you don't want a windows PC you will buy one without windows.

Good luck finding a PC without Windows that isn't made by Apple in U.S. retail chains. Good luck figuring out how to try the keyboard and screen of a laptop made something like System76 before buying. And good luck connecting the laptop to the Internet should major home ISPs adopt Trusted Network Connect as a measure against spam, viruses, and mass copyright infringement.

Re:Once Linux PCs are mail order only

[vux984]

Good luck finding a PC without Windows that isn't made by Apple in U.S. retail chains.

Fast forward to a world of locked bootloaders and I could see PC vendors having a "no-OS, bare hardware, unlocked bootloader" checkbox on every single system they sell.

It would cost vendors little to do this.

The reason that it doesn't exist today is because you can already buy any computer you like and put whatever you want on it. So there is no real advantage in offering a no-OS, hardware only solution.

86-DOS by SCP

[tepples]

How in the world has Microsoft, one single software firm, managed to usurp power enough to dictate to hardware manufacturers

It started in 1981, when IBM was looking for an operating system for its 8088-based IBM PC. Microsoft offered to undercut DRI's CP/M by buying the rights to the 86-DOS product from Seattle Computer Products, a company that had sold computer kits built around the Intel 8086 microprocessor, of which the 8088 was a cost-reduced variant. SCP had designed 86-DOS to allow developers of CP/M programs to make quick ports, and at the time, there wasn't much existing software for 8086 computers on which big companies were already relying. So a switch from CP/M to 86-DOS wasn't nearly as painful as a switch from Windows to GNU/Linux would be today.

are we headed towards a second, 'scientific' dark age?

We're already in a cultural dark age due to digital restrictions management on motion pictures and video games.

Re:86-DOS by SCP

[Anonymous Coward]

We're in a cultural dark age due more to religious nonsense than digital restrictions on motion pictures or video games.

There's no shortage of ways to get around the digital restrictions, but we're awash in the religious pushing their laws onto the books and losing ground almost daily.

Example: I have yet to meet a single person who has any trouble getting "pirated" movies, music, or software to "just work".

There is almost nothing of cultural value emanating from the entire Muslim religion any longer, which is sad, considering how much they actually contributed in earlier centuries. The same goes for the other two Abrahamic religions as well. All three are leading us into a downward spiral.

Take a good look at the anti-cloning laws, and similar stupidity, to see what happens when the religious are allowed to dictate how we perform science research and the cultural impacts it has.

Ubuntu on a Chromebook

[tepples]

Personally I think old Ballmer has too damned much on his plate to give a shit about Linux one way or another ATM

Then why has B-17 Ballmer's company continued to pressure manufacturers of Android smartphones, charging them as much for the use of FAT file system patents and other essential patents as it would charge for a license of Windows Phone itself?

namely "Become Apple" which he is learning

Hence the patent suits.

Have you SEEN the new Acer ChromeBook? You have an X86 CPU, hard drive, RAM, etc that are so bog standard it hurts yet is so locked down you can't even run Linux X86 on the damned thing!

To reformat an Acer Chromebook into developer mode, hold F3 and Esc while turning on the power, then press Ctrl+D.

Re:Ubuntu on a Chromebook

[Anonymous Coward]

Then why has B-17 Ballmer's company continued to pressure manufacturers of Android smartphones, charging them as much for the use of FAT file system patents and other essential patents as it would charge for a license of Windows Phone itself?

Because it's a revenue stream, if the conspiracy theorists were to be believed Microsoft has all the power in the world to force OEMs to not use Linux and to use Windows instead, but they don't. Android is the most pervasive OS in the mobile device market and Windows Phone and Windows RT are barely a blip on the marketshare charts.

Re:Ubuntu on a Chromebook

[hairyfeet]

So even you admit that you have to 1.-Put it into Dev mode, 2. Format the hard drive, no dual boots allowed, oh and you forgot 3.- You can ONLY use a single version of Ubuntu that is done by one guy because a bog standard X86 install WILL NOT WORK thanks to how fucking locked down the BIOS/UEFI is even under "dev mode".

As for why they are still getting checks from Android, duh! Because they can't give away their own product in mobile and that's the closest they've come to a positive revenue stream in mobile in over a decade!

If MSFT had any real power left they'd be using Windows licensing to force OEMs to drop Android but that ain't happening, instead it looks like more companies like Acer are in talks to give more business to Google as they can see that Win 8 is a megafail.

so if anything we need to be MORE vigilant, not less, and hold Google's feet to the fire because if they end up taking over and continue to use the ChromeOS model the future of X86 is gonna be nothing but game consoles, all locked down and controlled by corporate AFTER the sale as well as before. i mean when you can't even install Debian or Slax on a Celeron? Something is SERIOUSLY wrong here.

Step 2: Fan on demand

[tepples]

So that you could monitor in how much pain it is in?

Yes, and this lets you trigger the CPU fan to turn on or speed up whenever the CPU is under stress. This way you get nice, quiet operation when the computer is running undemanding applications such as editing the low-definition version of a video, or loud operation when you're out of the room and the computer is running something similarly CPU-demanding with all cores blazing, such as applying the chosen edits and effects to the original high-definition footage.

Schroedinger's joke and what the tropers call CMTP

[tepples]

When I see Schroedinger's joke, a comment that both is and isn't a joke depending on how it's read, I try to make Schroedinger's reply. If the parent comment wasn't a joke, as in the case of my cousin's laptop that has a habit of overheating, my comment is helpful. If it was, my comment is a joke too. KingRobot is perceptive.

MUST...BE...GREEN...MUST...BE...GREEN...

[Impy the Impiuos Imp]

If that much security is your concern, shut down properly to save power and eat the time waste of startup, or don't shut down and just leave it running.

Crusade against the "naked PC"

[tepples]

Fast forward to a world of locked bootloaders and I could see PC vendors having a "no-OS, bare hardware, unlocked bootloader" checkbox on every single system they sell.

Unless Microsoft changes the terms of the Windows OEM license to make it economically infeasible to offer such an option, such as its crusade a few years ago against the "naked PC".

It would cost vendors little to do this.

Other than likely having to pay full retail for Windows if the same company sells PCs without an operating system.

Re:Schroedinger's joke and what the tropers call C

[sconeu]

No big deal. As I noted above, I am quite willing to admit that I missed your joke as well.

It's possible that I bow to your superior quantum level of humor.

Upward mobility

[tepples]

most people use them as a tool and don't want to be tweaking them and configuring them

So what should one someone who owns a device do when he wants to use the device as a tool but discovers that a particular application is not available for his device because the device's monopoly gatekeeper rejected the concept? For example, someone who plays video games might want to try his hand at making a mod, but games for a certain platform aren't especially mod-friendly. It's a question of headroom for upward mobility.

Re:Upward mobility

[exomondo]

So what should one someone who owns a device do when he wants to use the device as a tool but discovers that a particular application is not available for his device because the device's monopoly gatekeeper rejected the concept?

Use a different tool. Sure an iPad is a great device for many things, but developing applications isn't one of them, you can't - for example - run XCode on it.

Then shut off Secure Boot

[tepples]

If I don't as the machines owner feel I have the need or desire to preserve a chain of trust; nobody should force me to do so.

Then shut off Secure Boot and resume into your unsigned hibernation file.

Makes sense

[lamber45]

Hibernation actually is a security hole. I'll ignore the kexec issue for now, but encrypted and checksummed hibernate images would be a good thing, and would be nice on a non-SecureBoot system as well. At a minumum, the hibernation image should carry a checksum of { the image data + the kernel that loaded it + relevant platform data }. That would at least prevent partially booting a suspend image with random corruption. Can SecureBoot also provide a secret key used only to encrypt the suspend image and decrypt it during boot? Or some additional data to feed into the checksum that securely identifies the platform? Or keep the suspend checksum in nonvolatile memory that can only be written to by a trusted operating system?