Secure Boot Coming To SuSE Linux Servers

darthcamaro writes "UEFI Secure Boot is a problem that only desktop users need to worry about right? Well kinda/sorta/maybe not. SeSE today is releasing SUSE Linux Enterprise 11 SP3 which will include for the first time — support for UEFI Secure Boot. Apparently SUSE sees market demand for Secure Boot on servers too. Quoting Matthias Eckermann, Senior Product Manager at SUSE: 'Our market analysis shows that UEFI Secure Boot is a UEFI extension that does not only cover desktops, but might very well also be deployed and even required on server systems going forward.'"

Comments

Secure Boot solves a nonissue

[Anonymous Coward]

The new hotness is memory-resident. Everything old is new again.

Re:Secure Boot solves a nonissue

[webmistressrachel]

1,4Gb downloaded already, and only 11 Comments? What's wrong with this place? ;-)

Re:Secure Boot solves a nonissue

[mystikkman]

Most folks with half a brain cell have left because of the constant slanted summaries, biased moderation by people with an axe to grind and the constant FUD and lies being spread on here.

http://mobile.slashdot.org/story/13/03/17/1914209/microsoft-to-abandon-windows-phone

Don't think that the constant karma whoring and circlejerking by the likes of symbolset, bmo, etc. and the moderation does not have any ill effects. There's no place for rational discourse here, whoever posts the most anti-MS screed gets voted up regardless of facts.

Re:Secure Boot solves a nonissue

[wbr1]

There's no place for rational discourse here, whoever posts the most anti-MS screed gets voted up regardless of facts.

I am going to test your theory.

MS Sucks balls, They have since 1978. In fact Gates dropped out because everyone's balls at Harvard were chafed from staying damp with Gates saliva.

Balmer is CEO now, because he even has a ball in his name.

If you look deep in the resources in shell32.dll, there is a string that reads, "insert balls into CD-ROM for a 'Gates job'."

Re:Secure Boot solves a nonissue

[PopeRatzo]

There's no place for rational discourse here

Please tell us when the Golden Age of Rational Discourse on Slashdot ended, sifu.

I'd like to have some time-frame for my nostalgia.

Re:Secure Boot solves a nonissue

[evilviper]

There's no place for rational discourse here, whoever posts the most anti-MS screed gets voted up regardless of facts.

On the plus side, the absolute FLOOD of inflammatory stories about global warming, evolution/intelligent design, has trailed off. Those were almost daily occurrences on the front page when CmdrTaco left, and the anti-XYZ bile in the comments was something to behold. You'd get a dogpile of angry replies and instantly modded down to -2 if you even offered small factual corrections to anti-XYZ rants.

While that was ongoing, I had almost entirely ceased activity on /. for months. Not to say that things are all better, but it had been even worse, or I wouldn't be here at all.

Re:Secure Boot solves a nonissue

[evilviper]

Please tell us when the Golden Age of Rational Discourse on Slashdot ended

I'd say it was roughly around the time that your account was created, Ratzo...

Re:Secure Boot solves a nonissue

[PopeRatzo]

Please tell us when the Golden Age of Rational Discourse on Slashdot ended

I'd say it was roughly around the time that your account was created, Ratzo...

I know, ain't I a stinker?

I should be a little more careful with my powers.

Re:Secure Boot solves a nonissue

[Anonymous Coward]

Does this mean you have less than half a brain cell?

Re:Secure Boot solves a nonissue

[webmistressrachel]

Unfortunately, I held out on actually registering, and have a rubbish UID as a result. I still see logical, rational and funny discourse, and I've got quite a loose leash when I post silly things to cause trouble - things could be a lot worse for me here, with the things I post sometimes!

I got the username I would have chosen though, I was webmistressrachel at Excite dot com while it was still going!

The new Microsoft-NSA hybrid owns us all

[hessian]

First they came for the secure boot, and I did not speak up, because I was not a BIOS...

This will enable them to control all of our computing hardware from their centralized corporate mind-control chambers.

Soon they will make us intolerant of anyone not like us, and we will become flag-waving, hamburger-munching, Coke-swilling droids who cheer whenever the poor, brown or leftist people are slaughter by automated drones.

Running Windows ME. ...so how'd I do Reddit I mean Slashdot? Did I hive mind the right way? Shower me in imaginary internet karma points!!!

Re:The new Microsoft-NSA hybrid owns us all

[Anonymous Coward]

Soon they will make us intolerant of anyone not like us, and we will become flag-waving, hamburger-munching, Coke-swilling droids who cheer whenever the poor, brown or leftist people are slaughter by automated drones.

Looks like your attention's been focused elsewhere for a while. You'll never guess what's happened...

Well isn't that sweet?

[Anonymous Coward]

Another jumps in bed with the devil.

SecureBoot is incomplete

[Junta]

SecureBoot is an incomplete strategy. It only allows for attestation of software vendor provided content. It does nothing for:
-custom executables
-configuration data and so on

Servers in particular need to be looking for a mechanism for the customer to measure and secure their own boot stuff. Constructing a good enough root kit out of valid signed secureboot content is going to be feasible unless you render the system overly limited.

It's theoretically possible to completely break SecureBoot but still advertise SecureBoot as intact. System will merrily load up a signed hypervisor and that signed hypervisor may in turn do whatever the hell it wants including boot the 'normal' OS as a guest with firmware that will tell the OS whatever the attacker feels like. If secureboot is disabled, you can have a rootkit that advertises it as enabled without issue.

Ultimately, it's a mitigation strategy with huge gaping holes that people presume are no longer a problem because they don't take the time to understand the nuances of such a strategy. I'm not accusing the designers of this misconception, but the general population's understanding of the benefits of SecureBoot has been very misguided (I have heard some claim that PXE being wide open is ok because secureboot would protect it, in one example of how badly misunderstood Secureboot is)

Re:SecureBoot is incomplete

[bws111]

Secure boot only ensures that you know that what you are booting is signed by someone you trust. It does not provide 'attestation'. If you want attestation, use TPM, possibly combined with secure boot. TPM is not subject to being tricked by hypervisors.

Re:SecureBoot is incomplete

[Junta]

My issue is that I'm having a hard time seeing what SecureBoot adds that cannot be acheived in a better fashion (e.g. more comprehensive use of a TPM). SecureBoot doesn't ensure that your are booting is signed by someone you trust. It assures that one efi executable was signed by someone (who you may or may not 'trust'), but most would conceive of 'what you are booting' to be the universe of everything that happens prior to the system being usable, boot loader, kernel, configuration, third party executables, etc etc, which SecureBoot does nothing to really facilitate meaningful measurement. SecureBoot is ill equipped to facilitate most of that.

It complicates use of non-microsoft OSes and I think the value of the mitigation provided is greatly overestimated due to a name that suggests more assurance than one should reasonably assume.

Re:SecureBoot is incomplete

[Nerdfest]

what you are booting is signed by someone you trust

Or Microsoft.

Re:SecureBoot is incomplete

[KiloByte]

It complicates use of non-microsoft OSes

And that's the whole reason SecureBoot is getting pushed onto manufacturers.

Re:SecureBoot is incomplete

[John.Banister]

