Secure Boot Coming To SuSE Linux Servers 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.'"
Secure Boot solves a nonissue (Score:1)
The new hotness is memory-resident. Everything old is new again.
Re: (Score:2)
1,4Gb downloaded already, and only 11 Comments? What's wrong with this place? ;-)
Re: (Score:2, Insightful)
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 vo
Re:Secure Boot solves a nonissue (Score:5, Funny)
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: (Score:2)
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: (Score:2)
I'd say it was roughly around the time that your account was created, Ratzo...
Re: (Score:2)
I know, ain't I a stinker?
I should be a little more careful with my powers.
Re: (Score:2)
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!
Re: (Score:2)
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-X
SecureBoot is incomplete (Score:3, Insightful)
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 (Score:4, Informative)
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: (Score:3, Insightful)
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 executabl
Re:SecureBoot is incomplete (Score:5, Insightful)
It complicates use of non-microsoft OSes
And that's the whole reason SecureBoot is getting pushed onto manufacturers.
Re: (Score:2)
Re: (Score:2)
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: (Score:3)
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 match
Re: (Score:3, Insightful)
what you are booting is signed by someone you trust
Or Microsoft.
Re: (Score:2)
If you don't trust Microsoft then you should of course not trust their key either.
some responsibility is on owner (Score:4, Interesting)
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.
Re: (Score:2)
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
good as MS ideas like metro on servers is dumb (Score:2)
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: (Score:1)
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: (Score:1)
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 (Score:2)
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: (Score:1, Insightful)
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 (Score:4, Insightful)
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: (Score:2)
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: (Score:2)
..and when all hardware vendors refuse to allow user generated root keys?
Re: (Score:1)
..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: (Score:2)
And why, exactly, would they do that? Especially server manufacturers? Your suggestion is pure FUD.
Re: (Score:2)
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: (Score:2)
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
Re: (Score:2)
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 manage
Re: (Score:2)
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: (Score:1)
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
Re: (Score:2)
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.
zero vendors on x86 (Score:2)
Secure boot on ARM *prohibits* the user from modifying the signing keys or turning it off.
Re: (Score:2)
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: (Score:2)
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 ha
Re: (Score:2)
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: (Score:1)
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
Re: (Score:2)
"...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 g
Re: (Score:2)
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: (Score:2)
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 he
Re: (Score:1)
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: (Score:2)
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 t
Re: (Score:2)
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: (Score:1)
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 k
Re: (Score:2)
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: (Score:3)
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: (Score:2)
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 (Score:4, Insightful)
Unless the hardware manufacturer won't let you.
Isn't this argument essentially fear, doubt, and uncertainty?
Re: (Score:2)
Considering technology trends today, it is a likely possibility.
Re: (Score:2)
no its experience and logic. just look at how they have already locked you out of arm based windows devices.
yes, based on previous experience (Score:3)
WinRT ARM devices already lock out the user from disabling secure boot or modifying the keys.
Re: (Score:2)
But this is not UEFI secure boot, but a completely different thing.
Re: (Score:2)
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: (Score:1)
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 pas
Re: (Score:2)
Which hardware manufacturer?
Re: (Score:2)
Re: (Score:2)
Just checking, thanks. I'll buy more tin foil, just in case.
Re: (Score:3)
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: (Score:2)
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
Secure Boot ISN'T! (Score:2, Insightful)
I don't think it was about Linux on x86... (Score:3)
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 r
Re:Secure Boot ISN'T! (Score:5, Informative)
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
Re: (Score:3)
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: (Score:2)
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
Re: (Score:2)
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: (Score:3)
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 b
Re: (Score:2)
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: (Score:1)
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 s
Re: (Score:2, Interesting)
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
Re: (Score:2)
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: (Score:1)
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: (Score:2)
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/ [hansenpartnership.com]
Typical Slashdot ignorance and blind hatred.
Re: (Score:1)
Except the OEM can prevent this from being an option for you.
Re: (Score:2)
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: (Score:1)
Sure... for x86 machines. I assume you mean
http://technet.microsoft.com/en-us/windows/dn168167.aspx [microsoft.com]
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 [microsoft.com]
"If the computer is running Windows RT, Secure Boot cannot be disabled."
Hmmmmmmmmmmmmmm
Re: (Score:2)
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: (Score:1)
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: (Score:2)
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
Re: (Score:1)
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: (Score:2)
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: (Score:1)
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.
Re: (Score:2)
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 [statcounter.com]. Desktop Operating System Market Share [hitslink.com], OS Platform Statistics 2003-2013 [w3schools.com]
Re: (Score:2)
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: (Score:2)
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.
Can Microsoft remain relevant? (Score:2)
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 p
Keyboard case for your phone (Score:2)
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: (Score:2)
They are failing to compete, severely
I agree. Microsoft should have done something long before Linux hit 0.97% marketshare.
I think it's a good move (Score:2)
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 co
MS lock in is bad when they have an app store (Score:2)
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.
Of course this is happening (Score:1)
Ridiculous. (Score:3)
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?
The real question (Score:2)
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 ... (Score:1)
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/ [suse.com]
(2) https://www.suse.com/communities/conversations/uefi-secure-boot-plan/ [suse.com]
(3) https://www.suse.com/communities/conversations/uefi-secure-boot-details/ [suse.com]
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,
Re: (Score:2)
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: (Score:2)
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!