×

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

Thank you!

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

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

Secure Boot Coming To SuSE Linux Servers

Unknown Lamer posted about 9 months ago | from the hold-the-key dept.

SuSE 135

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

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

135 comments

Secure Boot solves a nonissue (1)

Anonymous Coward | about 9 months ago | (#44220907)

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

Re:Secure Boot solves a nonissue (1)

webmistressrachel (903577) | about 9 months ago | (#44221159)

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

Re:Secure Boot solves a nonissue (1, Insightful)

mystikkman (1487801) | about 9 months ago | (#44221239)

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 [slashdot.org]

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 (4, Funny)

wbr1 (2538558) | about 9 months ago | (#44221925)

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

PopeRatzo (965947) | about 9 months ago | (#44221951)

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

evilviper (135110) | about 9 months ago | (#44222707)

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

evilviper (135110) | about 9 months ago | (#44222705)

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

Anonymous Coward | about 9 months ago | (#44221531)

Too much gay sex, and that's a fact.

The new Microsoft-NSA hybrid owns us all (0, Troll)

hessian (467078) | about 9 months ago | (#44220943)

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

Anonymous Coward | about 9 months ago | (#44221149)

Fuck you, fairy faggot. The US government will own your ass with or without cooperation from any entity. I hope they put all you fags against the wall when they finally lower the boom.

Re:The new Microsoft-NSA hybrid owns us all (0)

Anonymous Coward | about 9 months ago | (#44222653)

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? (0)

Anonymous Coward | about 9 months ago | (#44220965)

Another jumps in bed with the devil.

SecureBoot is incomplete (2, Insightful)

Junta (36770) | about 9 months ago | (#44220969)

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 (3, Informative)

bws111 (1216812) | about 9 months ago | (#44221083)

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 (2, Insightful)

Junta (36770) | about 9 months ago | (#44221187)

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 (5, Insightful)

KiloByte (825081) | about 9 months ago | (#44221587)

It complicates use of non-microsoft OSes

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

Re:SecureBoot is incomplete (2)

John.Banister (1291556) | about 9 months ago | (#44221623)

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

cold fjord (826450) | about 9 months ago | (#44221713)

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

Anonymous Coward | about 9 months ago | (#44221809)

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

benjymouse (756774) | about 9 months ago | (#44222755)

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.

some responsibility is on owner (3, Interesting)

Chirs (87576) | about 9 months ago | (#44221909)

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.

good as MS ideas like metro on servers is dumb (1)

Joe_Dragon (2206452) | about 9 months ago | (#44221037)

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

Nerdfest (867930) | about 9 months ago | (#44221375)

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.

SecureBoot has no place as implemented (1)

sethstorm (512897) | about 9 months ago | (#44221075)

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 (1, Insightful)

bws111 (1216812) | about 9 months ago | (#44221109)

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 (3, Insightful)

0123456 (636235) | about 9 months ago | (#44221139)

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

bws111 (1216812) | about 9 months ago | (#44221211)

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

epyT-R (613989) | about 9 months ago | (#44221261)

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

Re:SecureBoot has no place as implemented (0)

recoiledsnake (879048) | about 9 months ago | (#44221277)

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

bws111 (1216812) | about 9 months ago | (#44221297)

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

Re:SecureBoot has no place as implemented (0)

Anonymous Coward | about 9 months ago | (#44221483)

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

bws111 (1216812) | about 9 months ago | (#44221539)

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

Anonymous Coward | about 9 months ago | (#44221829)

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

sofar (317980) | about 9 months ago | (#44222175)

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

recoiledsnake (879048) | about 9 months ago | (#44221221)

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

Nerdfest (867930) | about 9 months ago | (#44221389)

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

Anonymous Coward | about 9 months ago | (#44222243)

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

Anonymous Coward | about 9 months ago | (#44222697)

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.

zero vendors on x86 (1)

Chirs (87576) | about 9 months ago | (#44221915)

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

Re:zero vendors on x86 (1)

Microlith (54737) | about 9 months ago | (#44222665)

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.

Re:SecureBoot has no place as implemented (1)

Microlith (54737) | about 9 months ago | (#44222709)

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

Anonymous Coward | about 9 months ago | (#44221153)

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

Re:SecureBoot has no place as implemented (1)

recoiledsnake (879048) | about 9 months ago | (#44221195)

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

mystikkman (1487801) | about 9 months ago | (#44221183)

The words "Secure Boot" seems to suddenly turn off the logic circuits in the brains of many otherwise intelligent folks and make them say dumb things and also cause selective amnesia. I have no other explanation for this continued ignorance on such a large scale for such a long time. The anti-MS FUD articles and modded up FUD and hating comments also don't help and serve to perpetuate the ignorance.

Re:SecureBoot has no place as implemented (1)

Junta (36770) | about 9 months ago | (#44221235)

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

recoiledsnake (879048) | about 9 months ago | (#44221309)

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

Junta (36770) | about 9 months ago | (#44221349)

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

recoiledsnake (879048) | about 9 months ago | (#44221381)

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

Anonymous Coward | about 9 months ago | (#44221533)

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

KingMotley (944240) | about 9 months ago | (#44222259)

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

Anonymous Coward | about 9 months ago | (#44221863)

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 (0, Insightful)

Anonymous Coward | about 9 months ago | (#44221485)

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

To be fair... (-1)

Anonymous Coward | about 9 months ago | (#44221559)

Most of the anti-secureboot posts sound like rabid anti-ms rants and most of the pro secure boot posts actually try to lay out a coherent thought.

There are valid and thoughtful criticisms of the SecureBoot model failings, but they tend to get drowned out by the 'M$ is EVIL, WINDOWS 8 SUXORS!' comments. It's easy to see how someone might be swayed by the pro-secureboot posts and just give up on ever expecting a *good* reason to dislike secureboot.

Re:To be fair... (-1)

Anonymous Coward | about 9 months ago | (#44221719)

Oh look! There's another one!

How much are you getting paid to tell us how great "Secure" Boot is?

Re:SecureBoot has no place as implemented (2)

vux984 (928602) | about 9 months ago | (#44221125)

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

0123456 (636235) | about 9 months ago | (#44221161)

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 (3, Insightful)

Rockoon (1252108) | about 9 months ago | (#44221225)

Unless the hardware manufacturer won't let you.

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

Re:SecureBoot has no place as implemented (1)

epyT-R (613989) | about 9 months ago | (#44221317)

Considering technology trends today, it is a likely possibility.

Re:SecureBoot has no place as implemented (1)

lister king of smeg (2481612) | about 9 months ago | (#44221509)

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

Anonymous Coward | about 9 months ago | (#44221981)

Can say the same thing about Android and iOS systems.

yes, based on previous experience (2)

Chirs (87576) | about 9 months ago | (#44221921)

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

Re:yes, based on previous experience (1)

sofar (317980) | about 9 months ago | (#44222185)

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

Re:SecureBoot has no place as implemented (1)

bws111 (1216812) | about 9 months ago | (#44221287)

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

vux984 (928602) | about 9 months ago | (#44221291)

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

Microlith (54737) | about 9 months ago | (#44222643)

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.

When people talk about Secure Boot... (-1)

Anonymous Coward | about 9 months ago | (#44221077)

I just want to kill the stupid Traffic Enforcement cop responsible for that nonsense.

If you can leave the car in place, then what the fuck is the problem? Huh? You tell me.

Jerkass money grubbers.

Secure Boot ISN'T! (2, Insightful)

kawabago (551139) | about 9 months ago | (#44221179)

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.

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

Junta (36770) | about 9 months ago | (#44221329)

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

Re:Secure Boot ISN'T! (-1)

Anonymous Coward | about 9 months ago | (#44221335)

Paranoia, it's a disease, you got it, go see a shrink, after a few years of psicotherapy you should be fine

Re:Secure Boot ISN'T! (4, Informative)

recoiledsnake (879048) | about 9 months ago | (#44221351)

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 [chmag.in]

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

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

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 it monitors for write operations. In case of write operation targeted at the MBR sector, it is changed to read operation. This way it is trying to bypass repair operation by Security Products

The OEMs offered to add Red Hat and Ubuntu etc.'s keys but they refused since they didn't want to have an exclusive solution and neither did they want to be in the position of signing keys. If the Linux foundation stepped up, the OEMs will gladly add their master key to UEFI, but it doesn't want to.

Is there something about UEFI and secureboot that causes many folks' brains to be absolutely switched off? Or is the FUD successful in muddling the facts? Or maybe the whole issue is too complex for folks to understand. But it's Linux users we're talking about, not "M$ Windoze sheeple". About 80% of the posts on here and on Reddit about UEFI Secure Boot are simply false and extremely misleading which perpetuates the cycle of ignorance and spreading FUD. Very disappointing, I expected that people would be smart on here, but they seem to be ignoring facts "la la la" in the hurry to feel victimized and jump on the anti-MS bandwagon. Post any anti-MS crap and it's automatically modded up, no wonder the site appears to be dying with very few comments on most articles these days.

  Posters like bmo, symbolset, tuple666, Zero__Kelvin, LordLimeCat, Jeremiah Cornelius, UnknowingFool, rtfa-troll, binarylarry, MightyMartian, drinkypoo, pieroxy and a whole bunch of others have ruined Slashdot beyond repair(with the help of moderators) and seem to suffer from this affliction: http://linux.slashdot.org/story/09/07/25/1757253/linus-calls-microsoft-hatred-a-disease [slashdot.org]

Re:Secure Boot ISN'T! (2)

csumpi (2258986) | about 9 months ago | (#44221385)

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! (1)

Junta (36770) | about 9 months ago | (#44221471)

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! (1)

KingMotley (944240) | about 9 months ago | (#44222311)

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! (2)

benjymouse (756774) | about 9 months ago | (#44222919)

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! (1)

readingaccount (2909349) | about 9 months ago | (#44221779)

+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! (0)

Anonymous Coward | about 9 months ago | (#44222097)

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! (1)

Rashkae (59673) | about 9 months ago | (#44222261)

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! (0)

Anonymous Coward | about 9 months ago | (#44221363)

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! (0)

Anonymous Coward | about 9 months ago | (#44221731)

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! (0)

Anonymous Coward | about 9 months ago | (#44222007)

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! (1)

cold fjord (826450) | about 9 months ago | (#44222139)

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! (1)

TheLink (130905) | about 9 months ago | (#44222959)

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 [intel.com] ). Same goes for drives and even some mice.

FUD Alert! ME! I'm scared of Linux!!! (0)

Anonymous Coward | about 9 months ago | (#44221301)

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!!! (1)

rubycodez (864176) | about 9 months ago | (#44221449)

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!!! (1)

KingMotley (944240) | about 9 months ago | (#44222319)

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!

Can Microsoft remain relevant? (1)

EzInKy (115248) | about 9 months ago | (#44221419)

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.

Keyboard case for your phone (1)

tepples (727027) | about 9 months ago | (#44221537)

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.

Re:Can Microsoft remain relevant? (1)

KingMotley (944240) | about 9 months ago | (#44222325)

They are failing to compete, severely

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

cheap authentic NFL jerseys wholesale (-1, Offtopic)

jerseyes (2975711) | about 9 months ago | (#44221469)

All phones their very own benefits and drawbacks, however when you get a glance at the Apple iPhone,Cheap jerseys [jerseyesstore.com] you already know that you may have Air Max located something great. And when you start making use of the iphone 4, you won't would like to use anything else. nfl jerseys Cheap [jerseyesstore.com] But there is however a great deal you could do with it--exactly where will you commence? Cheap nike nfl jerseys [jerseyesstore.com] Read on for some ideas.In case you are a mother or father and you do not want your child looking at "mature" stuff in your telephone, all you need to do is switch on the parental management feature. To make with this feature, all you have to do is head to settings, tap on "common" after which tap on "limitations".If your phone has iced and forcing on the Rest/Wake button will not be working, there is another choice.

I think it's a good move (1)

msobkow (48369) | about 9 months ago | (#44221717)

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?

FUD (-1)

Anonymous Coward | about 9 months ago | (#44221893)

Fear, uncertainty and doubt.

Secure Boot is nothing more than FUD. Secure Boot is entirely FUD. Secure Boot exists for the sole purpose of generating never ending stream of FUD.

I know it, you know it and Microsoft knows it.

This isn't an evolution in personal computing security, it's a carefully crafted plan by Microsoft set to destroy all potential competition and drive 'personal' computing back into the stone age for another decade.

It must be stopped. Quickly, completely and with prejudice.

MS lock in is bad when they have an app store (1)

Joe_Dragon (2206452) | about 9 months ago | (#44222055)

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! (0)

Anonymous Coward | about 9 months ago | (#44222269)

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

Of course this is happening (1)

Lirodon (2847623) | about 9 months ago | (#44222343)

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

Ridiculous. (2)

VortexCortex (1117377) | about 9 months ago | (#44222939)

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. [coreboot.org]

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?

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

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

Submission Text Formatting Tips

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

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

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

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

Loading...