If some well meaning but less than perfectly well informed member of a management team decides that there should be a policy requiring secure boot, then it might be nice for the product that it's able to comply. Certainly it would be better to properly educate management, but dealing with software might be easier.

Re:SecureBoot is incomplete

[cold fjord]

SecureBoot doesn't ensure that your are booting is signed by someone you trust.

Maybe what's needed is an additional piece like a programmable smart card that could carry a list of trusted sources. Then you could customize each system for exactly what is to be trusted on it in a hard to hack form. (Assuming the card reader is read only on that system.)

Re:SecureBoot is incomplete

[Anonymous Coward]

SecureBoot doesn't ensure that your are booting is signed by someone you trust.

Factually wrong. Sign your own binaries and manage your own white-list of certs. You can do this you know, create your own customer kernel with your cert to sign, and bootloader.

Re:SecureBoot is incomplete

[benjymouse]

My issue is that I'm having a hard time seeing what SecureBoot adds that cannot be acheived in a better fashion (e.g. more comprehensive use of a TPM). SecureBoot doesn't ensure that your are booting is signed by someone you trust.

Yes it does. Especially on Windows, the OS is booted from signed cabinet files, i.e. the Microsoft bootloader will refuse to boot Windows unless the cabinet file (which include executables, libraries, core config files) is signed correctly.

It assures that one efi executable was signed by someone (who you may or may not 'trust'), but most would conceive of 'what you are booting' to be the universe of everything that happens prior to the system being usable, boot loader, kernel, configuration, third party executables, etc etc,

And if the bootloader and OS in turn takes on their part of that responsibility, you *do* have a trusted chain. Of course, it requires that the OS is booted from signed files that include executables as well as config. If the OS is set to require signatures (or hash matches) of 3rd party executables it can ensure integrity for itself. The chain merely ensures that each step can be confident that at the time where each step receives control of the system, integrity is ensured. Each step must ensure it's own integrity and only pass control to the next step if integrity can be validated.

Re:SecureBoot is incomplete

[vojtech]

You might want to examine the MOK concept that SUSE has implemented. It allows for custom executables that are checked against a local key.

Regarding configuration, that is outside of the scope of Secure Boot. Its purpose isn't a full system attestation, it's limited to preventing executing untrusted code in kernel space. That alone is of value, as it makes installing persistent and invisible rootkits much much harder. Not impossible, of course - as long as software can have bugs, no security technology can be perfect.

(working for SUSE ...)

Re:SecureBoot is incomplete

[kthreadd]

If you don't trust Microsoft then you should of course not trust their key either.

Re:SecureBoot is incomplete

[Anonymous Coward]

Ultimately, it's a mitigation strategy with huge gaping holes that people presume are no longer a problem because they don't take the time to understand the nuances of such a strategy. I'm not accusing the designers of this misconception, but the general population's understanding of the benefits of SecureBoot has been very misguided (I have heard some claim that PXE being wide open is ok because secureboot would protect it, in one example of how badly misunderstood Secureboot is)

SecureBoot can indeed help solve some of the problems of PXE. However, you're right in that simply loading signed executables isn't enough. Filesystems loaded over PXE must also be verified. This is where iPXE comes in. You use PXE with SecureBoot to load a signed copy of iPXE. Being signed, you trust iPXE, which has the ability to verify the kernel and initrd files.

iPXE won't update PCRs yet, which would be useful, although I've heard this is coming.

good as MS ideas like metro on servers is dumb

[Joe_Dragon]

good as MS ideas like metro on servers is dumb even more so the is the app store.

Need an exit route if they go app store only.

Re:good as MS ideas like metro on servers is dumb

[Nerdfest]

SecureBoot is designed to make that exit more difficult. You can get past it if you know what you're doing, but giving someone a Linux distro to install themselves via a USB boot no longer as easy as it was.

Re:good as MS ideas like metro on servers is dumb

[jampola]

Turn computer ON -> Press F12 or Del -> Disable secure boot -> Reboot

Now THAT wasn't so hard was it?

Yes yes, I know, some systems aren't that easy but for the last 3 or 4 (really really new) laptops I've had to install Debian on, it really was THAT easy!

SecureBoot has no place as implemented

[sethstorm]

Until it is something that allows for end-user control of the process instead of Microsoft, then the only support necessary is for it to be made non-functional.

Re:SecureBoot has no place as implemented

[bws111]

Secure boot does nothing to prevent the end user from being in control, and it does not require anything from Microsoft. If your vendor does not allow you to install your own keys, get a better vendor.

Re:SecureBoot has no place as implemented

[vux984]

Until it is something that allows for end-user control of the process instead of Microsoft,

In that the end user can remove the microsoft key? Yes, it can do that.

In that the end user can install their own key, sign their own software, and boot from that? Yes, it can do that too.

What exactly is your gripe?

Re:SecureBoot has no place as implemented

[0123456]

Secure boot does nothing to prevent the end user from being in control, and it does not require anything from Microsoft. If your vendor does not allow you to install your own keys, get a better vendor.

So first you say that Windows Boot doesn't prevent the end user from being in control, then you admit that it puts the vendor in control. Vendor lock-in is the whole point of Windows Boot.

Re:SecureBoot has no place as implemented

[Anonymous Coward]

Handcuffs don't restrict your freedom! If you're in them just get a better government!

Re:SecureBoot has no place as implemented

[0123456]

In that the end user can remove the microsoft key? Yes, it can do that.

Unless the hardware manufacturer won't let you.

In that the end user can install their own key, sign their own software, and boot from that? Yes, it can do that too.

Unless the hardware manufacturer won't let you.

What exactly is your gripe?

That the hardware manufacturer is telling me what I can and can't run on hardware I own?

In any case, Windows Boot has an insignificant security impact on servers. If my server reboots unexpectedly to load malware, I'm sure as hell going to find out why.

Re:SecureBoot has no place as implemented

[Anonymous Coward]

Or just use a key that has already been leaked...

Re:SecureBoot has no place as implemented

[recoiledsnake]

Given that you're in full control of the keys, Secure Boot is more like a ADT alarm system controlled lock you put in your home than a handcuff. By default, MS is trusted, but you can make it untrusted and prevent Windows from ever booting even by accident if you so wish.

Re:SecureBoot has no place as implemented

[bws111]

HARDWARE vendor. As in, the hardware vendor provides a way for you to manage the keys. It has NOTHING to do with vendor lockin.

Re:SecureBoot has no place as implemented

[recoiledsnake]

Gah, what's it about secure boot that seems to confuse so many people?

Currently there are zero vendors that lock out users from the signing keys since being Windows Certified needs user control of keys.

The parent posts point is that if such a vendor shows up, vote with your wallet and feet and get a computer from another vendor.

How is secure boot about lock-in when you can turn it off with a mouse click?

How is it Microsoft's fault that the FOSS community is unable to come up a signing organization that OEMs are willing to add?

Re:SecureBoot has no place as implemented

[Rockoon]

Unless the hardware manufacturer won't let you.

Isn't this argument essentially fear, doubt, and uncertainty?

Re:SecureBoot has no place as implemented

[Junta]

