FSF Does Want Secure Boot; They Just Want It Under User Control 210
Yesterday, we ran a story with the headline "Free Software Foundation Campaigning To Stop UEFI SecureBoot." It's more complicated than that, though, writes gnujoshua: "We want computer manufacturers to implement Secure Boot in a way that is secure. If a user can't disable Secure Boot and they are unable to sign their own software (e.g., bootloader, OS, etc), then we call that particular implementation 'Restricted Boot.' We don't want computer makers to implement Restricted Boot. We want them to implement Secure Boot and to provide a way for individuals to install a fully free OS on their computers. Many computer makers are implementing UEFI Secure Boot in this way, and we want to continue encouraging them to do so." The complete text of the statement they'd like people to sign reads: "We, the undersigned, urge all computer makers implementing UEFI's so-called "Secure Boot" to do it in a way that allows free software operating systems to be installed. To respect user freedom and truly protect user security, manufacturers must either allow computer owners to disable the boot restrictions, or provide a sure-fire way for them to install and run a free software operating system of their choice. We commit that we will neither purchase nor recommend computers that strip users of this critical freedom, and we will actively urge people in our communities to avoid such jailed systems."
What problem does it solve? (Score:5, Interesting)
What problem does Secure Boot solve, other than Microsoft's "other OS" problem?
Re:What problem does it solve? (Score:5, Interesting)
Re:What problem does it solve? (Score:5, Interesting)
The boot sector issue has already been solved by most BIOS by (optionally, under user control in the BIOS configuration) preventing writes to the sector. The only time you need to unlock it is when you want to update the bootloader (relatively rare). I'm still at a loss for the value-add presented by secure boot.
Re:What problem does it solve? (Score:5, Interesting)
The value is that it's DRM. Obviously this has no value to any computer user, but it has value to the people who try to force the proprietary OS on you (Microsoft).
Re: (Score:2)
It's not DRM. You can turn it off in the firmware and there's no way for the OS to know that you did.
Re: (Score:2, Informative)
Wrong.
1. You can turn it off on x86 - not on ARM
and the biggy:
2, Windows can tell if it was booted in secure mode or legacy mode.
So basically you couldn't be more wrong. Congratulations.
Re: (Score:2)
How does Windows know whether it was booted in secure mode? It makes the EFI GetVariable() call. Which is a function pointer handed to it by the firmware. Which you can modify if you're running untrusted code. So, no, Windows can't tell.
Re: (Score:2)
The GetVariable() call returns a decryption key that the hardware calculated. If secure boot is turned off then it returns the wrong value. Your patched version cannot return the correct value because you do not know it.
Actually the "value" is the state of the decryption chip, not anything that can be read. Either you have to get the decryption chip into the same state (supposedly impossible unless you know the master key, which would just let you sign a bad copy of Windows anyway), or you would have to fin
Re: (Score:2)
"The GetVariable() call returns a decryption key that the hardware calculated"
No it doesn't. It returns a 1 if the firmware claims to have booted securely, and a 0 if not. You're thinking of Measured Boot, not Secure Boot.
Re: (Score:2)
Please describe how Windows can accurately determine whether it was booted in Secure Boot mode or not. For an encore, describe how Trusted Computing can limit the code you can boot. As far as I know, single machine local attestation is an unsolved problem.
Headline is disingenuous (Score:5, Informative)
Re:Headline is disingenuous (Score:4, Interesting)
Problem with secure boot is it creates a whole new attack vector. Attempts to solve one problem by creating a new one. When the purpose of attack is to deny access to the machine, what better way than to trip secure boot into action and prevent the machine from running. So you attack software doesn't have to do much of anything at all, just be difficult to remove without a full reinstall and it can leave the rest of the attack to secure boot.
Re: (Score:2)
WTF does DRM have to do with security? DRM is anathema to security. The person who owns the device should OWN IT. DRM allows outside parties to tell the device what is permissible, and what is not permissible. Allowing outsiders any access to my device, however indirectly, is contrary to security.
If DRM is a subset of security, then the Tea Party is a subset of the Democratic Party. The Westboro clan is a subset of the gay rights movement. Chavez is a subset of capitalistic investors.
Dude - we get eno
Re:What problem does it solve? (Score:5, Informative)
Many viruses modify either the OS bootloader or low level drivers (SATA, PCI bus etc). By loading so early in the boot process they have full and unrestricted access to the entire machine, making them excellent and difficult to remove rootkits.
This isn't just a Windows problem either, all operating systems are vulnerable to the modification of core boot files.
Re:What problem does it solve? (Score:5, Interesting)
Many viruses modify either the OS bootloader or low level drivers (SATA, PCI bus etc). By loading so early in the boot process they have full and unrestricted access to the entire machine, making them excellent and difficult to remove rootkits.
This isn't just a Windows problem either, all operating systems are vulnerable to the modification of core boot files.
One of the only cool things about Windows 7/8 do is have protected kernel paths combined with signed drivers in x64. This makes the job of a rootkit much harder and is one of the only arguments to give for die hard XP users who are chaining their old systems by their ankles for life afraid to upgrade.
It is not about DRM at all and is not used. A signed bootloader with the kernel path and device drivers prevent the next aulurion worm/rootkit from taking shape as nothing untrusted can run from the kernel.
It is great for corporate customers. If this could be used for gnu/Linux the situation would be great for security.
Re:What problem does it solve? (Score:4, Insightful)
This makes the job of a rootkit much harder and is one of the only arguments to give for die hard XP users who are chaining their old systems by their ankles for life afraid to upgrade.
It's not a case of being afraid to upgrade. It's the fact that users, companies and organisations have software and infrastructure that runs and is tested on XP and there is zero benefit to them changing it. Kind of like how a great deal of mainframe code is still written in COBOL. There is no benefit to rewriting it and people do not have the time or the resources. You might not like that but that's the real world.
It is not about DRM at all and is not used. A signed bootloader with the kernel path and device drivers prevent the next aulurion worm/rootkit from taking shape as nothing untrusted can run from the kernel.
Anything can be deemed to be untrusted, that's the problem. I'm afraid the rootkit/virus/security angle to this stuff is just an excuse, plain and simple.
It is great for corporate customers.
It's a disaster for corporate customers. They face a future of new hardware refusing to boot existing versions of Windows or any other operating systems, enforced upgrades and a spiralling in costs, licensing and otherwise. A rootkit is the least of their worries.
Re: (Score:2)
It's not a case of being afraid to upgrade. It's the fact that users, companies and organisations have software and infrastructure that runs and is tested on XP and there is zero benefit to them changing it. Kind of like how a great deal of mainframe code is still written in COBOL. There is no benefit to rewriting it and people do not have the time or the resources. You might not like that but that's the real world.
The key difference is that people tend not to use their mainframe running COBOL code to browser the internet at lunch time. Software for XP tends to be end-user software, on vulnerable workstations.
Windows 7 does provide a full XP virtual machine as well.
Re: (Score:2)
The key difference is that people tend not to use their mainframe running COBOL code to browser the internet at lunch time. Software for XP tends to be end-user software, on vulnerable workstations.
You're missing the point. Corporations have desktop software that they completely rely on that was written for the NT4/Windows 2000/Windows XP era as the desktop market expanded within business through the 90s and early 00s. That reached a critical mass some years ago. I hate to burst peoples' bubbles on this but companies do not spend vast sums on having dedicated teams of people continually upgrading Microsoft software and rewriting their own software to run on new platforms nor do they care about people
Re:What problem does it solve? (Score:4, Insightful)
I posted comments here debating slashdotters who feel anyone still running an old IE at work deserves to be hacked who do not understand corporate IT.
You feel free to debate other 'Slashdotters' as much as you like to fit your own arguments. There are other browsers available on XP besides IE since Microsoft claims they can't upgrade it.
Like the mainframes platforms of old there are solutions for them. Citrix and MS terminal servers are just 2 to run older software.
More complexity and more expense to continue running exactly what users were running before. The corporate world has no time for it. However, we still have forty year old COBOL code calculating our bank balances every day and people are not going to be rewriting what they have in .Net to run on a newer platform. There is only so much Microsoft can squeeze from that lemon.
The fact of the matter is new hardware does not like XP very well.
Well it wouldn't would it, you idiot? That's why corporations are virtualising old versions of Windows, but this presents Microsoft with a dilemma. Previously they depended on perpetual hardware upgrades but virtualising Windows allows corporations to continue functioning as normal and upgrade hardware pretty much forever. Enter 'Secure Boot'. Hardware that doesn't have the keys to boot 'foreign' hypervisor platforms and hypervisors implementing Secure Boot that have keys only to boot what they feel like.
These will get EOL'd and you are screwed as they wont run XP anymore by 2014.
People will care little. I know of people running NT 4, many virtualised, on closed off networks because they have applications on there that would take a great deal of time and effort they don't have to upgrade. Iit is simply the way the real world is.
It is a security risk, and the rest of the world who does not have your requirements are moving on.
The numbers in the corporate world who are still running XP tell you otherwise. They aren't moving on.
Already Office 2003 is not fully compatible with the newest .docx files in Office 2013 and sometimes Office 2010.
That's not anyone's problem but Microsoft. No one cares in the corporate world. Many have mail merges and Office BASIC tied into Office 97. They won't be rewritten. They already have all their documents in the old binary doc format and have no time to do conversions or find out if a new version of Office will actually open them.
Did you read about hte newest malware targetting the XP versions of Ie 8, 7, and 6?
The moral of the story? Don't use IE.
Who are you going to get support from after next year?
People are not phoning Microsoft up every day of the week getting support to keep their systems running. Things are a known quantity.
It is time to consider Hyper V, Windows Server 2003 terminals, and Citrix similiar to rally and x3700 IBM terminal software for these must have apps before it is too late.
More complexity the corporate world dislikes. However, those who have needed to virtualise and and run terminal sessions have been doing so. The trick with that though is that you don't need a magical desktop environment to run web or remote applications.
I disagree that a corporate customer wouldn't love to have documents time bomb, lock and encrypt files, and prevent software that is unathorized to steal keystrokes at bootup.
I thought this wasn't about DRM? ;-) Any experience of corporate IT tells you these are accidents waiting to happen. All you'll get is a load of support calls asking you why something doesn't work.
I know it is an uneccesary cost for you but come on? 12 years is a FUCKload A LOT of time and you
Re: What problem does it solve? (Score:2)
Just to put this out there yet again, .NET WORKS PERFECTLY FINE ON WINDOWS 8. Microsoft allowed managed C++ to access the new Windows RT runtimes, and the RT framework only allows a subset of the .NET framework, but all your old apps run just fine outside the metro stack regardless of your development methodology.
Yes, if you want to run your local apps locally on a surface RT some redevelopment will be required, but given your local app is probably shockingly bad under a touch interface it probably needs r
Re:What problem does it solve? (Score:4, Interesting)
It is not about DRM at all
Not at all you say? Not at all about DRM...then what happened here:
https://www.softwarefreedom.org/blog/2012/jan/12/microsoft-confirms-UEFI-fears-locks-down-ARM/ [softwarefreedom.org]
A signed bootloader with the kernel path and device drivers prevent the next aulurion worm/rootkit from taking shape as nothing untrusted can run from the kernel.
It also ensures that users cannot do this sort of thing:
http://www.evilavatar.com/forums/showthread.php?t=7650 [evilavatar.com]
Or even something as simple as this:
https://en.wikipedia.org/wiki/Decss [wikipedia.org]
See, the distinction here is subtle. If the user can modify their kernel, but only when their computer is a special "modify the bootloader" mode (or if the user can sign their own bootloader etc.), then the security argument makes sense. If the user cannot, then there is no security argument, because forbidding the user to modify their own system has nothing to do with security -- unless by "security" you mean "DRM."
If this could be used for gnu/Linux the situation would be great for security.
Re:What problem does it solve? (Score:5, Interesting)
The BIOS exists in the mother board's firmware. When you turn on the computer the BIOS is what is first executed. BIOS is what searches for drives that are bootable by looking for a first sector with 0x55 0xAA @ byte positions 510 & 511 (offset from pos 0, the first byte). If you tell the BIOS not to allow writes to any boot sectors then there can be no writing to the OS bootloader which starts off in that boot sector. That sector's 512 bytes (minimum) get loaded at seg:off 0000:07C0h on x86 systems, and the code begins executing in 16 bit real mode. In that 466 bytes of data (512 - 2 - 64 for partition table) it's a pretty tight fight, but I've managed to squeeze in a hash algorithm and a fingerprint along with the loader code for my own OS. If my boot sector is write protected, then it can't be modified, and it can verify the early environment kernel it loads hasn't been tampered with as well. From my early kernel I can perform signature verification of all other code loaded -- From drivers and applications to even other OS's sectors (for multi-boot). Signatures are either embedded in the executable as part of my extension to ELF or in a separate table in the case of the multi-boot OS sectors. Furthermore, the /boot/ system can be stored on read only media, such as a CD ROM, to prevent any tampering when the OS isn't running (you can do this with Linux too). This is how I secure even x86 systems w/o the option to disable boot sector writes -- Boot a CD that boots the OS.
EFI requires a FAT 32 file system to store your boot data within. Other FATs like FAT16 are supposed to be supported, but in my experience only FAT32 works reliably. This is nice because the BIOS can load your whole early kernel image into memory, set up protected mode and begin executing the kernel image at its desired memory location without requiring you to write bootstrap loader that does this. EFI sucks a bit because I'll miss the old real mode and the ability to install old OSs like DR DOS & DOS 3.1, and miss all those classic graphics modes, but that's a lot of baggage (service interrupts) for BIOS to have to support, and it's all a bit buggy anyway from BIOS to BIOS...
UEFI, SecureBoot, adds the requirement that the boot image be cryptographically signed with a key stored in the firmware. However, what good does it do to cryptographically sign the kernel image and verify it at boot if the OS doesn't take over and cryptographically verify all the low level drivers, etc? It's not any good, that's what. So, the OS has to support that same sort of signature system that I can achieve on an x86 without UEFI's help, given that BIOS lets me disable writing to the boot sector, or I boot from a read only media (CD/DVD).
There's nothing preventing EFI from having an option one could enable to prevent changes to the bootable sectors while the system is running. Drives would have to support a "mark read only" standard for sectors that the EFI or the OS itself could use to prevent changes to data on disk. The point is that the same exact benefits UEFI provides can be provided by simply setting sectors "read only" at boot -- No signature chains required in the damn BIOS at all. OS code will be responsible for verifying its own signature chains anyway, so the OS could be written in such a way that it's early kernel doesn't ever need to be modified -- Public Key Crypto could be used in the 1st stage kernel to allow any 2nd stage to be verified once the 1st stage is loaded, and different signed 2nd stages could be created for kernel upgrades. To keep the whole system secure only the 1st stage would need hardware write only protection. Additionally, the write-only method would allow any OS be installed without requiring clumsy crypto-key management -- End users could set a BIOS flag: Allow new OS Installation During Next Boot: [ON | OFF] much easier than looking up and entering a huge hex key -- What are the chances you'll mistype one char? Ugh, THAT's going to raise the bar to i
Re: (Score:2)
EFI sucks a bit because I'll miss the old real mode and the ability to install old OSs like DR DOS & DOS 3.1, and miss all those classic graphics modes, but that's a lot of baggage (service interrupts) for BIOS to have to support, and it's all a bit buggy anyway from BIOS to BIOS...
FYI, EFI is more than capable of presenting a BIOS environment to the next stage of the boot process, ask any mac owner.
Re: (Score:2)
If my boot sector is write protected, then it can't be modified, and it can verify the early environment kernel it loads hasn't been tampered with as well.
You speak later about booting from read only media, but thats part of the problem. Even if you prevent a specific boot sector from being written to, that doesn't tell you or the kernel anything about which bootsector was loaded and executed... and therefore the kernel cannot know that it has, or ever had, full control.
Re: (Score:2)
There's nothing preventing EFI from having an option one could enable to prevent changes to the bootable sectors while the system is running.
Well except that you make way too many assumptions. Like EFI will intrinsically (magically) know how all bootable devices past, present, and future work. And it has, and can maintain complete control over all known and unknown interfaces to those devices at all times, and scrub all the calls to those interfaces to prevent any attempts to write to the boot sector. Also, it would magically retain that control whether attached or unattached to the machine (USB stick, Sata Dock). Many of those are either im
Re:What problem does it solve? (Score:4, Interesting)
If you tell the BIOS not to allow writes to any boot sectors then there can be no writing to the OS bootloader which starts off in that boot sector.
Not true I'm afraid, modern operating systems that talk to the hardware directly rather than using BIOS calls will ignore this setting.
There's nothing preventing EFI from having an option one could enable to prevent changes to the bootable sectors while the system is running. Drives would have to support a "mark read only" standard for sectors that the EFI or the OS itself could use to prevent changes to data on disk.
So nothing but a change a to the SATA standard and the requirement of having a new HDD that supports the feature. Plus the whole point about rootkits is that they have equal power to the BIOS/EFI/OS, and besides which they don't always target the bootloader anyway. Many variants of the fake anti-virus scam that was rife a few years ago targeted the legacy IDE driver, for example, so protecting the bootloader wouldn't help.
OS code will be responsible for verifying its own signature chains anyway
Wouldn't help. One of the tricks rootkits use is to present the OS with a valid signature when verifying a driver, but then let it load an infected copy or replace the code with their own in memory. That is one reason why they are hard to detect - when an antivirus scanner reads the driver file from disk it gets the clean copy and does not see an infection.
However, what good does it do to cryptographically sign the kernel image and verify it at boot if the OS doesn't take over and cryptographically verify all the low level drivers, etc?
Fortunately they thought of that and SecureBoot will verify bundles of low level driver files as well. Otherwise, as you point out, it would be useless for any OS that doesn't use a huge monolithic kernel.
I mean, FAT32 is Microsoft's Proprietary File System, and parts of it are patented: Short to Long name mapping, for example.
Which is why no long file names are required, and everything that needs to be implemented can be done so with patent-free open source code. That is why FAT32 is so common in embedded systems and consumer products - widespread compatibility, free implementations and no patents to worry about.
Re: (Score:3, Interesting)
Secure Bullshit (Score:2)
Re:Secure Bullshit (Score:4, Funny)
All computers have a SECURE setting. It is called "Power off".
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Real slashdotters unplug the CPU.
Re: (Score:2)
Real slashdotters remove the processor and RAM.
Re: (Score:2)
Anything in a computer that calls itself 'Secure' isn't. Secure Boot is a false sense of security that will lead people to think they are safe. Secure Boot is Microsoft's Security against competition.
Agreed, Secure Boot is just Microsoft returning to its usual illegal business thuggery and hoping not to get slapped with $billions of fines this time. I would care about it if I thought the Surface would be a big hit but it's a thud so this is mostly entertainment. Great entertainment, like Laurel and Hardy trying to be evil.
Re: (Score:3, Informative)
BIOS boot sector protection has never prevented writes to the MBR unless you're running DOS - any actual OS uses direct hardware access instead of using the BIOS, and so it can't be blocked. It'd be possible for the BIOS to complain that the MBR's been modified, but it has no way of verifying that the partition boot code or the actual bootloader are still secure. Unsurprisingly, malware authors take advantage of this - https://support.kaspersky.com/viruses/solutions?qid=208280748 [kaspersky.com] has a list of modern bootki
Re: (Score:2)
And then the tiny ass bootsector loads another unchecked block of code that can easily be tampered with.
The boot sector is .... 512 bytes. That is bearly enough code to do anything useful, it is infact NOT enough space for the code required to boot my FreeBSD machine which has its root on ZFS, as such that process is two stage (well more than that in actuality) and the boot sector really just points to another boot block in an known location that the bios doesnt' give a flying fuck about.
There isn't enough
Re: (Score:2)
I posted too soon :/
It should also be noted that 'boot sector protection' as implemented doesn't work unless you're using BIOS calls to do the write. Once you're using direct hardware access like every OS on the planet does, BIOS doesn't have any part in the process and thus is a non-starter.
Re:What problem does it solve? (Score:5, Interesting)
1. It heads off anything else that is good enough being installed on to PC hardware that Microsoft deems threatening.
2. It's a lovely form of DRM Microsoft is probably salivating at. It means that future hardware can explcitly refuse to install previous versions of Windows even if it is possible.
3. Manufacturers will probably love it because there is the possibility that they can enforce what hardware can or can't be installed in the system. The net result is that hardware will have an artificially shorter life from now on and things will get a whole lot more expensive for users and for any prospective entrants into the hardware business. In fact, it will be downright impossible. Expect this to turn into one God-awful mess.
4. Everyone talks about Linux and other operating systems, but it will have an interesting effect on virtualisation. Microsoft has long been deeply uncomfortable about non-Microsoft systems running Windows virtual machines. The net effect is that these days you can run NT, Windows 2000 or Windows 2003 and prolong their life on new hardware by virtualising. With 'Secure' Boot Microsoft gets to dictate what hypervisors will run on hardware in future and they'll be able to control the life of their current and future operating systems. Expect to install Windows 8 on Windows Server 2015 with Hyper-V? Nope, sorry. Windows will probably also end up refusing to run as a guest on any hardware it doesn't like.
Basically, it's the end of the PC platform. I don't know whether Microsoft realises it but we'll all look back on this as the beginning of the end for them.
Re: (Score:2)
#4 is false. How do propose that Windows will detect that it's not being virtualized if the host doesn't want it to know? Did you think that somehow there is magic dust that makes it so that VMs can't virtualize a UEFI boot environment, secure boot and all?
Re: (Score:2)
I don't know whether Microsoft realises it but we'll all look back on this as the beginning of the end for them.
It's the continuation of the end. The beginning of the end was when Minimsft [blogspot.com] was captured and lobotomized.
Re: (Score:2)
Re: (Score:2)
The most important one is that it can gaurantee that the software you're running is the software you THINK you're running.
Simple example: Someone nasty gets access to your Linux box and installs a rootkit. This includes a modified version of "ps" that won't show the rootkit process(es), making it harder for you to notice it's there.
If you use a Linux machine that's set up to take advantage of the hardware, you could have it set to, say, only allow software that was signed by Canonical to run on it. This wou
Re: (Score:3)
A rootkit doesn't install a modified version of ps, it modifies the system calls that ps uses. That way the rootkit is able to hide its processes from any program that enumerates processes. (There's much more to it of course.)
That also makes it easier to defend against. There's no need to prevent the user from running whatever userland code they want. All you need to do is ensure that the kernel you are running is the one you THINK you're ru
Re: (Score:2)
What problem does Secure Boot solve, other than Microsoft's "other OS" problem?
Actually, it doesn't even "solve" that problem. Secure Boot is only a potential problem on computers running Windows 8. Once you buy that computer, Microsoft has already collected their "Windows Tax" so even if you install some other OS, it has no effect on Microsoft. They already got their money. This is one of Microsoft's biggest problems. The monopolist mentality is so deeply entrenched that they spend an enormous amount of time and money on stupid crap that is of absolutely no benefit to them.
More
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
What problem does Secure Boot solve, other than Microsoft's "other OS" problem?
Secure Boot satisfies Steve Ballmer's compulsive need to piss on the shoes of antitrust regulators.
Here's to hoping (Score:2)
So then they're fine with Windows 8 (Score:5, Insightful)
Windows RT is a whole different matter, but Windows RT also accounts for about 0% of the tablet market right now. Why is the FSF making all this noise now, when Apple has been happily locking down the iPad since 2010? Microsoft is just joining the party, and it seems a little late for FSF to get self-righteous about it.
But more power to them I guess. It seems like a tough fight, however, when users have a great deal of choice between tablets (both locked and unlocked), even with the locking down of certain hardware.
Re:So then they're fine with Windows 8 (Score:5, Insightful)
Why do people think that no one complained about Apple's lock down? They've had a walled garden in place since iOS 2.0 and it's always been a point of contention. Secure Boot just brings the threat of universal lock down that much closer.
Re: (Score:3)
Apple did not get a free pass (Score:4, Informative)
Why do people think that no one complained about Apple's lock down? They've had a walled garden in place since iOS 2.0 and it's always been a point of contention. Secure Boot just brings the threat of universal lock down that much closer.
Well to be fair both the FSF and EFF have been heavily involved after Apple demonised their customers calling them criminals for for jailbreaking Apples Phones(not theirs). Ignoring the fact that those are *electronic* devices and Apple is nowhere near a monopoly (I now its not a good answer for apple users), but again the same groups are not just focused on Microsoft. As for the FSF a quick Google gives this http://www.defectivebydesign.org/blog/1256 [defectivebydesign.org], although the jailbreak DMCA exemption for the iPhone...and not the tablet, have been big news on most technology sites.
Re: (Score:2)
Why do people think that no one complained about Apple's lock down? They've had a walled garden in place since iOS 2.0 and it's always been a point of contention. Secure Boot just brings the threat of universal lock down that much closer.
Because secure boot is about locking down the PC platform. It's on a whole different level. People can actually chose not to use iOS. They don't exactly get a choice these days not to use a PC.
Re:So then they're fine with Windows 8 (Score:5, Informative)
The FSF has been knocking Apple over iOS since its release. http://www.fsf.org/blogs/community/why-free-software-and-apples-iphone-dont-mix [fsf.org]
Re: (Score:2)
Think of it like a boss battle, where the boss is supported by many little nuisance h
Re: (Score:2)
That's one hardware vendor versus dozens. Restricted-Boot will cover all the other hardware vendors. Apple gets to cheat because they make the software for their hardware. All the people that buy Apple know this and in fact it's one of the reasons some of them buy Apple. I own a Mac computer but I bought an Android phone because I don't like the total lock down they have on the iOS devices. I pretty much run anything I want on my Mac so they haven't taken the process to the Computer side of the busines
Re: (Score:3)
So then they're fine with the way Windows 8 handles it? Because that's exactly what Microsoft demands of computer manufacturers who want to be certified for Windows 8.
Only on x86. The MS requirement for user-control over UEFI only applies to x86 systems. Arm based systems (phones, pads, etc.) have no such requirement.
But yes, I was surprised and pleased that MS included those requirements, even if it was just for x86, and I'm sure the FSF was as well.
Re: (Score:2)
But yes, I was surprised and pleased that MS included those requirements, even if it was just for x86, and I'm sure the FSF was as well.
I wasn't surprised. On x86 they had to because of the stink that would be created if corporations couldn't install existing Windows versions on new hardware or run their ghosting and imaging tools. On ARM they have no such problems and all they want to do is ensure Android cannot run.
A lot of ifs for the future, though... (Score:2)
That's the real question. Is the ability to disable secure boot on X86 just a temporary concession to corporations that would refuse to buy new computers without it? Once XP and Windows 7 work their way out of the corporate infrastructure, will Windows certified X86 machines still be required (or even allowed) to support disabling secure boot. If there's some promise to that effect, then fine. But I don't know of any.
Also, if ARM ever supplants X86 in corporate settings, then all bets are off. There is
Re: (Score:2)
Re: (Score:2)
So then they're fine with the way Windows 8 handles it? Because that's exactly what Microsoft demands of computer manufacturers who want to be certified for Windows 8
The difficulty is that OEMs will not lose any Windows 8 certification if they do not implement a user configurable key database. If it boots Windows 8 Microsoft won't care. Microsoft tacked that on to their 'mandatory requirements' knowing full well it won't be implemented in just about any case. In another 'mandatory requirement' they specify that the key database contents are to be determined by the OEM.
As for disabling secure boot, that was done so that existing versions of Windows and other platforms
Re: (Score:2)
Microsoft have told me that they'll revoke certification for any vendor who doesn't provide the appropriate options. If you have examples of machines that have certification and which don't allow any modification of the key database, let me know so we can find out if they were telling the truth.
Re: (Score:2)
If I buy a computer from Dell I don't want Microsoft telling me what I can use it for.
Re: (Score:2)
You've linked to a story about a traditional MBR bootkit that doesn't even run under UEFI. Secure Boot is, as far as anyone knows, not yet cracked.
Re: (Score:2)
Thought I may point out that your link shows how Win8's security can be by-passed by disabling SecureBoot prior to loading a bootkit. Every OS ever and ever will be, can be defeated this way.
Restricted Boot by definition insecure (Score:5, Interesting)
Think about it a moment. The ultimate piece of malware would be one that can make your computer run software of someone else's choice, prevent you from running software other than the malware, and block you from removing the malware from the system or preventing it from running. Every piece of malware out there tries to do this, with varying degrees of success. Look at the malware that tries to disable anti-virus/anti-malware software.
Now, Restricted Boot would give someone else control over what software could boot on the machine, and prevent you from changing that list of authorized software. You cannot authorize software you want to run to run, nor can you remove authorization from software you do not want to run. You can't influence what runs at boot, you can't alter it's operation. In short, you've bought into every malware author's wet dream: a system where they can do anything they want and the user can't do a thing about it.
And if you think "Oh, but all the system software would be signed by Microsoft, so how would the malware authors get the keys to authorize their software?", think about this: Microsoft certificates have already been compromised. The bad guys have already gotten access to what they need to sign software with legitimate Microsoft keys. The certificates used by the Flame malware [sans.edu] were only some of the most recent. And I'd note this older bulletin [microsoft.com] describing a situation where Verisign issued legitimate certificates issued to Microsoft to black-hats with no association with Microsoft. The bad guys obtaining the private keys to sign software isn't a theoretical discussion, it's already actually happened.
Re: (Score:3, Interesting)
The master keys have not been compromised. Only one of the older ones which are derived from the master for signing software under XP. MS has revoked that particular key and replaced it with another one. The bad guys also forged one of Adobe's for running signed flash applets as well but Adobe has replaced it. The master key in both situations are still secure.
Re: (Score:2, Informative)
The problem regarding the "Secure Boot"-key are a bit different:
Because they are built into the UEFI-firmware they cannot be easily replaced. You have to upgrade your firmware to get a new key. And then there is some kind of chicken&egg problem:
When the built-in key is compromised what should be updated first? The boot-loader (Signed with the non-compromised key) ? Or the key? If you replace the boot-loader first, the firmware refuses to load this boat-loader. And if you first replace the key, you have
Wrong (Score:5, Insightful)
To replace the key and the boot-loader you have to disable "Secure Boot" in the firmware (Disabling by software is not allowed), then update the key (Means flashing a new version of the firmware) and the boot-loader and then reactivate "Secure Boot".
Now think of Average Joe or your grand mother and tell me how someone like them will accomplish this.
Replacing the keys doesn't require reflashing the firmware, you just need go into the UEFI setup screen and add or delete the keys you're interested in. If the key gets compromised, you just go to the setup, add the new key, boot and update the bootloader and go into the setup and remove the old key. Or, even easier, you update the boot-loader on a working system, then go into the UEFI setup and remove the old key and add the new key. The procedure you outlined is unnecessarily complex even assuming that you have to reflash the firmware to get new keys.
Re: (Score:2)
Re: (Score:3)
No. You are wrong. You said:
Replacing the keys doesn't require reflashing the firmware, you just need go into the UEFI setup screen and add or delete the keys you're interested in. If the key gets compromised, you just go to the setup, add the new key, boot and update the bootloader and go into the setup and remove the old key ...
This is true for Secure Boot where the user/owner has control of the keys but it is untrue of Restricted Boot which is what the OP was talking about. In fact their subject line (which you overwrote) was:
Restricted Boot by definition insecure
Their point, of course, is that with Restricted Boot the user, by definition, does not have control of the keys so has no access to the setup screens you talk about. This is the essence of the problem with Restricted Boot they were pointing out. Your response makes no sense.
Re: (Score:2)
The master key in both situations are still secure.
They are not guaranteed to stay that way, that's the OP's point. If I was a serious virus writer this system is a potential boon. If you can find a way of compromising the system so that things appear to be trusted when they're actually not and you can lock out other software as a result you can create a hell of a lot of damage before anyone even notices.
Re: (Score:2)
If you were a serious virus writer you'd already want to use the Microsoft CA to sign your rootkit so you can install it as a signed driver in Windows. Secure Boot moves the vulnerability down the stack, but even now a compromised Microsoft signing key is still massively desirable to virus authors.
Re: (Score:2)
So they want the status quo then? (Score:3)
So the FSF is basically asking people to sign a petition that asks manufacturers to do what they are already doing and plan on doing ? The current requirements for windows 8 is that users must be able to disable secure boot in the bios and do key management (addition/removal) of keys as well. I don't know of any manufacturer that is planning on doing anything different since that would mean that their systems would not be windows 8 certified.
In fact, I don't think microsoft bans having other keys besides their key in the bios by default.If, for example, the FSF or some coalition (e.g. RedHat, Ubuntu, Debian, etc.) were to come up with some workable way key signing infrastructure, they could petition UEFI/mobo developers to include their keys in shipped products as well. The question is how do you freely allow people to get bootloaders signed without making it easily for malware authors to do the same.
Re: (Score:2)
The unsigned or differently-signed bootloader is not able to load Windows, because it will leave the machine in a different state that Windows will refuse to load from (ie wrong keys produced by the hardware). So such bootloaders are pretty limited. I could imagine a *huge* piece of Malware that is an entire copy of Windows but the user will lose any personal data stored on the disk in secure encrypted directories so this may be easily noticed, especially if Microsoft defaults to this encryption (which perv
Re: (Score:2)
It will not be able to set a decoding key that the following code needs, so no the following code will not work. It does not just do an if statement, it expects to read a decoding key from a piece of hardware and use that to decode parts of the system.
Re: (Score:2)
So the FSF is basically asking people to sign a petition that asks manufacturers to do what they are already doing and plan on doing ?
That is pretty much it.
Secure Boot is part of the UEFI 2.2 spec. Published in 2008. The geek has had four years to prepare for this.
Re: (Score:2)
Windows RT has Restricted Boot on it.
Re:So they want the status quo then? (Score:4, Interesting)
Can you boot whatever you want on Windows RT thingy? No. RMS and FSF are right, you are wrong.
Secure Boot is *not* (necessarily) DRM (Score:4, Interesting)
Being categorically against Secure Boot is akin to be categorically against digital encryption and signing in general just because they are tools that are sometimes used to create DRM. DRM is bad. Secure Boot without user/owner key control can make it worse. The FOSS community should embrace Secure Boot but fight for key control.
Used properly, Secure Boot will make FOSS systems more secure. It is much better to add security measures *before* they are needed rather than after. We have generally been ahead of the curve security-wise for decades. Embracing Secure Boot (with user key control) will help us stay ahead of the curve. If we instead shun Secure Boot there is a very real danger that we will lag behind.
Re: (Score:2)
Here's an amazing idea. (Score:2)
Re: (Score:2)
Anybody notice the accurate summary? (Score:2)
Writting "it's more complicated" is nice, but hardly a good apology.
Nevertheless, in days like these, let's take a moment to congratulate slashdot on a summary that's actually correct.
It's too often, that I find a different story, if I read beyond the summary.
But virus's would know more than users (Score:2)
Re: (Score:2)
When you turn off secure boot, Windows DOES NOT BOOT! It cannot because it will not see correct decoding keys read from the hardware. The virus cannot do much other than brick the machine, which it can do already in a much worse way by modifying a file so Windows refuses to boot whether or not secure boot is on.
The more useful feature that RMS really should insist on is that the user can add their own keys. But all this means is that you can boot either Windows or Linux without having to change the bios set
What happens when... (Score:2)
What happens when the Master key is found/hacked/whatever?
I mean, the big hacking groups, you know, the real criminal ones with the money, are probably salivating at the idea of finding an exploit or getting their hands on the master key. Its really only a function of time, and even money that it happens in the next few years. Hell, they could probably throw enough money at someone within MS with access to the master key and have it within a few days if they knew who would be open to taking a bribe.
Still,
Re:What happens when... (Score:4, Informative)
Just because you haven't seen one doesn't mean they aren't prevalent.
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] [chmag.in]
http://www.theregister.co.uk/2010/11/16/tdl_rootkit_does_64_bit_windows/ [theregister.co.uk] [theregister.co.uk]
http://www.computerworld.com/s/article/9217953/Rootkit_infection_requires_Windows_reinstall_says_Microsoft [computerworld.com] [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 dataThe 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 U
Link for the petition / statement (Score:3)
Direct link to the petition / statement referred to in the summary: http://www.fsf.org/campaigns/secure-boot-vs-restricted-boot/statement/ [fsf.org]
Only takes a few seconds to sign it!
Re:Its all in the language (Score:5, Insightful)
'Jailed' is the popular nomenclature. What do you think 'jailbreaking' means on your mobile device? It means unlocking the bootloader so it will boot unsigned or differently signed kernels. Doesnt sound patronizing to me, it sounds descriptive.
Re:Its all in the language (Score:5, Insightful)
Weaslly words? The lockdown in the name of "Secure Boot" is a weasel word. Calling it what it is in its implementation on ARM, "Restricted Boot" is not weasely--it's correct (cf. "Digital Rights Management" vs. "Digital Restrictions Management")
Re: (Score:2)
Re:Its all in the language (Score:5, Insightful)
Most people buying a computer will hear "Secure Boot", and yell, "Good! Secure! War on Terror!"
When they hear "Restricted Boot", they will scream, "Bad! Restricted! War against my freedom!"
It's those folks who this wording is for, not Slashdot folks.
Re: (Score:2)
Mod parent up.
Words have meaning, and I like descriptive product names.
Re: (Score:2)
Re: (Score:2)
Calling it "secure" is weaselly, as it will do very little to improve security for the users and their data.
Re: (Score:2)
Re: (Score:2)
Apple can do anything it wants with its OWN devices. When they start using their (non-existent) monopoly to force others to follow the same rules, its different.
You don't get to tell a company how to sell its own product just because it doesn't let you freeload on their work.
Re: (Score:2)
Anybody selling a system that prevents the user from using free software or OSs deserves a big, fat, nasty, very expensive, tour of courts all over the world.