×

Announcing: Slashdot Deals - Explore geek apps, games, gadgets and more. (what is this?)

Thank you!

We are sorry to see you leave - Beta is different and we value the time you took to try it out. Before you decide to go, please take a look at some value-adds for Beta and learn more about it. Thank you for reading Slashdot, and for making the site better!

The Linux Foundation's UEFI Secure Boot Pre-Bootloader Delayed

Soulskill posted about 2 years ago | from the threatening-to-become-post-bootloader dept.

Microsoft 179

hypnosec writes "The Linux Foundation's plans for releasing a signed pre-bootloader that will enable users to install Linux alongside Windows 8 systems with UEFI have been reportedly delayed. The Foundation proposed a signed pre-bootloader that will chain-load a bootloader which, in turn, will boot the desired operating system, thus keeping Linux installations for novice users as simple as it was before. Further, this particular component is meant for small-time Linux distros which otherwise wouldn't have the required expertise or resources to develop their own system to tackle the secure boot issue. This was going as per plans up until Linux kernel maintainer James Bottomley disclosed that he has been having rather bizarre experiences with Microsoft sysdev centre. Bottomley said, 'The first time I sent the loader through, it got stuck (it still is, actually). So I sent another one through after a week or so. That actually produced a download, which I've verified is signed (by the MS UEFI key) and works, but now the Microsoft sysdev people claim it was "improperly" signed and we have to wait for them to sort it out. I've pulled the binary apart, and I think the problem is that it's not signed with a LF [Linux Foundation] specific key, it's signed by a generic one rooted in the UEFI key. I'm not sure how long it will take MS to get their act together but I'm hoping its only a few days." Update: 11/21 14:22 GMT by U L : See the Original weblog post, and one interesting tidbit: Microsoft banned bootloaders licensed under the GPLv3 and "similar open source licenses."

Sorry! There are no comments related to the filter you selected.

Ehh? (0)