The disconnect is that SecureBoot as it theoretically is allowed to be implemented to cater to user control and the practical likelihood of how it is implemented is miles apart. A great deal of security isn't about what some protocol or device *can* do, it's about how it commonly ends up in real world.

SecureBoot *strongly* suggests a non-configurable scheme where it must be enabled and it must be MS signing key. Some people say MS wouldn't encourage such misbehavior, but the Surface RT from everything I hear is exactly that way (though I hear the Surface Pro is not). I don't think MS will be doing a lot to punish a vendor for being too lazy to include customer key management capability.

Initial signing key shouldn't have come in the firmware, it should have been like the TPM, the vendor has the opportunity to 'take ownership' of the platform. First OS to install gets to own the signing key. This eliminates the problem for 99.99% of MS user base as Windows preload happens at a 'trusted' vendor without putting undue burden on the rest of the industry. If your argument is that perhaps the user shouldn't trust that system vendor that much, SecureBoot isn't going to fix that. If the argument is that people with piece part systems are put at risk, it's such a small population that has to be using a malicious copy of the media.

Re:SecureBoot has no place as implemented

[epyT-R]

..and when all hardware vendors refuse to allow user generated root keys?

Re:SecureBoot has no place as implemented

[recoiledsnake]

..and when the universe dies a heat death? Anything is possible tomorrow, Secure Boot doesn't mean that suddenly 100% of the numerous PC makers will one day suddenly ban user root keys and make their devices harder to fix in case of issues.

Re:SecureBoot has no place as implemented

[bws111]

And what if the server is intentionally rebooted (by you) to install malware? Ideally the management of the keys in hardware would be protected and only performed by someone who does not have root authority to the OS. Secure boot can help stop rogue admins. It gives control to the owner of the server instead of the admin.

Re:SecureBoot has no place as implemented

[vux984]

Unless the hardware manufacturer won't let you.

Which is nothing to do with secureboot, and everything to do with the hardware manufacturer.

Hardware manufacturers have been technically able to make it so you can't go into BIOS, and have been technically able to restrict what bootloader you use since as long as BIOS has existed.

Secureboot really has nothing to do with it one way or the other.

That the hardware manufacturer is telling me what I can and can't run on hardware I own?

They haven't done so in the past, and they aren't doing so now.

Your gripe is that they might do so in the future, which they have always been able to do, even without secure boot.

If they wanted to force you to run windows they could have done so with a much less complicated solution than secure boot,and they could have done this a LONG time ago. They could have just hard coded the windows boot loader into the bios itself, and locked you out of it.

Re:SecureBoot has no place as implemented

[bws111]

And why, exactly, would they do that? Especially server manufacturers? Your suggestion is pure FUD.

Re:SecureBoot has no place as implemented

[recoiledsnake]

A great deal of security isn't about what some protocol or device *can* do, it's about how it commonly ends up in real world.

It already successfully prevents many kinds of undetectable rootkits on Windows in the real world.

Initial signing key shouldn't have come in the firmware, it should have been like the TPM, the vendor has the opportunity to 'take ownership' of the platform.

I would certainly prefer that the vendors with razor thin margins of a few bucks a PC/motherboard in Taiwan not be burdened with 'taking ownership' of the platform.

If the argument is that people with piece part systems are put at risk, it's such a small population that has to be using a malicious copy of the media.

Even 1% of PC users would be in the high millions.

Re:SecureBoot has no place as implemented

[epyT-R]

Considering technology trends today, it is a likely possibility.

Re:SecureBoot has no place as implemented

[Junta]

I would certainly prefer that the vendors with razor thin margins of a few bucks a PC/motherboard in Taiwan not be burdened with 'taking ownership' of the platform.

The process would be implicit to the OS installer in the hypothetical. It's not like those cheapo vendors would incur any incremental cost at all. It's just that the UEFI firmware that everyone uses understands key installation via some EFI runtime service, and then locks it out once used. Windows PE would detect such a service without key, put MS key in at *that* point instead of having the board vendor always put it in the firmware before an OS ever touches it.

On a related note, if you are relying on the lowest bidder with the cheapest workforce to provide you a secure solution free from supply chain attacks, you are already screwed.

Re:SecureBoot has no place as implemented

[recoiledsnake]

That seems like a lot of work and complexity for something that's already feasible.

Vendors can currently ship OS-less machines with secure boot turned off.

Linux vendors can remove MS' key and put in theirs or the distros' if there is one, or just turn it off and then install Linux before shipping it to the user. The user can install/remove keys and enable/disable secure boot as they please.

Re:SecureBoot has no place as implemented

[Nerdfest]

The FOSS community could quite easy come up with a signing organization, but is unlikely to give computer manufacturers a discount on their OS (or charge more for it) if they don't implement it. This is admittedly just a suspicion, but it does match with the history of what has happened with things like the EEE notebooks.

Re:SecureBoot has no place as implemented

[murdocj]

Which hardware manufacturer?

Re:SecureBoot has no place as implemented

[Anonymous Coward]

Before Microsoft announced that user control over secure boot would be required for x86 systems Red Hat talked to many hardware vendors about their secure boot plans; at the time most of the vendors they talked to were planning to take the least costly route: no secure boot user control.

Re:SecureBoot has no place as implemented

[Anonymous Coward]

I like how "Secure" Boot articles bring the Microsoft shills out of the woodwork.

Re:SecureBoot has no place as implemented

[lister king of smeg]

no its experience and logic. just look at how they have already locked you out of arm based windows devices.

Re:SecureBoot has no place as implemented

[Anonymous Coward]

By having a one-time efi services based scheme, then this all could have been automatic and implicit in the OS install for hardware vendors that preload and for people buying bare systems and installing their own OS.

The current scheme has end users and integrators having to drop into firmware setup menu and take manual action on *every system* if they wanted to pursue such an action (automated scheme to replace key is hard to construct when the whole point is to avoid malware authors having control of the key database).

This would have been as dead simple as reading/writing the efi boot variables that windows and linux do and no one but firmware devs and the os devs would have to give it much thought. Power users and systems integrators could have been utterly oblivious to the negotiation going on as the vendor of choice 'takes ownership' of the platform. Once owned, then you have a PITA process to reset (just like a TPM) to avoid malware being able to change it.

This also would have meant that MS could have avoided being the signing authority for non-MS software, which would have further enhanced rootkit protection aspect of this mechanism.

Re:SecureBoot has no place as implemented

[bws111]

So all of the server manufacturers were willing to give up on the 65% of the server market that is NOT Windows? If you're going to make crap up, at least make it plausible.

Re:SecureBoot has no place as implemented

[Anonymous Coward]

HA! No enterprise customer would allow a system that doesn't allow network boot or custom images. Not allowing secure boot to be manageable by the end user would break IT around the world.

Got a rescue boot-disc? Ohh sorry, can't load it. Want to network boot from your SAN? Ohh sorry, can't do that. Want to remote image your computer? Ohh sorry, secure boot wasn't set to be manageable. Learn how IT works before you start running your mouth.

Re:SecureBoot has no place as implemented

[Anonymous Coward]

but the Surface RT from everything I hear is exactly that way

Well yeah. It's on ARM and they said Secure Boot on ARM is required to have non-configurable Secure Boot.

though I hear the Surface Pro is not

Well yeah. It's on x86 and the said that x86 requires at least the ability to disable Secure Boot and recommend full management.

Re:SecureBoot has no place as implemented

[Anonymous Coward]

Can say the same thing about Android and iOS systems.

Re:SecureBoot has no place as implemented

[sofar]

Then they will not be windows 8 certified, and may not affix a "Windows 8" WHQL sticker, or advertise their systems together with any Microsoft Logo.

Re:SecureBoot has no place as implemented

[Anonymous Coward]

You are retarded. This is admittedly just a suspicion, but it does match the history of your posts in this thread.

Re:SecureBoot has no place as implemented

[KingMotley]

So your idea of how to secure the boot from BIOS on, is to let programs be able to install their own keys? And this is why novices don't design security.

Re:SecureBoot has no place as implemented

[Microlith]

In that the end user can install their own key, sign their own software, and boot from that?

Maybe. If the device you're booting from has its option rom signed by Microsoft and you remove their key, can you boot from the device anymore? My educated guess is no (you can't truly get away from Microsoft) and you are forced to trust Microsoft even if you don't want to because hardware OEMs can only ever assume one key is available due to the (poor) architecture.

Re:SecureBoot has no place as implemented

[Anonymous Coward]

Why else would vendors do unnecessary work?

And it's not like there isn't a history of this. Microsoft makes a pretty good product, but it's not like they have the moral high ground...at all.

Re:SecureBoot has no place as implemented

[Microlith]

How is it Microsoft's fault that the FOSS community is unable to come up a signing organization that OEMs are willing to add?

Because it was laid out poorly from the beginning. Had the key architecture not been left up to an ad-hoc distribution mechanism and, instead, been firmly rooted in the UEFI Foundation, then said signing organization could have gone to the UEFI Foundation and gotten a key without involving Microsoft.

Instead, it was ad-hoc and as a result anyone who wanted their key on the platforms had to go get a key from Verisign and run around to all the OEMs and beg to have it included. This would have been hard for Canonical, never mind all of the smaller vendors out there. So instead, Canonical, Redhat and SuSE (who account for the majority of the Linux user base) jumped in bed with Microsoft and left everyone else flapping in the wind, to be frank. Net result is that Microsoft now has de-facto control over the signing process and the rest of the Linux world has to work around with binary only shims.

Re:SecureBoot has no place as implemented

[Anonymous Coward]

Currently there are zero vendors that lock out users from the signing keys since being Windows Certified needs user control of keys.

Maybe not, but as long as nobody can tell how to get in control of the keys, that's as good as being locked out.

Asking Google for help just gives "You need to enter UEFI setup", with no explanation of how to do that. And none of the usual keys work (F1, F2, Esc, Del).

Googling how to enter UEFI setup then gives a lot of pages explaining that first you need to buy Windows 8, then you need to go into control panel and select reboot to UEFI setup.

So much for not being locked into buying Windows 8.

Re:SecureBoot has no place as implemented

[MrNemesis]

"...and then they came for *my* bootloader, and there were no more vendors to speak out for me."

With apologies to Niemoller. We've already seen a whole class of devices introduced with the inability to boot anything other than their proscribed OS, we've seen the WindowsRT "our bootloader only", and we've not got "UEFI secure boot must be available, but have an off switch for people willing to go into their BIOS". Given MS and their apparently rabid desire to turn windows from a workstation platform into a glorified app store and it doesn't take too hefty a dose of cynicism/paranoia to think MS might strongarm the OEMs into forcing MS-only bootloaders on consumer tech, relegating "custom bootloaders" to much higher-priced hardware.

Re:SecureBoot has no place as implemented

[Rockoon]

The imaginary one in his head.

Re:SecureBoot has no place as implemented

[murdocj]

Just checking, thanks. I'll buy more tin foil, just in case.

Re:SecureBoot has no place as implemented

[nabsltd]

So all of the server manufacturers were willing to give up on the 65% of the server market that is NOT Windows? If you're going to make crap up, at least make it plausible.

In the business world, the vast majority of operating systems being run either don't or soon won't care about the physical hardware because they are running on top of a hypervisor. As long as the hypervisor can secure boot, then that's all that matters.

Now, there are obviously physical servers being used to run various operating systems directly, but again the vast majority in the business world (which is where most hardware dollars are spent) are going to be running Solaris, BSD,, Red Hat, SuSE, Microsoft Windows, etc. In other words, nothing that a business needs to run on physical hardware won't have a signed bootloader available.

Re:SecureBoot has no place as implemented

[recoiledsnake]

Because it was laid out poorly from the beginning. Had the key architecture not been left up to an ad-hoc distribution mechanism and, instead, been firmly rooted in the UEFI Foundation, then said signing organization could have gone to the UEFI Foundation and gotten a key without involving Microsoft.

What is this UEFI Foundation that you speak of?

Re:SecureBoot has no place as implemented

[vux984]

If the device you're booting from has its option rom signed by Microsoft and you remove their key, can you boot from the device anymore?

You should also be able to authorize the option roms you need by hash.