Anonymous Coward | about 2 years ago | (#42053105)

How long until crackers will be able to install this loader to load their virtual machine that will run a compromised Windows 8?

Of course it was defective. (1, Insightful)

Anonymous Coward | about 2 years ago | (#42053509)

Which part of "Microsoft Product" did they not understand?

Somebody should sue Microsoft anyway (5, Insightful)

Anonymous Coward | about 2 years ago | (#42053127)

At least in Europe they'd succeed.

Not surprised (3, Insightful)

gagol (583737) | about 2 years ago | (#42053143)

Somehow, thay can sign town of apps and drivers on a regular basis, but signing teeny tiny code for FSF got screwed... It only validate, in my opinion, this whole secure boot shit was meant to give alternative OS a hard time.

Re:Not surprised (5, Funny)

Ynot_82 (1023749) | about 2 years ago | (#42053179)

town of apps

So that's why they called their UI Metro.
Always wondered about that

Re:Not surprised (1)

gagol (583737) | about 2 years ago | (#42053189)

Good catch, typing in bed is never optimal... I meant "tons" for the record.

Re:Not surprised (5, Funny)

wonkey_monkey (2592601) | about 2 years ago | (#42053219)

Good catch, typing in bed is never optimal...

You're holding it wr- nevermind.

Re:Not surprised (0)

Anonymous Coward | about 2 years ago | (#42053633)

town of apps

So that's why they called their UI Metro.
Always wondered about that

They certainly let the UI designers "go to town" on Metro (or whatever it's called now ... Bob 2012?)

Not surprised at all (4, Interesting)

boorack (1345877) | about 2 years ago | (#42053223)

As of now we know that Win8 is vulnerable to a huge chunk of malware designed for older versions of Windows. This "UEFI Secure Boot" does not prevent it at all. I suspected earlier that UEFI Secure Boot wasn't designed to make PCs more secure but rather to lock down PCs, so novice users trying to check out some Linux distribution will have tough time doing so. This fiasco makes me sure that this was the case and makes me wonder why antitrust authorities don't do anything about this. This is potentially more harmful than MSIE case after all.

Re:Not surprised at all (2)

Toreo asesino (951231) | about 2 years ago | (#42053389)

As of now we know that Win8 is vulnerable to a huge chunk of malware designed for older versions of Windows.

Citation (badly) needed.

Re:Not surprised at all (5, Informative)

rsmith-mac (639075) | about 2 years ago | (#42053455)

As of now we know that Win8 is vulnerable to a huge chunk of malware designed for older versions of Windows.

Secure Boot was designed to block malware from successfully inserting itself into the boot chain to bypass OS security measures, and that's it. Beyond that it's up to the OS to block malware from running in ring 0 or ring 3, which comes down to AV scanning, code signing, and any privilege escalation exploits abused by malware. Secure Boot closes off one important vector for malware, not all of them.

Re:Not surprised at all (4, Insightful)

Paul Jakma (2677) | about 2 years ago | (#42053665)

What people really want is that their running code is verified to be running the way it is supposed to be. This requires formal proofs of code operation - which is notoriously difficult (and impossible to do generally with arbitrary software). SecureBoot does not give that, it only attests the code image *started* as the one it was supposed to be, according to the trust anchor. SecureBoot can however make the lives of ordinary users difficult. For now, we have the ability to use our own trust anchor, or none at all. Microsoft can't yet afford to block users from running all the non-SecureBoot OSes - as these include older Windows releases.

It's sad that so many Linux distributions and foundations are going along with this.

Re:Not surprised at all (0)

recoiledsnake (879048) | about 2 years ago | (#42054087)

SecureBoot does not give that, it only attests the code image *started* as the one it was supposed to be, according to the trust anchor..

Secure boot can give that, if the code image checks the signatures of the drivers and the kernel it loads and the kernel can check the signatures of the executables it runs and not load anything else that is not signed. Lets say you set up such a system today, you can be sure after 1 year that the same binaries are loading and have not been replaced with malicious ones. Even if malware was loaded into memory at runtime, cleanup will just involve a reboot + replacing any drivers, executables, kernel etc that fail the signature check(ignoring changes to data i.e).

Re:Not surprised at all (1)

Chrisq (894406) | about 2 years ago | (#42054553)

SecureBoot does not give that, it only attests the code image *started* as the one it was supposed to be, according to the trust anchor..

Secure boot can give that, if the code image checks the signatures of the drivers and the kernel it loads and the kernel can check the signatures of the executables it runs and not load anything else that is not signed. Lets say you set up such a system today, you can be sure after 1 year that the same binaries are loading and have not been replaced with malicious ones. Even if malware was loaded into memory at runtime, cleanup will just involve a reboot + replacing any drivers, executables, kernel etc that fail the signature check(ignoring changes to data i.e).

No, once malware has run you have to assume the worst; that software has been compromised and verifies false signatures. If you had a system that never allowed new signers (all signatures built into the kernel) then you would be right, but it would be inflexible. Also you can't just include executables in your checks; anything that could be interpreted also needs verification.

Re:Not surprised at all (3, Interesting)

hAckz0r (989977) | about 2 years ago | (#42054421)

Yes they can and will. That is all a part of the 'forced upgrade' plan to wealth. Microsoft will do most anything to make running an old OS more painful so you will be forced to buy from them again and again. I listen to the trials and tribulations of my coworkers trying to keep their ageing xp machines running on a daily basis. One is forced by M$ to keep the machine off the net because M$ decided that his license (part of a larger sitewide license) is now counterfit. Its used for malware testing so it does not belong on the net in the first place, but restoring and re-patching it every time it is used is a royal pain.

Re:Not surprised at all (5, Insightful)

Anonymous Coward | about 2 years ago | (#42053707)

Secure Boot closes off one nowadays almost completely irrelevant vector for malware, not all of them.

FTFY.

Re:Not surprised at all (2)

LordLimecat (1103839) | about 2 years ago | (#42054211)

The "best" (hardest to remove) rootkits still infect the boot sector. I just had to deal with one a few days ago.

Re:Not surprised at all (1)

Anonymous Coward | about 2 years ago | (#42055133)

Actually, the best and hardest to remove infect the bios itself, removing those are very difficult.

Re:Not surprised at all (0)

Anonymous Coward | about 2 years ago | (#42054779)

Well, instead of demanding the BIOS to not boot anything MS-unblessed, it would have been easier to prescribe the boot order to start with the hard disk. This won't help against factory-installed malware on the disk, but that is not really the most prevalent attack vector.

Re:Not surprised at all (1)

DrXym (126579) | about 2 years ago | (#42053505)

I'm not surprised if a chunk of malware still happens to work on the latest OS, especially through a normal BIOS which has no secure boot. Not all malware roots the system or replaces critical files and even if they did a legacy system has no way of knowing.

Even under UEFI, the secure boot would be responsible for ensuring the OS loader and firmware drivers were correctly signed before executing them. Assuming they were then it's not responsible for exploits which happen down the chain. I assume Windows 8 does attempt to validate its kernel and critical files but who knows what exploits are possible even under that model.

support free software & hardware and prices dr (2, Informative)

Anonymous Coward | about 2 years ago | (#42053529)

Stop buying MS hardware! Prices will drop...

The free software and open source software advocates merely need to stop buying hardware dependent on and designed for proprietary operating systems. There are options that are becoming very popular. The major issue right now is there are a lot of people too cheap to realize the difference between a $400 POS laptop with Microsoft Windows which has higher specs and your typical higher quality laptops smaller companies are shipping with Linux. Even if the hardware is lower spec'd at a higher price doesn't mean it is a rip off. What your getting is significantly better in a number of different areas.

As an example your not going to be dealing with wireless issues related to digital restrictions. HP, Dell, Lenovo, and Toshiba ship laptops that prevent the replacement of incompatible wireless cards with third party options. This is because they make money off selling replacement cards to users whose wireless cards have died after the warranty period.

There are other good examples such as the loss of support because manufacturers have discontinued the proprietary drivers/firmware for your hardware.

While System76, ZaReason, and most others are shipping good quality hardware they do need to improve in certain areas. Right now pretty much every typical user is being disadvantaged by bad policies or simply the lack of a policy that advocates the use of chipsets which are free software friendly where such chipsets are available. A quick search will turn up a lot of customers who are running into issues because of these non-free drivers/firmware dependencies. And from what I'm reading nobody cares. People are just being shafted.

The only company which seems to be making a difference in this area is ThinkPenguin. ThinkPenguin is funding a number of major and minor distributions, the Free Software Foundation, and investing in the manufacture of hardware which is free software friendly. This amongst many other projects to bring better support for hardware to users around the world. And this irregardless of the distribution. If you want to run Ubuntu one day and switch to Trisquel the next you actually can (Trisquel is a distribution that doesn't ship drivers/firmware/and other software dependent on non-free software- there are many other distributions with similar policies). Even Debian doesn't ship with non-free drivers/firmware any more. They have released a derived kernel even which removes pieces from the mainline kernel.

Ultimately it is the actions of people using such distributions which funds the ecosystem which improves support for hardware that works with Linux rather than against it.

Standardizing on a binary application interface is not the answer. Supporting free software is.

And I'm not a loony. I'm not saying get rid of all the non-free stuff. There being distributions which support bad hardware will help in introducing people to free software. What I'm saying is be conscious of the negative effects of your actions when purchasing hardware down the road. Encourage distributions to inform users of the technical (and optionally ethical) issues of using such hardware. If you can avoid hardware dependent on non-free code do so.

Linux will not take off without wider availability of such hardware because the average user isn't going to stat up a terminal window to install some proprietary driver. They aren't going to apply some hack because the manufacturer refuses to fix a bug. The source code needs to be maintained (not just included) in the mainline kernel and/or similar. That is what leads to the best hardware which works out of the box. And this is not to say that the code itself is necessarily better. However it certainly doesn't hurt it when anybody can submit fixes, improvements, etc.

Re:Not surprised at all (4, Interesting)

Wattos (2268108) | about 2 years ago | (#42053617)

Maybe the "Secure" in "UEFI Secure Boot" referes to securing Microsofts Monopoly and existence in the OS market?

Re:Not surprised at all (1)

Truekaiser (724672) | about 2 years ago | (#42053639)

Regulatory capture.
The last fed lawsuit was less to do with them bundling i.e. With windows and more to do with them not giving the regulatory agency's $.

Re:Not surprised at all (5, Informative)

recoiledsnake (879048) | about 2 years ago | (#42053939)

As of now we know that Win8 is vulnerable to a huge chunk of malware designed for older versions of Windows. This "UEFI Secure Boot" does not prevent it at all. I suspected earlier that UEFI Secure Boot wasn't designed to make PCs more secure but rather to lock down PCs, so novice users trying to check out some Linux distribution will have tough time doing so. This fiasco makes me sure that this was the case and makes me wonder why antitrust authorities don't do anything about this. This is potentially more harmful than MSIE case after all.

If you(and others here) really want to educate yourself instead of spreading karmawhoring FUD, please read on.

Here are some references about boot malware which UEFI secure boot will prevent.

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.

Re:Not surprised at all (4, Insightful)

marcosdumay (620877) | about 2 years ago | (#42054945)

Is there something about UEFI and secureboot that causes many folks' brains to be absolutely switched off?

No. But it seems there are a few points that you are making an effort to ignore. Because you just quoted them, but still don't acknowledge them.

Re:Not surprised at all (3, Interesting)

AmiMoJo (196126) | about 2 years ago | (#42054317)

Actually UEFI does prevent a huge amount of it, and most important all the worst stuff that was beyond the ability of AV software to get rid of. Remember all those fake anti-virus scams? They installed a rootkit that changed the low level SATA driver which is loaded very early in the boot process. UEFI prevents an OS modified in that way from booting and the Windows 8 recovery system can detect and fix it.

Not if the SATA change happens after boot. (1)

Anonymous Coward | about 2 years ago | (#42055451)

It only stops a changed boot process booting. But if once booted, the OS then changes the drivers, you're open again.

And though this may be "the worst to remove", multiply the effort by the probability of catching one and you're being penny wise and pound foolish.

Re:Not surprised (3, Insightful)

mwvdlee (775178) | about 2 years ago | (#42053263)

Something about contributing to stupidity instead of malice.
I'm guessing since MS has to sign these bootloaders for relatively few cases, they're doing it atleast part manually.

Re:Not surprised (0)

Anonymous Coward | about 2 years ago | (#42053779)

Attributing?

Re:Not surprised (1)

mwvdlee (775178) | about 2 years ago | (#42053989)

Indeed, appollogizemisations.

Re:Not surprised (1)

l3v1 (787564) | about 2 years ago | (#42053799)

"Something about contributing to stupidity instead of malice."

Well, there's a part of an edifying story going something like: - How old are you, my prince? - 25 (*) - And you still believe in fairytales?

(*) Number doesn't really matter, but reflects age greater than childhood.

Re:Not surprised (1)

sunderland56 (621843) | about 2 years ago | (#42053969)

Signing of apps and signing of drivers is handled by completely different people; I would imagine that signing of boot loaders is another, new group. This may well be their very first submission, so things may not go exactly as planned.

Re:Not surprised (1)

Chrisq (894406) | about 2 years ago | (#42054479)

Somehow, thay can sign town of apps and drivers on a regular basis, but signing teeny tiny code for FSF got screwed... It only validate, in my opinion, this whole secure boot shit was meant to give alternative OS a hard time.

Actually I'm generally not a Microsoft fan but I'd reserve judgement on this. Signing boot-loaders to be authorised by the hardware is likely to be a different procedure and done by different people to signing drivers. They probably have not done this often and when they have it will have been mostly with their own generic key. I can easily put this down to mistakes, and if they sort it out promptly I see no reason to put it down to ill will.

Present user test? (1, Interesting)

SuricouRaven (1897204) | about 2 years ago | (#42053181)

Does that mean the user has to actually be present to press a key? That renders secure boot unuseable on remote-admined or unattended servers, the very place you would most want to have a secure boot chain.

Re:Present user test? (3, Informative)

jimicus (737525) | about 2 years ago | (#42053245)

Likely to be much less of an issue on proper server hardware; most server vendors know full well a significant amount of the hardware they shift will never run Windows.

Re:Present user test? (1)

SuricouRaven (1897204) | about 2 years ago | (#42054535)

A lot of servers aren't 'proper' server hardware. Sometimes consumer-grade is good enough, espicially when it's so much cheaper you can have redundent everything. Think clusters.

Re:Present user test? (1)

avarus (610800) | about 2 years ago | (#42053253)

One would assume that the administrator of a headless server is clued up enough to load their own key into UEFI and doesn't need this workaround in any case.

TIM

Re:Present user test? (2)

Skal Tura (595728) | about 2 years ago | (#42053313)

Automation is key here, if it takes a manual step to do that, you can forget it.

Re:Present user test? (1)

gweihir (88907) | about 2 years ago | (#42053597)

Easily rectified. If you have a "real" server, use IPMI. Otherwise something like a teensy or a programmable mouse.

Re:Present user test? (1)

tapanitarvainen (1155821) | about 2 years ago | (#42053849)

Does that mean the user has to actually be present to press a key? That renders secure boot unuseable on remote-admined or unattended servers, the very place you would most want to have a secure boot chain.

User only needs to press a key during initial installation, after that it should boot unattended just fine: "If the user gives permission, the signature will be installed and loader.efi will then boot up without any present user tests on all subsequent occasions even after the platform is placed back into secure boot mode." http://www.linuxfoundation.org/news-media/blogs/browse/2012/10/linux-foundation-uefi-secure-boot-system-open-source [linuxfoundation.org]

Let me get this straight (5, Insightful)

DMiax (915735) | about 2 years ago | (#42053185)

So, instead of signing with a scrap key that vendors will ignore they signed essentially with the original one, so that this bootloader will work on any PC that follows the standard? This is so awesome I don't even know at what to laugh first.

I wish LF just released this bootloader and defuse all this "secure boot" crap. Of course they will play nice and allow Microsoft to save their face... Microsoft incompetence is just appalling. They will probably end up signing malware by accident at some point, but at least you won't be able to run Linux on your PC, so mission accomplished.

Re:Let me get this straight (2)

someones (2687911) | about 2 years ago | (#42054055)

If they did now, M$ would replace the broken key and its gone.
BUT, if they wait for the time when this secure boot crap really hits the market and THEN release this bootloader, M$ wont be able to revoke this key, as too many vendors allready included it and many would not go thru this crap again.

So it would be strategically wise to wait like 3 years and THEN release this one to essentially kill secure boot.

Wtf? (5, Insightful)

ickleberry (864871) | about 2 years ago | (#42053191)

We have to ask Microsoft for permission now before they give us a key that lets us install Linux on our own machines?

This is seriously not good, lads. They still have the monopoly so we should sue them till the last toothpick in their Redmond HQ are belong to us.

Re:Wtf? (0)

Anonymous Coward | about 2 years ago | (#42053239)

We have to ask Microsoft for permission now before they give us a key that lets us install Linux on our own machines?

This is seriously not good, lads. They still have the monopoly so we should sue them till the last toothpick in their Redmond HQ are belong to us.

all your toothpick belong to us?

Re:Wtf? (1)

Anonymous Coward | about 2 years ago | (#42053311)

Someone set us up the gums?

Re:Wtf? (1)

flimflammer (956759) | about 2 years ago | (#42053355)

Or just disable secure boot, which is amazingly easy to do in the first place. If a novice user can properly install Linux, that same novice user can be directed to disable this stupid function.

Re:Wtf? (5, Insightful)

turkeyfeathers (843622) | about 2 years ago | (#42053667)

Or just disable secure boot, which is amazingly easy to do in the first place.

For now.

Re:Wtf? (0)

flimflammer (956759) | about 2 years ago | (#42055703)

Really? You think Microsoft is going to be able to get permanent Secure Boot as a mandatory feature on all x86 class hardware, and then be allowed to dictate what competing operating systems are allowed on that hardware?

No one sees the flagrant antitrust issues here?

You guys take paranoia to scary levels.

Re:Wtf? (1)

linebackn (131821) | about 2 years ago | (#42055685)

> Or just disable secure boot, which is amazingly easy to do in the first place. If a novice user can properly install Linux, that same novice user can be directed to disable this stupid function.

To repeat what I have said before: how well will that really work in practice?

You: "Hey, I need to boot my Linux USB drive on your computer, is that OK?"
Friend: "Uh, sure, I guess."
Friend: "Uh, it isn't working."
You: "Oh, I need to go in to your bios and disable SecureBoot."
Friend: "Duh, you aren't disabling anything that makes my computer less secure!"
You "but...."
Friend "NO!!!".

Re:Wtf? (1)

Toreo asesino (951231) | about 2 years ago | (#42053399)

Disabling secure boot allows this no problem.

Re:Wtf? (0)

Anonymous Coward | about 2 years ago | (#42054427)

That's while you still -can- disable secure boot. If the Linux Foundation now has to ask Microsoft permission for a key that will allow distributions to boot, how much of a stretch is it for Microsoft to simply now allow any other keys besides their own to be signed?

They have the keys now, so to speak. They're the ones that get to decide what a computer can and cannot do now...and it's going to stay that way, because they have a steady stream of income from the even more tightly locked-down 360/720 platforms. As long as they have a good grasp on games and entertainment they can pretty much do whatever the hell they want to the PC.

Re:Wtf? (1)

amorsen (7485) | about 2 years ago | (#42053469)

Feel free to run your own PKI and get the root keys included by the vendors. The option has been seriously considered by some of the larger Linux players, but it is just too expensive to do. Note that getting the root key included was not considered to be the main obstacle, it was the "run your own PKI" bit which killed the idea.

That is also why this is not news. PKI is hard, all of the major SSL signature vendors except one have made really stupid mistakes already. It is no wonder that Microsoft messes up too.

Need to replace UEFI with CoreBoot (5, Interesting)

LinuxNeverWindows (2590581) | about 2 years ago | (#42053555)

The way of breaking that monopoly is to replace UEFI on machines with CoreBoot (http://www.coreboot.org/Welcome_to_coreboot). This still does not support enough hardware but given a bit of support from Linux friendly companies (e.g. Clevo, IBM etc) it could be done. To see CoreBoot in action have a look at the Samsung ChromeBook with CoreBoot (http://www.youtube.com/watch?v=RypqMqtTPs8).

Re:Wtf? (1, Insightful)

kiwimate (458274) | about 2 years ago | (#42055293)

We have to ask Microsoft for permission now before they give us a key that lets us install Linux on our own machines?

I count three incorrect assumptions in this one statement.

Short answer: no, and see the other answers as to why it's no.

Long answer: no, and I'm not really that bothered that someone doesn't know this. What does bother me is that this got modded up to +5 Insightful.

Remember the days when Slashdot used to have technical people hovering around these pages?

I wouldn't worry too much about all this (1)

Viol8 (599362) | about 2 years ago | (#42053251)

Given the number of server side linux installs on x86 machines the PC manufacturers are not going to shoot themselves in the foot and not supply machines that linux can be (pre)installed on. They'll probably have a Windows compatable line and a Linux compatible line. At least for servers. For desktops and laptops things could get a bit tricky I suppose, but then I was under the impression all this secure boot crap could be switched off in the BIOS anyway?

Re:I wouldn't worry too much about all this (1)

mwvdlee (775178) | about 2 years ago | (#42053291)

As I understand it, UEFI is not a requirement for Win8, instead it's additional expenses for hardware manufacturers.
I'm guessing very few machines will actually have UEFI. Just some of the more expensive business models.

Re:I wouldn't worry too much about all this (0)

Anonymous Coward | about 2 years ago | (#42053381)

are you goofy? go look at the motherboards for sale.

Re:I wouldn't worry too much about all this (1)

FireFury03 (653718) | about 2 years ago | (#42054277)

As I understand it, UEFI is not a requirement for Win8,

AFAIK Windows 8 doesn't require UEFI, but the vendors are required to implement it in order to be able to use the "Designed for Windows 8" stickers. I think they're also required to enable it by default. x86 vendors can have an option in the BIOS to allow it to be turned off (I imagine the vendors who largely sell servers will do this whilst the cheap brands won't because implementing a "off" option would cost them a few pennies more in coding time). As I understand it, MS has mandated that ARM machines are required to have UEFI that can't be switched off (not entirely sure how they are enforcing this last one).

Re:I wouldn't worry too much about all this (0)

Anonymous Coward | about 2 years ago | (#42055071)

You made one mistake: x86 vendors must have an option to allow it to be turned off (for now).

"Designed for Windows 8" sticker (1)

r00t (33219) | about 2 years ago | (#42055369)

Last I heard, Apple had clawed it's way back to the top in some fashion... maybe the most profitable PC vendor? Anyway, they are pretty big and successful. Do they have this sticker? I doubt it. I'm thinking that a bunch of stickers all over your product detracts from the styling. A PC covered in gaudy do-dads looks like shit next to a PC with nice clean styling.

Re:I wouldn't worry too much about all this (0)

Anonymous Coward | about 2 years ago | (#42053301)

but then I was under the impression all this secure boot crap could be switched off in the BIOS anyway?

quote

For now... yes.
in the future..
Who knows. It wouldn't be Microsoft if they weren't putting the boot in with an innocent expression on their faces.

Re:I wouldn't worry too much about all this (-1, Redundant)

flimflammer (956759) | about 2 years ago | (#42053385)

People who seriously think secure boot will somehow become mandatory are borderline retarded. I'm sorry, but it's just not going to happen like that. Microsoft would not be able to defend an action that so flagrantly screws with every other OS on the planet.

Take off your tinfoil hats, people. Christ.

Re:I wouldn't worry too much about all this (2, Insightful)

Anonymous Coward | about 2 years ago | (#42053695)

It's *already* mandatory for ARM systems.
So you're the 'borderline retard'.

Re:I wouldn't worry too much about all this (1)

recoiledsnake (879048) | about 2 years ago | (#42054181)

I thought Windows RT was supposed to fail spectacularly from all the articles and comments on Slashdot?

Why are people then worried about Surface RT etc. getting a monopoly and using it to squeeze out Android from ARM tablets?

Where is the outcry about Apple locking up "ARM systems" with >60% marketshare ?

Or even about Android tablets errr "ARM Systems" shipping with locked bootloaders?

Re:I wouldn't worry too much about all this (0)

flimflammer (956759) | about 2 years ago | (#42055589)

Please. On locked down arm devices, yes. Get back to me when x86 is mandatory.

Continue being paranoid.

Re:I wouldn't worry too much about all this (0)

Anonymous Coward | about 2 years ago | (#42053731)

Wake up. Box builders cannot use the Windows logo if their machines are not compliant, they also lose their preferred partner license discounts.

It has nothing to do with building your own machines, or a limitation in the OS itself. Just the image and money.

Re:I wouldn't worry too much about all this (1)

flimflammer (956759) | about 2 years ago | (#42055659)

Maybe you should wake up. You think everyone is just going to sit idly by and let Microsoft force every other OS out of the market on consumer PCs unless Microsoft says it's OK for them to exist there? You don't think any of the big names in computing are going to have a problem with this?

No one else sees the glaring legal issues here? No one thinks Microsoft could see the glaring legal issues there?

By all means, mod this down like my previous post. You people are crazy.

Jerkoffs (0)

Anonymous Coward | about 2 years ago | (#42053273)

UEFI is complete bullshit.

Microsoft banned GPL in UEFI binaries .. (5, Informative)

dgharmon (2564621) | about 2 years ago | (#42053275)

Microsoft has also banned any GNU GPLv3 licences for these binaries [muktware.com] .

'When you get to this stage, you also have to certify that the binary " to be signed must not be licensed under GPLv3 or similar open source licenses". I assume the fear here is key disclosure but it's not at all clear (or indeed what "similar open source licences" actually are).'

Re:Microsoft banned GPL in UEFI binaries .. (4, Interesting)

bWareiWare.co.uk (660144) | about 2 years ago | (#42053481)

This restriction is imposed by the GPLv3 not by Microsoft. They are just being helpful in letting you know, they can't give specifics for all other licensees out there.

Re:Microsoft banned GPL in UEFI binaries .. (4, Insightful)

l3v1 (787564) | about 2 years ago | (#42053825)

What? GPLv3 doesn't allow a binary of the software to be signed with a key? Do you have a citation for that? Cause it sounds... interesting.

Re:Microsoft banned GPL in UEFI binaries .. (4, Informative)

l3v1 (787564) | about 2 years ago | (#42053839)

Nevermind, I looked around myself: http://www.gnu.org/licenses/gpl-faq.html#GiveUpKeys [gnu.org]

It says:

"I use public key cryptography to sign my code to assure its authenticity. Is it true that GPLv3 forces me to release my private signing keys?

No. The only time you would be required to release signing keys is if you conveyed GPLed software inside a User Product, and its hardware checked the software for a valid cryptographic signature before it would function. In that specific case, you would be required to provide anyone who owned the device, on demand, with the key to sign and install modified software on his device so that it will run. If each instance of the device uses a different key, then you need only give each purchaser the key for his instance.
"

So "no" then. (0)

Anonymous Coward | about 2 years ago | (#42055533)

There is no reason why MS cannot sign a GPL program if asked other than it doesn't want to.

Re:Microsoft banned GPL in UEFI binaries .. (1, Flamebait)

recoiledsnake (879048) | about 2 years ago | (#42053813)

Stop raking up shit with stupid karmawhoring paranoid crap.

If the UEFI binary was GPLv3 (not GPL like in your title, GPL v1 and v2 are good), then anyone distributing the binary will have to release the signing key, which defeats the whole purpose of UEFI secure boot signing since it will allow malware creators to sign their own malicious bootloaders with the key.

Why don't you GPL v3 your bank accounts and passwords and release them? OMG DGHARMON BANS GPL FOR HIS INFO. +5 INFORMATIVE

While the ignorance in the posts here is pathetic enough, even the moderators are clueless about UEFI secure boot.

Re:Microsoft banned GPL in UEFI binaries .. (1)

sunderland56 (621843) | about 2 years ago | (#42053941)

So does that mean that the FSF is going to release a binary without source code? How ironic.

Re:Microsoft banned GPL in UEFI binaries .. (1)

Barefoot Monkey (1657313) | about 2 years ago | (#42054387)

So does that mean that the FSF is going to release a binary without source code? How ironic.

No, the Linux Foundation. And no, it doesn't mean they'll release a binary without source code - it just means that the binary presented for signing must not be licensed as GLPv3 (or similar, whatever that means).

What am I missing? (2, Insightful)

wonkey_monkey (2592601) | about 2 years ago | (#42053287)

So the Linux Foundation, quite rightly, are trying to make available a signed bootloader which will then anyone boot whatever we want without having to disable secure boot - have I got that right? What stops someone monkeying around with the next level of abstraction?

Re:What am I missing? (2, Insightful)

Anonymous Coward | about 2 years ago | (#42053327)

As you have noticed, the system is retarded and unworkable.

Re:What am I missing? (0)

Anonymous Coward | about 2 years ago | (#42054257)

Since users have go through a warning message everytime before such a system is booted , it is noticed that it's Slashdot posters and moderators that are retarded and falling for all the FUD about secure boot.

Re:What am I missing? (1)

recoiledsnake (879048) | about 2 years ago | (#42054237)

So the Linux Foundation, quite rightly, are trying to make available a signed bootloader which will then anyone boot whatever we want without having to disable secure boot - have I got that right? What stops someone monkeying around with the next level of abstraction?

Not exactly. It will require a physically present user to click though a warning message before booting the "next level of abstraction".

Re:What am I missing? (0)

Anonymous Coward | about 2 years ago | (#42055521)

I doubt it, if I install linux on my computer as the only OS I want it to boot without user interaction. I don't see why they would make a bootloader without that function, and I suspect that will be the case. And then someone can take that bootloader, boot their malware first, and then boot windows after inserting code into windows. Even if you got the warning it will only do so much if you erase the bootable windows copy and provide only the bootable malware that chain loads the infected unsigned windows.

Godspeed (1, Insightful)

Anonymous Coward | about 2 years ago | (#42053295)

Freedom is getting fucked harder and harder every day.

Re:Godspeed (0)

Anonymous Coward | about 2 years ago | (#42054195)

Security and Freedom is a balancing act. A purely free computer has no security and a purely secure computer is not usable. Many people have wondered if there is a way to use PKI to make computers more secure.

Can I have a secure system if someone has physical access to it? Yes, with PKI I can. Am I willing to make things a bit more annoying when dual booting to have a more secure system? I know I am.

Disabling secure boot and dual booting? (3, Interesting)

efornara (1165681) | about 2 years ago | (#42053337)

I know that new laptops shipping with Windows 8 preloaded have to allow the user to disable secure boot.

Now that some laptops are out there, does anyone know if disabling secure boot will still let you run Windows, ideally even after its partition has been resized? Or will the preinstalled Windows just refuse to boot if secure boot has been switched off?

Another anti trust case? (2)

zaax (637433) | about 2 years ago | (#42053353)

Sounds like another anti-trust case. I will be putting Unbuntu on my next machine and if I can't do it I will be asking for my money back and getting pi, though I might getting a pi anyway as they are much cheaper than a 'nomal laptop / netook'.

Re:Another anti trust case? (-1)

Anonymous Coward | about 2 years ago | (#42053431)

You can just disable it in the bios you retard.

Enjoy uisng your 'netook'.

Re:Another anti trust case? (0)

Anonymous Coward | about 2 years ago | (#42055523)

You can just disable it in the bios you retard.

Enjoy uisng your 'netook'.

That won't work because netooks ues bananos instead of bios.

This (1)

symbolset (646467) | about 2 years ago | (#42053439)

is my surprised face:

Microsoft as gatekeeper (5, Insightful)

lasermike026 (528051) | about 2 years ago | (#42053657)

Microsoft as gatekeeper to PC hardware is a non-starter. You can not have one company determine who will and will not use a PC. When I mean use I mean loading the operating system of the user's choice. That is using a computer, running the programs and operating system that the owner of the computer wants. One company determining how a user will use their computer best example of a monopoly.

Sup Dawg, I herd you like bootloaders (0)

Anonymous Coward | about 2 years ago | (#42053743)

So I put a bootloader for your bootloader to boot

Not good (0)

Anonymous Coward | about 2 years ago | (#42053767)

In earlier news as I remember it the fact that Verisign/Symantec provided the keys was seen as a sign that Microsoft did not put itself in a position of too much power over the process. Now I read they are very much part of the process. No matter what their intentions are (at the moment) it is not good that OS suppliers have to go through a competitor to access hardware features.

The things that went wrong hopefully weren't intentional. They do show that Microsoft still lives in a dream world where all IT is Microsoft. Checking if a file is a Win32 binary and requiring Silverlight is not the way to interact with a world where other operating systems exist.

They don't go into specifics about the contract, but it reminds me of me having reason to contact Microsoft a few years back about an issue I ran into as a result of others using their software, without me using any of their products at all. A support guy on the phone pointed me to a contact form on their website. It turned out I had to agree to a EULA just to talk to them, making me agree to all kinds of things about products I didn't even use. I refused to do that, and sent my complaint by paper mail instead, mentioning that I thought it was a bit wierd that an IT giant effectively blocked me from using the computer to communicate with them. I never got a response to my complaint. The message as I interpreted it: if you don't use their stuff you don't exist for them. It seems to be happening here too.

Cant work out (0)

Anonymous Coward | about 2 years ago | (#42053897)

How people still trust a pathological liar (Microsoft) which always showed their true colours. Grow up.

Antitrust! (0)

Anonymous Coward | about 2 years ago | (#42054243)

This "secure boot" is nonsense. I say we all sue Apple until we can run Ubuntu on our iPads!

Wait, we're supposed to be mad at Microsoft today, aren't we? My bad.

Re:Antitrust! (2)

jbengt (874751) | about 2 years ago | (#42054799)

MS can do all the lock-down they want on the hardware they make and sell. But for them to be in charge of locking down 3rd party hardware and software that I buy from other vendors is just nuts. Especially as the 800 lb gorilla in the room means that I will have almost no choice of vendors that don't restrict my use. I want my computer to be mine, not Microsoft's and not Apple's.

I'm not sure I give much of a crap (2)

pointyhat (2649443) | about 2 years ago | (#42054641)

It has been proven recently that the whole WinTel PC thing and the associated lock in is on its way out as UEFI Secure Boot would be as well. ARM and Linux is where everything appears to be heading. Look at all the Android tablets and phones, Chromebook, Raspberry Pi, Beagleboard etc. Even Apple is rumored to be looking at ARM for newer laptops and are throwing their own cores together.

It's only a matter of time...

Re:I'm not sure I give much of a crap (1)

marcosdumay (620877) | about 2 years ago | (#42055587)

(Failing != failed) && (going down != zero)

MS has a hold on the PC strong enough to survive several years, even if their management insist on their current suicide style of doing business. They can make a lot of problems even if they fail, and they can be a huge problem if they somehow get their heads over their shoulders.

Cripes! How shocking! (1)

Arancaytar (966377) | about 2 years ago | (#42054833)

I don't see how anyone could have seen this coming.

Oh, the irony (0)

Anonymous Coward | about 2 years ago | (#42054917)

Apple will soon be the maker of the most open PCs. OSX, Windows, Linux, whatever you want to run on it.

That's a win (1)

RMingin (985478) | about 2 years ago | (#42054965)

"I've pulled the binary apart, and I think the problem is that it's not signed with a LF [Linux Foundation] specific key, it's signed by a generic one rooted in the UEFI key."

Please, "leak" that one immediately. It would tear huge holes in "Secure Boot".

Give bootloader signing to a third party! (1)

linebackn (131821) | about 2 years ago | (#42055593)

Bootloader signing must be controlled by a neutral third party. Not Microsoft. Anything less is simply anticompetitive and will end badly.

Reading between the lines, you can clearly hear Microsoft management waffling around muttering "Uh, we need to find a way to fuck open source harder"

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?