My educated guess is no (you can't truly get away from Microsoft) and you are forced to trust Microsoft even if you don't want to because hardware OEMs can only ever assume one key is available due to the (poor) architecture.

This problem is at least solvable by market forces, and is not a defect in the design of the system. Vendors going after linux marketshare could make it a value add to publishing option rom hashes, or making the roms available so we can sign them ourselves etc or preinstall a manufacturer key along with the microsoft key and sign the option roms with their key as well to simplify removing the ms key.

The upshot is that there ARE ways of removing the MS key and getting a usable system if you want, but its less convenient than it could be if vendors thought about supporting it ahead of time.

I doubt we'll see much improvement with windows 8 preloaded systems from HP etc. But server offerings and enthusiast offerings, and open hardware initiatives ... they might take the small amount of time to simplify running it without the MS key at all if there is any demand for that.

Re:SecureBoot has no place as implemented

[bws111]

What you said may be true, but has nothing to do with what I said. The post I responded to said that BEFORE Microsoft required user control the manufacturers were not going to allow users to control secure boot. In that timeframe, Red Hat, SuSE, etc were not planning on using MS to do any signing. Therefore, the ACs post is not even remotely believable, as it implies that the server manufacturers were willing to give up the largest segment of the market. And for what? The cost of adding user key management to UEFI is minimal at best, and makes your product more attractive. All of these 'but the manufacturers could stop supporting user keys' posts are pure FUD, with absolutely nothing to back them up (that makes sense, anyway).

Secure Boot ISN'T!

[kawabago]

Secure Boot isn't secure nor is it a security feature. It's sole purpose is to keep Linux off of x86 computers. It's already easy to get around 'Secure Boot so I think it's broken as a concept. Security has to constantly evolve to meet evolving problems. Hardware can't do that.

Re:Secure Boot ISN'T!

[recoiledsnake]

Secure Boot isn't secure nor is it a security feature. It's sole purpose is to keep Linux off of x86 computers. It's already easy to get around 'Secure Boot so I think it's broken as a concept. Security has to constantly evolve to meet evolving problems. Hardware can't do that.

+3 interesting? What's wrong with Slashdot that posts with the most misinformation are modded up? And then other people take these modded up posts as gospel and keep repeating the FUD.

Can you tell us how it's easy to get around Secure Boot?

Secure Boot isn't secure nor is it a security feature. It's sole purpose is to keep Linux off of x86 computers

Here's a couple of viruses that Secure Boot prevents.

http://www.chmag.in/article/sep2011/rootkits-are-back-boot-infection

http://www.theregister.co.uk/2010/11/16/tdl_rootkit_does_64_bit_windows/

http://www.computerworld.com/s/article/9217953/Rootkit_infection_requires_Windows_reinstall_says_Microsoft

I recommend reading atleast the first link.

Here's one juicy bit:

TDL4 is the most recent high tech and widely spread member of the TDSS family rootkit, targeting x64 operating systems too such as Windows Vista and Windows 7. One of the most striking features of TDL4 is that it is able to load its kernel-mode driver on systems with an enforced kernel-mode code signing policy (64-bit versions of Microsoft Windows Vista and 7) and perform kernel-mode hooks with kernel-mode patch protection policy enabled.

When the driver is loaded into kernel-mode address space it overwrites the MBR (Master Boot Record) of the disk by sending SRB (SCSI Request Block) packets directly to the miniport device object, then it initializes its hidden file system. The bootkit’s modules are written into the hidden file system from the dropper.

The TDL4 bootkit controls two areas of the hard drive one is the MBR and other is the hidden file system created at the time of malware deployment. When any application reads the MBR, the bootkit changes data and returns the contents of the clean MBR i.e. prior to the infection, and also it takes care of Infected MBR by protecting it from overwriting.

The hidden file system with the malicious components also gets protected by the bootkit. So if any application is making an attempt to read sectors of the hard disk where the hidden file system is stored, It will return zeroed buffer instead of the original data.

The bootkit contains code that performs additional checks to prevent the malware from the cleanup. At every start of the system TDL4 bootkit driver gets loaded and initialized properly by performing tasks as follows: Reads the contents of the boot sector, compares it with the infected image stored in hidden file system, if it finds any difference between these two images it rewrites the infected image to the boot sector. Sets the DriverObject field of the miniport device object to point to the bootkit’s driver object and also hooks the DriverStartIo field of the miniport’s driver object. If kernel debugging is enabled then this TDL4 does not install any of it’s components.

TDL4 Rootkit hooks the ATAPI driver i.e. standard windows miniport drivers like atapi.sys. It keeps Device Object at lowest in the device stack, which makes a lot harder to dump TDL4 files.

All these striking features have made TDL4 most notorious Windows rootkit and it is also very important to mention that the key to its success is the boot sector infection.

Another bit:

The original MBR and driver component are stored in encrypted form using the same encryption. Driver component hooks ATAPI's DriverStartIo routine where

Re:Secure Boot ISN'T!

[Anonymous Coward]

Security has to constantly evolve to meet evolving problems. Hardware can't do that.

You had me until you said this. Security should constantly evolve and we all know because it has been repeated into the ground here that once you have physical access to hardware it is more than game over in the security department.

Why shouldn't hardware evolve to solve the same problem if it is the Achilles' heel of the problem?

The largest most embarrassing security breaches in the news lately have all come from people with way to much local access, as a software engineer I do not see why the Sysadmins get a pass here either ;)

Re:Secure Boot ISN'T!

[csumpi]

What's wrong with Slashdot that posts with the most misinformation are modded up? And then other people take these modded up posts as gospel and keep repeating the FUD.

Welcome, young Skywalker, I have been expecting you.

Re:Secure Boot ISN'T!

[Junta]

Can you tell us how it's easy to get around Secure Boot?

Well, that rootkit had to go through quite a few hoops to avoid detection. A different set of hoops are in order here.

It'd be hard to hide a MS hypervisor because they are so bloated, but a linux hypervisor can be constructed in under 24 megabytes, which is essentially a rounding error in the typical EFI boot partition as created by MS. So the rootkit is a linux bootloader, kernel, and initrd with qemu and such. The rootkit has to fake a *lot* more stuff to fool extremely comprehensive security software (e.g. if it bothers to look at every single device in great detail, then it would have to emulate every single device). This hinges mostly on how comprehensive the security software is expected to be (and whether that security suite compromises to tolerate 'P2V' type changes) and how dedicated the malware authors are (history has shown them to be... extremely dedicated).

The concept is solid enough, but the implementation is flawed. As a consequence of mandating that the factory burns in the signing key, it pretty much forces MS to sign competitor payload or be seen as anti-competitive. This means your Microsoft install implicitly trusts software from Red Hat, Canonincal, VMware, Attachmate, and really anyone else who may enter the ring. There is no way that MS is providing adequate auditing to assure those paths aren't vulnerable and it shouldn't have to. Because it must be installed into firmware before an OS touches it, there is also *no* reasonable opportunity to provide any assurance of customer provided content like configuration.

As to that root kit you mentioned, MS could have protected itself from that without SecureBoot or any boot signing. MS could have made MBR writes from within their OS forbidden without an extreme warning. No OS bothers to do that, but it would have been actually a pretty defensible move on their part to mitigate root kits.

The problem is that Secure Boot gives MS control of the entire ecosystem but in doing so missed an opportunity to provide something that *would* have worked better and allowed MS to avoid vouching for anything but their own software at boot time.

Re:Secure Boot ISN'T!

[westlake]

Secure Boot isn't secure nor is it a security feature. It's sole purpose is to keep Linux off of x86 computers.

Not a problem.

Top 7 Operating Systems From June 2012 to June 2013. Desktop Operating System Market Share, OS Platform Statistics 2003-2013

Re:Secure Boot ISN'T!

[Anonymous Coward]

It's sole purpose is to keep Linux off of x86 computers.

Sounds like a noble cause. Now we only need to keep Linux of ARM and PPC as well.

Re:Secure Boot ISN'T!

[readingaccount]

+3 interesting? What's wrong with Slashdot that posts with the most misinformation are modded up? And then other people take these modded up posts as gospel and keep repeating the FUD.

The problem is that a LOT of people on Slashdot basically live on Slashdot. It's their primary tech site, and hence they surround themselves with like-minded people who believe Linux will crush Microsoft on the desktop any day now, that Microsoft are dying, that no-one could like Windows/Microsoft by choice, that most people support Snowdon and his actions, and so on. It's one great bit echo chamber as opinions get reinforced by other like-minded posters, which strengthens their opinions and moves them into undeniable fact.

A place like ArsTechnica shows a vastly different situation, with far more people showing more varied opinions, such as liking Windows 8, preferring Microsoft technologies like C# to C++/Java, preferring Surface to iPad, and in this case, seeing the benefits of Secure Boot. Why do they do this? Because they aren't fucking brainwashed to believe what Slashdot tells them to believe.

I have no love for Microsoft. I dislike Windows 8 for the most part, I prefer cross-platform solutions and am indifferent to others. But what I do try to do is basic my opinions on the merits of the topic at hand - I've learnt to basically ignore most other opinions because way, way too many of them are based on emotion and (in Slashdot's case) hate to allow for an informed opinion.

Re:Secure Boot ISN'T!

[Anonymous Coward]

Yes, When Intel designed Secure Boot on their own, they thought.. Hmmm.. how can we screw over Linux. If you have any problems with Secure Boot, blame Intel, Microsoft is just an end user of the spec Intel created.

Speaking of how anti-Linux Intel is, how are those OpenSource nvidia and AMD graphics drivers treating you? Ohh sorry.. Intel has the best OpenSource support?.. who would have thought, being how anti-Linux they are.

Re: Secure Boot ISN'T!

[Anonymous Coward]

Hmmm. Everyone one of those links you provided involves windows and rootkits.

I only run FreeBSD and Linux. How does Secure Boot benefit me again? If I could generate my own keys, and not rely on any external sw/hw vendor, I could see some value there. Short of that, it is creating unnecessary obstacles for people who can live away from Microsoft.

Re:Secure Boot ISN'T!

[cold fjord]

Security has to constantly evolve to meet evolving problems. Hardware can't do that.

Is that really true? Firmware can be updated. Hardware components that can be read during system initialization can be added. There are at least some possibilities.

Re:Secure Boot ISN'T!

[Rashkae]

Interesting summary on that TDL4, thanks...

After all this time, i still remember the good ol' days having to clean up MonkeyB... it's nice to see the old timer ideas getting put to more modern/criminal use

Re:Secure Boot ISN'T!

[KingMotley]

MS could have protected itself from that without SecureBoot or any boot signing. MS could have made MBR writes from within their OS forbidden without an extreme warning.

And it still wouldn't protect the system from TDL4, while SecureBoot does. Your idea of how to secure the system would be broken in a matter of days, if that long for other malware.

Re:Secure Boot ISN'T!

[benjymouse]

The concept is solid enough, but the implementation is flawed. As a consequence of mandating that the factory burns in the signing key, it pretty much forces MS to sign competitor payload or be seen as anti-competitive.

This is where you fail. Microsoft does not sign competitor payload using a UEFI burned key. What Microsoft offers is that they will sign 2nd level boot loaders so that the Microsoft bootloader will accept to chain-load it. You cannot directly boot such a Microsoft signed bootloader or OS directly from UEFI.

Why is this significant? Because
1. It allows Microsofts bootload'er to make it *obvious* that a foreign OS is being booted. You cannot get around this because it is Microsofts code that gets the control before your code.
2. It allows Microsoft to *revoke* that specific signing if it turns out that it is being used for nefarious purposes.

This means your Microsoft install implicitly trusts software from Red Hat, Canonincal, VMware, Attachmate, and really anyone else who may enter the ring. There is no way that MS is providing adequate auditing to assure those paths aren't vulnerable and it shouldn't have to. Because it must be installed into firmware before an OS touches it, there is also *no* reasonable opportunity to provide any assurance of customer provided content like configuration.

Again, fail. The key validating software from Linux vendors (when they use Microsofts boot loader shim) is NOT in the firmware. It is part of Microsofts bootload'er (which is in turn validated by UEFI). If a 2nd level bootloader shim is being used for nefarious purposes, Microsoft can *revoke* that specific bootloader/OS. Thus, it is in the self-interest of distros to secure their part of the path.

As to that root kit you mentioned, MS could have protected itself from that without SecureBoot or any boot signing. MS could have made MBR writes from within their OS forbidden without an extreme warning. No OS bothers to do that, but it would have been actually a pretty defensible move on their part to mitigate root kits.

Defense in depth. Secure boot cannot prevent vulnerabilities, nor is it designed to do that. It is designed to prevent malicious code from gaining persistent foothold on a system, i.e. a guaranteed validated system after each boot. A kernel space exploit in any OS can lead to the attacker can write to otherwise off-limit areas. I trust that you are not advocating hard-shell-soft-core security.

The problem is that Secure Boot gives MS control of the entire ecosystem but in doing so missed an opportunity to provide something that *would* have worked better and allowed MS to avoid vouching for anything but their own software at boot time.

Linux Foundation could have stepped up as signing authority. Or Red Hat - they have the amp to do so. As it happens, both those organizations actively declined. There is *nothing* in UEFI that precludes anyone else from having their keys directly in the firmware. They would need to work with multiple vendors, however. That's why it would have been a job for LF or Red Hat.

Incidentally, Microsoft Hyper-V 3 (launches with Server 2012R2) support secure boot and has UEFI firmware. And yes, you can register your own keys. If VMWare/Xen/KVM were to offer the same this will soon become a silly discussion as this would pertain only to the lowest level hypervisor layer on a host. I could certainly fathom VMWare working with server vendors to have *their* key pre-registered.

Re:Secure Boot ISN'T!

[TheLink]

Yeah. More and more stuff is software nowadays. So much so that nowadays, Software is stuff you configure. Hardware is stuff other people configure ;).

To nongeeks a lot of PC stuff is hardware. To us less so. To some elite hacker most of it is software.

CPUs can be patched after release ( https://downloadcenter.intel.com/Detail_Desc.aspx?lang=eng&DwnldID=14303 ). Same goes for drives and even some mice.

Re:Secure Boot ISN'T!

[dargaud]

As to that root kit you mentioned, MS could have protected itself from that without SecureBoot or any boot signing. MS could have made MBR writes from within their OS forbidden without an extreme warning. No OS bothers to do that, but it would have been actually a pretty defensible move on their part to mitigate root kits.

Yes. I aways wondered why writing to the MBR wasn't possible only after going into BIOS, activating manually an option 'allow MBR write just for this boot', install your OS, reboot and it's secure again.

Re:Secure Boot ISN'T!

[Anonymous Coward]

The problem is that a LOT of people on Slashdot basically live on Slashdot. It's their primary tech site, and hence they surround themselves with like-minded people who believe Linux will crush Microsoft on the desktop any day now, that Microsoft are dying, that no-one could like Windows/Microsoft by choice, that most people support Snowdon and his actions, and so on. It's one great bit echo chamber as opinions get reinforced by other like-minded posters, which strengthens their opinions and moves them into undeniable fact.
A place like ArsTechnica shows a vastly different situation, with far more people showing more varied opinions, such as liking Windows 8, preferring Microsoft technologies like C# to C++/Java, preferring Surface to iPad, and in this case, seeing the benefits of Secure Boot. Why do they do this? Because they aren't fucking brainwashed to believe what Slashdot tells them to believe.

I can see what you're saying, but the Slasdot community is largely made up of REAL nerds - old school!
We remember rebooting Windows 3.11 for workgroups more than 20 times a day due to system crashes when trying to do real work.
We remember the amazement of playing sasteroid with no lag while installing slackware from floppies.
We remember the shit that Microsoft has pulled over the decades to crush superior products, especially ones like Linux and Java that threatened it's vendor lock-in stranglehold.
Fuck me I could go on and on...
Anyway, the point is, we weren't brainwashed...we lived through it and we remember.

Re:Secure Boot ISN'T!

[Anonymous Coward]

24MB?! Why so bloated? Ohh, Linux Hypervisors are near 200k lines of code and the FreeBSD hypervisor is around 2,000 lines. Now I see what's wrong with Linux. Why use 2,000 lines when 200,000 will work!

Re:Secure Boot ISN'T!

[ashpool7]

Why do the OEMs get to add keys? Why can't I load the key myself from UEFI or another side channel?

This is why secure boot triggers "do not want." Motherboard manufacturers are trying to wedge themselves in as gatekeepers where they were previously not.

Re:Secure Boot ISN'T!

[recoiledsnake]

Why can't I load the key myself from UEFI or another side channel?

You can.

http://blog.hansenpartnership.com/owning-your-windows-8-uefi-platform/

Typical Slashdot ignorance and blind hatred.

Re:Secure Boot ISN'T!

[ashpool7]

Except the OEM can prevent this from being an option for you.

Re:Secure Boot ISN'T!

[recoiledsnake]

Sure, but they will lose Windows 8 certification which gives them marketing, discounts etc.

That's why no OEM currently prevents that option. If you have a reference stating that one does, please provide it. Until then it's just speculation, an OEM can do anything in the future, including blocking Windows from running.

Re:Secure Boot ISN'T!

[ashpool7]

Sure... for x86 machines. I assume you mean

http://technet.microsoft.com/en-us/windows/dn168167.aspx

where they have four requirements, one of which is "They must allow the user to completely disable Secure Boot."

Now, for the Win RT version of Surface

http://support.microsoft.com/kb/2800988

"If the computer is running Windows RT, Secure Boot cannot be disabled."

Hmmmmmmmmmmmmmm

Re:Secure Boot ISN'T!

[recoiledsnake]

Windows 8 is not the same as Windows RT.

Windows 8 runs on only x86.

I love how the iPad gets a free pass but the barely selling WindowsRT is a big deal.

Re:Secure Boot ISN'T!

[ashpool7]

What *is* the same between the Surface Pro and the Surface (RT), is that UEFI and Secure Boot are being used.

Back to the original topic, this is why people do not want Secure Boot. Here is a company taking the standard and doing *exactly* what people were afraid the company would do with it. It's no longer "speculation."

Re:Secure Boot ISN'T!

[recoiledsnake]

What *is* the same between the Surface Pro and the Surface (RT), is that UEFI and Secure Boot are being used.

Back to the original topic, this is why people do not want Secure Boot. Here is a company taking the standard and doing *exactly* what people were afraid the company would do with it. It's no longer "speculation."

Is that so? Then why can anyone run Linux on a Surface Pro?

Or do you mean that WindowsRT is doing so well that it will kill PCs will do more harm to user freedom than an iPad? Looks like you are more optimistic about it than MS itself!

If people do not want Secure Boot then why are they falling over each other to buy the iPad with a locked bootloader? Or one of the many Android phones and tablets with locked bootloaders? Or are you just speculating about "people"?

It's like saying Antivirus programs will one day prevent all executables from running just because they have the capability to block any executable and have successfully blocked some.

Re:Secure Boot ISN'T!

[ashpool7]

You're not forced to install antivirus programs nor is there a scheme to prevent you from removing them.

I'm not speculating about "people," I'm talking about the "people" accused of turning their brains off when Secure Boot gets brought up. These are the same people who don't like the locked bootloaders on the iPad and especially on Android phones and tablets.

Re:Secure Boot ISN'T!

[recoiledsnake]

You're not forced to install antivirus programs nor is there a scheme to prevent you from removing them.

...yet.. just like secure boot on x86 PCs.
Boot kits are prevalent on PCs and Secure Boot prevents it while allowing the small percentage of enthusiasts to install alternative OSes on x86.
Just because some person wanting to install some OS can't bothered to uncheck a checkbox doesn't mean that hundreds of millions of PC users must be subject to undetectable rootkits.

Re:Secure Boot ISN'T!

[ashpool7]

I know you want to be like x86 != ARM, which is fair, but UEFI == UEFI

It would be great if you could just uncheck a checkbox at boot time, but this standard was made so that you can remove that checkbox and still claim standards compliance. That's the rub.

FUD Alert! ME! I'm scared of Linux!!!

[Anonymous Coward]

Guys, seeing this shit concerns me in the sense that I'll get a MOBO and a processor for my homemade Linux box and only to find out I can't install Linux - or have serious issues that are beyond my capabilities.

So, If I go an buy the latest and greatest Motherboard and processor and whatnot, what bullshit do I have to deal with?

Sorry for the Troll subject line, but I want an answer - not just for me, but for all of us Linux users - yes, we exist.
 

Re:FUD Alert! ME! I'm scared of Linux!!!

[rubycodez]

it's not just Linux users - I want my computer to boot on any code * I and no one else * tells it to boot.

If I want Microsoft's opinion on suitability of code for booting I'll beat it out of them with a lead pipe.

Re:FUD Alert! ME! I'm scared of Linux!!!

[KingMotley]

I was going to write a technical book called Secure Boot for dummies, but I got as far as:
Go to your BIOS, and check the box that says "Disable Secure Boot". Then click save.

Then I realized I was done. Now on sale @Amazon for $24.95!

Re:FUD Alert! ME! I'm scared of Linux!!!

[Anonymous Coward]

"Apply magic here. Now you're done".

First of all, UEFI does not have BIOS, unless you are in compatibility mode. Maybe you mean UEFI setup? In that case, I've been trying for months to find anyone who can tell me how to enter UEFI setup. I've tried F1, F2, F3, Esc, Del... All the usual keys, and none work.

Even Google can't tell me, I find a lot of people like you, who claim that once you've used the correct level 60 spell, the rest is easy, but nobody who are willing to tell how to get to setup in the first place. Searching for "how to enter uefi setup" and similar just gives a lot of pages telling me to buy Windows 8 (in which case I wouldn't need to turn off secure boot in the first place), and then go into control panel and select reboot to UEFI setup.

I don't think it was about Linux on x86...

[Junta]

I think it more likely it was about Android on ARM. MS didn't want to end up selling some fantastic hardware device and getting all the 'momentum' wiped out by Android loads so people could run with a platform with some semblance of an ecosystem going (though I've not seen an RT device I'd find interesting regardless of software). x86 got to come along for the ride so that MS would be doing things in a nicely consistent fashion with more credibility on the matter of rootkit mitigation. It does mitigate rootkits, rootkits now have to be more complicated than they had to be previously. The components available to construct a rootkit may be unable to avoid tipping off a careful user that something is weird during the boot process (e.g. if SuSE's logo appears during a pure Windows boot, that would be a sign that something is afoot). Of course, the typical user that doesn't notice or has been trained to shrug off 'weird stuff' during the boot process (e.g. a lot of security suites end up branding boot process as they do their own FDE thing, so seeing a lizard on screen may make most people assume it's security software).

Can Microsoft remain relevant?

[EzInKy]

Secure Boot is just another attempt by Microsoft to maintain their near monopoly on computer operating systems. They are failing to compete, severely, so have no choice but to find some method that will force people to continue to be blessed by Microsoft before being free to use the devices they purchased. Take the planned new XBox as an example of their obsession with control.

As much as I respected Nokia for their hardware manufacturing prowess, I have to admit I am a cheerleader for their demise as the price for jumping in bed with the devil. I still haven't found a decent device to replace my N900. Search for "unlocked cellphone with hardware keyboard" and you will understand the problem. Oracle, it seems, will be next to join the illustrious many who have died at the hand of Microsoft.

Re:Can Microsoft remain relevant?

[KingMotley]

They are failing to compete, severely

I agree. Microsoft should have done something long before Linux hit 0.97% marketshare.

Keyboard case for your phone

[tepples]

Search for "unlocked cellphone with hardware keyboard" and you will understand the problem.

Couldn't it be solved by making a case with a slide-out Bluetooth keyboard? Google tells me that such cases exist for iPhone 4/4S and Galaxy S3; I don't know if any single chassis shape for any other model has enough market share to merit making a compatible case.

I think it's a good move

[msobkow]

From my perspective, securing the boot loader is the first step. Then you need a binary checker (which has been around for a while), and a trusted vendor distributing the updates and binary checksums. With those two pieces in place, you can at least have some modicum of insurance that your binaries haven't been compromised since they were released by the vendor.

I wouldn't worry about custom executables, though -- how is a hacker supposed to even know they exist unless they've got inside info on your company and the programs they write?

some responsibility is on owner

[Chirs]

As I understand it, the signed redhat bootloader will only boot redhat kernels (which in turn will extend the chain of trust upwards). The generic linux bootloader will boot anything, but will require proof from a person that they acknowledge that it is booting that thing (in order to prevent a "blue pill" type attack).

In this instance, the person with physical control over the system could load an arbitrary kernel, but it is difficult for an attacker to install a hidden rootkit.

zero vendors on x86

[Chirs]

Secure boot on ARM *prohibits* the user from modifying the signing keys or turning it off.

Re:zero vendors on x86

[Microlith]

To be more accurate, Microsoft's system vendor requirements for Windows 8 on ARM (Windows RT) require that it not be possible to turn off secure boot. Nothing about secure boot inherently makes it impossible to turn off. Microsoft is simply forcing their will on the OEMs who then take that control away from you.

The best thing to do is to let Windows RT die in the market.

yes, based on previous experience

[Chirs]

WinRT ARM devices already lock out the user from disabling secure boot or modifying the keys.

Re:yes, based on previous experience

[sofar]

But this is not UEFI secure boot, but a completely different thing.

MS lock in is bad when they have an app store

[Joe_Dragon]

MS lock in is bad when they have an app store and may try to make it app store only / kill off all of the older apps.

Also why code for metro when you can code that will run on windows , mac and Linux.

UEFI "Secure" Boot == You Don't Own It!

[Anonymous Coward]

If you purchase a system that cannot disable secure boot, then you are ONLY renting/leasing the system - you do not own it! JUST SAY NO!!!

Re:UEFI "Secure" Boot == You Don't Own It!

[Anonymous Coward]

Who sells such a system?

Of course this is happening

[Lirodon]

Microsoft only endorses SUSE because Novell/Attachmate pays them off for the patents that they've allegedly infringed.

Ridiculous.

[VortexCortex]

I understand the software writers don't want to marginalize themselves in case servers adopt UEFI. However, there are zero security benefits of UEFI, versus booting part of your OS right from the BIOS/Firmware. It's up to the OS's bootloader to kick of an encryption chain after UEFI loads. So, put the damn bootloader in the firmware with Coreboot.

The way my setup works is that Coreboot has a bootstrap loader for my OS in firmware. The BIOS requrires a password to access it, and enable the flashing of firmware. Type password, "Enable Firmware Flash On Next Boot" option. No screwy hex code you're bound to mess up several times. My boot protocol uses public key crptography so that the custom multi-boot loader can handle any number of OS updates. The 2nd stage OS loader changes, it can include the signature of via key that's paired with the OS's 1st stage firmware boot loader. DONE. All we need is a standardized way for BIOS to flash a small part of the OS loader at OS install, and then any OS can be just as secure as secure boot, without ANY hierarchy of control -- The OS devs can own all the keys they use to secure and load their own OS. It's not like the chips don't have the memory now -- Shit, on new desktop systems the firmware has gaudy graphics, animations, and sounds -- The damn motherboard runs a stipped down Linux or BSD to prestent you the BIOS config options!

So, think about this. Coreboot + Key/Signing you already have to have in the OS loader is just as secure as UEFI, except there's no grand central Microsoft authority who says what OS can and can not install on the hardware, or to pressure hardware makers into bowing to the demands of the Windows requirements. If there is a bug in the BIOS or hardware that lets it rewrite firmware from software without permission, then it exploits UEFI or Coreboot equally -- How do you think UEFI is implemented -- IN FIRMWARE? Hell, I have the option with Coreboot to use UEFI boot if I want. However, I can also remove that shite, or even have the firmware setup legacy BIOS interrupt tables for booting old OS's like MSDOS, DR DOS, etc. Currently, I have my system config in my Coreboot, so it doesn't search for shit, just loads my OS and runs instantly at power up.
Coreboot w/ OS + SSD = Milliseconds to boot; Beat that, Security Theater Boot.

They should rename that shite, Microsoft Controlled Boot, because it is, for all intents and purposes. Stop and think. How can a sysop like me figure out a more flexible system that's just as secure as SecureBoot, more easy to use and maintain, and even adds security to tons of legacy x86 hardware -- Yet all those well paid folks who's only job was to engineer a secure boot standard "UEFI", came up with some restrictive shit that in effect gives Microsoft more control of the hardware and software arena? NO. ACTUALLY THINK. SEE?

Re:Ridiculous.

[Anonymous Coward]

NO. ACTUALLY THINK.

Maybe you should Actually Read. The Microsoft Certification Requirements, that is. The ones that explicitly require manufacturers who want to put the 'certified for windows' sticker on their hardware (read: everyone, especially if windows is already installed on it) to allows end-users to either add their own keys to the Secure Boot keystore, or wipe the keystore and add their own keys (including MS key, making the two options fundamentally equivalent). This applies to anyhting that doesn't run RT.

Basically, MS REQUIRES hardware vendors to disable lock-in in order to sell computers with Windows 8 installed.

YES

[Anonymous Coward]

I can't believe this isn't blindingly obvious. Microsoft knows they don't need to "eradicate" their competitors; they merely need to make it inconvenient to deal with them.

The real question

[hendrikboom]

The big question which the original article doesn't address is:

Does SuSE expect the owner of the machine to specify the top-level signing keys? Or does it expect Microsoft's to be frozen into the hardware?

Some details about SUSE' approach ...

[mge1512]

As a number of valid questions have been asked here, I'd like to point you to details about our approach:

(1) https://www.suse.com/communities/conversations/uefi-secure-boot-overview/
(2) https://www.suse.com/communities/conversations/uefi-secure-boot-plan/
(3) https://www.suse.com/communities/conversations/uefi-secure-boot-details/

Those blogs have been published around the time when we had decided to implement UEFI Secure Boot in SUSE Linux Enterprise 11 SP3. For those who like to understand things visually, #3 has a graphic even, ...

Kind regards - Matthias G. Eckermann / MgE