|
|
Log in / Subscribe / Register

Garrett: Secure Boot and Restricted Boot

[Posted March 27, 2013 by corbet]

Matthew Garrett asserts that people attacking UEFI secure boot are aiming at the wrong target. "Those who argue against Secure Boot risk depriving us of the freedom to make a personal decision as to who we trust. Those who argue against Secure Boot while ignoring Restricted Boot risk depriving us of even more. The traditional PC market is decreasing in importance. Unless we do anything about it, free software will be limited to a niche group of enthusiasts who've carefully chosen from a small set of devices that respect user freedom. We should have been campaigning against Restricted Boot 10 years ago. Don't delay it even further by fighting against implementations that already respect user freedom."
to post comments

Garrett: Secure Boot and Restricted Boot

Posted Mar 27, 2013 14:32 UTC (Wed) by utoddl (guest, #1232) [Link] (119 responses)

I'll take it for the sake of argument that Matthew is right. But that quote is so overloaded with buzzwords I'd have as much chance explaining it to my dog as to my grandmother. Until we can come up with a way of describing the actual problem(s) to actual people, this will remain a niche argument to a niche group.

Garrett: Secure Boot and Restricted Boot

Posted Mar 27, 2013 15:53 UTC (Wed) by theophrastus (guest, #80847) [Link] (104 responses)

I've come to the conclusion, (some would say it was bloody obvious), that the terminology surrounding this topic was precisely chosen specifically to obfuscate its ramifications.

Garrett: Secure Boot and Restricted Boot

Posted Mar 27, 2013 16:34 UTC (Wed) by drag (guest, #31333) [Link] (103 responses)

The fundamental concept is actually very simple:

If you are able to install and manage your own keys then secure boot is beneficial. If you are not then it's destructive.

People continue to ignore it because it's inconvenient for their politics and that is how things get complicated. It's difficult to find new ways to explain the same things over and over to people in a hope that you find a way that get past their bias filters.

In this case 'Microsoft == Bad' is pretty much the part that you have to get past when taking to 'Linux enthusiasts'.

Never mind that there are plenty of worse behaving companies out there, like Apple. Never mind that Microsoft's version of secure boot respects user preferences and freedoms much more then anything that preceded it in the embedded ARM world. Just ignore all of this and concentrate on the fact that if Microsoft started it then it must be against Linux, because that is the only thing that makes sense in a lot of people's world view.

Garrett: Secure Boot and Restricted Boot

Posted Mar 27, 2013 16:58 UTC (Wed) by tshow (subscriber, #6411) [Link] (101 responses)

I think you'll find the worry here isn't so much "microsoft == bad" as it is "OEMs will take the path of least resistance".

Google a bit for BIOS and ACPI bugs. The people who wrote those are going to be the people implementing user loadable keys. If the past is any indication, you can be sure that something microsoft signed will boot, because it will have been tested by the OEM. Or, if the board is going to apple, it will have been tested booting something apple signed. Third party keys? Probably not so much.

That's (for me) the major worry here; the OEMs will either have slipshod implementation of user loadable keys, or they'll leave it out entirely, because why bother with the work for a fraction of the market?

The problem with the microsoft signed solution is that it gives the OEMs an out. It makes it easier for them to say "well, just use the $(corporation)-signed bootloader" and not fix/implement user keys.

Garrett: Secure Boot and Restricted Boot

Posted Mar 27, 2013 17:12 UTC (Wed) by mjg59 (subscriber, #23239) [Link] (100 responses)

Do you have any examples of systems shipping with Windows 8 and without support for user key management?

Garrett: Secure Boot and Restricted Boot

Posted Mar 27, 2013 17:33 UTC (Wed) by PaXTeam (guest, #24616) [Link] (1 responses)

do you know how to do it on a Lenovo Edge 430? all i see is (with the latest BIOS from february) that i can restore the factory keys but not how i can add my own.

Garrett: Secure Boot and Restricted Boot

Posted Mar 27, 2013 17:50 UTC (Wed) by mjg59 (subscriber, #23239) [Link]

Assuming it's like the X230 firmware, choose the option that returns you to setup mode. You can then enrol your choice of keys using the standard UEFI SetVariable calls.

Garrett: Secure Boot and Restricted Boot

Posted Mar 27, 2013 17:53 UTC (Wed) by zdzichu (subscriber, #17118) [Link] (10 responses)

Like Surface Pro tablet? I suppose it isn't Windows 8 certified, which is amusing for product by Microsoft.

Garrett: Secure Boot and Restricted Boot

Posted Mar 27, 2013 17:56 UTC (Wed) by mjg59 (subscriber, #23239) [Link]

You've verified that it doesn't let you return to setup mode?

Garrett: Secure Boot and Restricted Boot

Posted Mar 27, 2013 18:54 UTC (Wed) by dpquigl (guest, #52852) [Link] (8 responses)

From what I understand Surface Pro Tablets are Windows RT devices. They are ARM processors and the secure boot standard doesn't allow for ARM devices to turn off the secure boot functionality. However this isn't any different from the rest of the embedded world. Jail breaking a device and removing the security check doesn't make it any more free. You needed to exploit your device just to do what you wanted to.

Garrett: Secure Boot and Restricted Boot

Posted Mar 27, 2013 19:01 UTC (Wed) by mjg59 (subscriber, #23239) [Link]

You understand incorrectly. Surface RT devices are ARM and run Windows RT. Surface Pro devices are x86 and run Windows 8.

Garrett: Secure Boot and Restricted Boot

Posted Apr 3, 2013 12:40 UTC (Wed) by xilun (guest, #50638) [Link] (6 responses)

> Windows RT devices. They are ARM processors and the secure boot standard doesn't allow for ARM devices to turn off the secure boot functionality.

s/secure boot standard/Microsoft/

And given this arbitrary restriction (which makes no sense from the security POV, installing system software on a tablet being already arguably more difficult than on a fully featured computer): s/secure boot/restricted boot/

Garrett: Secure Boot and Restricted Boot

Posted Apr 3, 2013 15:18 UTC (Wed) by hummassa (guest, #307) [Link] (5 responses)

I find it funny -- strike that.
I find it HILARIOUS when people try to make a distinction between "secure" boot and "restricted boot". The infrastructure is the same, only varying the degree of control that Theoretically the end user has over the keys used to sign the bootloader and the loaded OS.

Garrett: Secure Boot and Restricted Boot

Posted Apr 3, 2013 16:34 UTC (Wed) by raven667 (subscriber, #5198) [Link] (4 responses)

Isn't the question of who controls policy the fundamental difference between beneficial security technology (firewalls, encryption, IDS, integrity checking, etc.) and oppressive security technology (firewalls, encryption, IDS, integrity checking, etc.) ? It seems that you are arguing that all security technology is bad because it can be used for bad things, a position usually held by authoritarians (who would of course retain all the security technology for their own use), although I doubt you belong to that group.

Garrett: Secure Boot and Restricted Boot

Posted Apr 3, 2013 18:11 UTC (Wed) by hummassa (guest, #307) [Link] (3 responses)

> It seems that you are arguing that all security technology is bad because it can be used for bad things

No, that is not what I am arguing at all. I am arguing specifically (for some time now) that:

1. "secure" boot technology is not secure at all; and
2. that anything beyond "make grub* be loaded, to load whatever I want after" is a waste of time and effort AND a collaboration with microsoft's efforts to keep linux out of the next generation of PCs|tablets|whatever_gadgets coming.

* substitute for favorite|possible bootloader here

Garrett: Secure Boot and Restricted Boot

Posted Apr 3, 2013 19:24 UTC (Wed) by raven667 (subscriber, #5198) [Link] (2 responses)

> 1. "secure" boot technology is not secure at all;

In what way is this architecture for simple integrity checking of the boot firmware and boot loader insecure against remote unauthorized attackers modifying the firmware or boot loader to hide and persist their root kits? The only attack surface I can see is the code which reads config variables which are under the possible control of an attacker, and I'm sure that code is limited and could be audited or fixed in the field to close any holes which are discovered.

Other application-security issues (buffer overflows in the browser or OS) are really not what this is about and no one is pretending that this is a miracle cure for unrelated security problems.

> 2. that anything beyond "make grub* be loaded, to load whatever I want after" is a waste of time and effort AND a collaboration with microsoft's efforts to keep linux out of the next generation of PCs|tablets|whatever_gadgets coming.

So any integrity checking of the kernel by the bootloader or of userspace by the kernel, none of which is defined by UEFI Secure Boot, is a bad thing? Is tripwire or AIDE a bad thing too? The whole point of the shim is to have total control over what boots after and to still allow you to verify that it hasn't been modified without your permission. A local user can trojan their own system if they want, I guess, Secure Boot won't attempt to stop them, but a remote attacker won't be able to do so from the running OS. At least that's the intent.

I don't see how MS is keeping Linux off the next generation of PCs when they already signed a boot loader that can boot any Linux system on a PC. As far as other gadgets, they are a mix of open and restricted devices, and no one is arguing against fighting boot-locking whenever it is encountered, MS isn't unique in this regard, most of the boot locked devices run Linux.

Garrett: Secure Boot and Restricted Boot

Posted Apr 3, 2013 21:41 UTC (Wed) by paulj (subscriber, #341) [Link] (1 responses)

When the kernel is insecure, when user-space is unlikely to be any better, why on earth would a rootkit *need* to modify the firmware? **ALL** it needs to do is arrange for an exploit to run early during boot. That exploit needn't even involve modifying any system binaries, if it can just exploit a bug in reading some data (which there are surely plenty - how well do,e.g., config file parsers get tested for security bugs?).

A "Secure" boot of utterly insecure software is meaningless.

Garrett: Secure Boot and Restricted Boot

Posted Apr 3, 2013 22:08 UTC (Wed) by raven667 (subscriber, #5198) [Link]

That is one opinion, but the kernel and userspace will never be any better or more secure than they are today and some people aren't willing to just throw up their hands and accept insecurity as the normal state of affairs without trying to do something about it. What you describe is correct, an exploit can be driven from config read during early boot, or attacker supplied code that exploits the system but the attack surface of config parsers is fairly small and well defined while the point where attacker supplied code can be run can be pushed later and later in the boot process via nested signature checking. Even in the case of an thoroughly compromised system the update process can be blocked but not modified so that the holes can be closed as they are found, leaving a working system which can be more reliably cleaned. Secure Boot gives you a small beachhead with which you have the opportunity to retake control of your system from a remote attacker, nothing more.

Garrett: Secure Boot and Restricted Boot

Posted Mar 27, 2013 18:45 UTC (Wed) by tshow (subscriber, #6411) [Link] (86 responses)

> Do you have any examples of systems shipping with Windows 8 and without support for user key management?

I do not. That said, I fail to see how that is relevant to the discussion; what I'm worried about is that the people who brought you (for instance, since I believe you're intimately familiar with this) the samsung laptop bricking bug are going to be the same people doing the firmware infrastructure for user key management.

User key management and disabling "secure boot" are going to be the less-trodden path, and the OEMs are going to treat them as such. The more excuses we give them to ignore or sideline those paths, the more likely they are to either be dropped, or (more likely) shipped in a worked-for-QA-the-one-time-they-tried-it-part-way-through-alpha state.

If they wind up shipping broken user key management or broken "insecure boot", what we don't want is for them to say: "Workaround: use $(corporation)-signed stuff" and then just let the bug go stale in the bug database. We want them to feel they need to fix it, even if it's one of those horrible "we did it all wrong, and the implications have tentacles reaching everywhere" can of worms bugs.

So, no, there are no such systems this year (as far as I know, assuming we're excluding winrt). That's not relevant. What's relevant is the balance of incentives for OEMs. The OEMs want to spend as little as possible developing products, and as little effort as possible on post-release maintenance. If we're going to keep the less-popular options available, we do ourselves no favours with workarounds, because it reduces the loss threat to the OEMs. If most people can get by with "just use stock $(corporation)-signed stuff", then the expense/reward math for the OEMs to fix "secure boot" or user key management bugs is dominated by the expense.

To be clear here, it's not malice on anyone's part I'm concerned with. My concern is that if we assume the major parties are imperfect (ie: their products will at times contain bugs) and are going to concentrate on their own short-term fiscal interest, we need (as much as we can) to set the playing field so the incentives are as favourable as possible to the outcome we want, which is for user key management and "secure boot" disabling to remain viable, and for problems in those systems to be treated seriously and fixed when they crop up.

That means anything the other players can point internally and say "well, only 0.0n% of users are actually affected by this because of $workaround" is poisonous.

Garrett: Secure Boot and Restricted Boot

Posted Mar 27, 2013 18:49 UTC (Wed) by mjg59 (subscriber, #23239) [Link] (85 responses)

The key management and disable path are explicitly required by Microsoft and are part of the hwcert process. If anyone ships without support then they're misrepresenting their system - it's not merely a "This machine doesn't do what I want", it's "This machine doesn't do what it's sold as doing". Microsoft gain nothing from permitting that confusion and have been very responsive when we identified some potential issues with pre-production hardware.

So, yes, the absence of any machines that fail to live up to these expectations is meaningful. The vendors have already had the opportunity to screw this up and haven't done so yet. There's no reason to believe that they're going to get worse at it.

Garrett: Secure Boot and Restricted Boot

Posted Mar 27, 2013 19:11 UTC (Wed) by tshow (subscriber, #6411) [Link] (4 responses)

> So, yes, the absence of any machines that fail to live up to these expectations is meaningful. The vendors have already had the opportunity to screw this up and haven't done so yet. There's no reason to believe that they're going to get worse at it.

That's a rather bold assertion. I haven't got any examples of machines that screw it up, but that's partly because (at this point) I haven't had to test any. Have you tested them all? They're all bug free? And that somehow implies all future products will be bug-free as well?

There have been bugs in BIOS implementations. There have been bugs in APM implementations. There have been bugs in ACPI tables. There have been bugs in IRQ routing. There have been bugs in shipping CPUs. I remember a motherboard (ASUS, IIRC, with a 200MHz Pentium MMX in it) at one place I worked that burned (literally -- the magic smoke got out) through 3 sets of L2 cache before we realized it was probably only ever tested with win95, and a 32bit OS that actually ran the hardware full tilt ran it too hot.

There *will* be bugs in these systems, and some of them *will* slip by QA and Microsoft's certification process even if everyone involved is being both diligent and fair.

Bugs happen. They *always* happen, in software, in microcode, in firmware and in hardware. The only question is whether the incentives are in place to convince the manufacturer to fix the problems when they arise.

Garrett: Secure Boot and Restricted Boot

Posted Mar 27, 2013 19:16 UTC (Wed) by mjg59 (subscriber, #23239) [Link]

Every machine I've tested (which is a number) is bug free in this respect. Can we guarantee that a given machine will not have any bugs that prevent users from being able to use it as they want to? No, but that's already true. What's different in this case is that there's a clear and absolute argument that a machine with this bug is defective and misleadingly advertised, which isn't true for many other bugs that would prevent you from running Linux.

Garrett: Secure Boot and Restricted Boot

Posted Mar 27, 2013 19:21 UTC (Wed) by drag (guest, #31333) [Link]

Certification processes are usually troublesome and expensive. Inevitably companies will ship their shit software/firmware on their shit hardware and it will cause problems. When those problems are identified and they do nothing to try to fix it for you or work around then they risk losing those certifications, which can be extremely expensive for the company in question. So while we can expect issues to happen, it's also reasonable to expect that for the most part issues will be resolved when they crop up.

Garrett: Secure Boot and Restricted Boot

Posted Mar 27, 2013 23:26 UTC (Wed) by s0f4r (guest, #52284) [Link] (1 responses)

There *will* be bugs in these systems, and some of them *will* slip by QA and Microsoft's certification process even if everyone involved is being both diligent and fair. Bugs happen. They *always* happen, in software, in microcode, in firmware and in hardware. The only question is whether the incentives are in place to convince the manufacturer to fix the problems when they arise. Microsofts certification is extremely rigorous, and the second line is already answered: vendors would not get certified, which means they lose the right to display logos and so on, which is IMHO a huge incentive - that is actually what the hardware vendors want - the "sticker". I do not doubt that Microsoft will take any vendor to court if it is caught illegally displaying the logo.

Garrett: Secure Boot and Restricted Boot

Posted Mar 27, 2013 23:56 UTC (Wed) by tshow (subscriber, #6411) [Link]

> Microsofts certification is extremely rigorous, and the second line is already answered: vendors would not get certified, which means they lose the right to display logos and so on, which is IMHO a huge incentive - that is actually what the hardware vendors want - the "sticker". I do not doubt that Microsoft will take any vendor to court if it is caught illegally displaying the logo.

Right. Which is why WHQL and "Microsoft Hardware" are bywords for quality.

Google "RROD".

Garrett: Secure Boot and Restricted Boot

Posted Mar 28, 2013 9:15 UTC (Thu) by paulj (subscriber, #341) [Link] (79 responses)

Required, *for now* for Windows 8 certification. I presume you can not guarantee this requirement will always remain?

Garrett: Secure Boot and Restricted Boot

Posted Mar 28, 2013 14:24 UTC (Thu) by raven667 (subscriber, #5198) [Link] (75 responses)

Who can guarantee anything, I could get hit by a bus tomorrow, in any event shouldn't we take action only on Restricted Boot technologies rather than pre-emmptively attack freedom-preserving Secure Boot out of fear or loathing of the company most responsible for it. It doesn't put us in any different or worse position to use Secure Boot technology that preserves freedom now and fight against Restricted Boot technology anywhere you find it, which seemed to be the point of mjg59's post.

Worst case is that the market for general purpose consumer computing segments into vendor silos (Apple, MS, Google) which might happen regardless of what we do but there will always be freedom-preserving hardware available in markets where Linux is dominant because there are enough customers who demand it to make it worthwhile. I don't expect that to happen right now though because its not in the best interest of hardware vendors to fight for the software OS vendors against their own customers, there'd have to be a lot of money on the line to make them mercenaries in that fight which otherwise doesn't involve them. It could happen though, look at the tiny entertainment industry bossing around the tech industry.

Garrett: Secure Boot and Restricted Boot

Posted Mar 28, 2013 14:43 UTC (Thu) by paulj (subscriber, #341) [Link] (74 responses)

Show me a market that is dominated by freedom-loving Linux users?

I'm not against Secure Boot per se. However Secure Boot doesn't really provide much in the way of security. It secures the boot, so you end up booting only the binaries you (or someone else) wanted, but it doesn't mean you are secure. For Secure Boot to meaningful, you need to have something Secure to boot into, but we are a long away from that in the field of software generally (and Linux, as is, will never be secure - will always be riddled with security sensitive bugs). The proponents of Secure Boot hand-wave this away, saying runtime security is out-of-scope. The raison d'etre of Secure Boot is security, but the non-deliverance of security by Secure Boot should not be held against it.

I'm not against Secure Boot of itself, the problem is that the API standardisation, code deployment, and infrastructure that is required for Secure Boot is exactly the same as that as for Restricted Boot.

As mjg59 frequently will point out, Secure Boot is required to be Secure Boot (on PCs) because the board vendors are (for now) required to keep the "allow the key DB to be modified" 'bit' enabled. However, clearly this means there is very *LITTLE* difference between Secure Boot and Restricted Boot.

The hard work has now been done. The large Linux vendors have acquiesced to signing their distros with 3rd party keys - not those of users either! There is literally nothing now, technologically, to stop the 'bit' from being flipped in the future. It will no longer affect Linux vendors.

I also, along with the rest of us, hope it will not be. However, I can't say I feel good that we're now in that position. I guess I'll just have to be glad that my utterly insecure Linux kernel has been Secure Booted.

Garrett: Secure Boot and Restricted Boot

Posted Mar 28, 2013 16:38 UTC (Thu) by raven667 (subscriber, #5198) [Link] (73 responses)

> Linux, as is, will never be secure - will always be riddled with security sensitive bugs). The proponents of Secure Boot hand-wave this away, saying runtime security is out-of-scope. The raison d'etre of Secure Boot is security, but the non-deliverance of security by Secure Boot should not be held against it.

I think the main misunderstanding here is that security is a continuum of risk and mitigation expense, not an absolute binary, on-off, square-wave. It's not hand-waving dismissal, it's acknowledgement of a fundamental truth.

> As mjg59 frequently will point out, Secure Boot is required to be Secure Boot (on PCs) because the board vendors are (for now) required to keep the "allow the key DB to be modified" 'bit' enabled. However, clearly this means there is very *LITTLE* difference between Secure Boot and Restricted Boot.

That is a fundamental difference though, even if a technically small one.

> The large Linux vendors have acquiesced to signing their distros with 3rd party keys

To be fair the only thing which is signed by a third party is the shim, everything after that including the full bootloader, the kernel, modules, etc. are signed by authorities which don't depend on Secure Boot, Secure Boot only affects the first thing the EFI loads, what policy you enforce after that, if any, is up to you.

The linux vendors have no interest in supporting locked down hardware as far as I can tell.

Garrett: Secure Boot and Restricted Boot

Posted Apr 4, 2013 8:50 UTC (Thu) by paulj (subscriber, #341) [Link] (72 responses)

Yes, security is a continuum, and there is no such thing as perfect security. There are many security people (or people working on security technologies) who often forget that, typically because they overly focused on some specific threat and ignore the bigger picture (or, it is not their job to consider the bigger picture), or alternatively because they will not bear the costs of what they are proposing/implementing.

There are many security steps you might take which, while not offering perfect security, are still worthwhile. E.g. it is worth locking my door, even though this would not stop someone who is prepared to bash the door in. However, fitting a lock to my front door would *not* be the best prioritisation of my resources if the windows and other external entrances still hadn't had window frames & glass, & doors fitted.

I.e. security measures have to be seen in context. Any given security measure can not be said to be worthwhile of itself. It must be assessed in context with the threat - realistic threats - AND in context with the rest of the system the security measure will be put in place with.

General purpose OSes, and the software they run today are ridiculously insecure. Secure Boot can NOT secure a Linux system from at-boot infection from the class of attackers who can write rootkits or firmware exploits. Because it is equally possible to write an exploit for early, privileged userspace, and use a general runtime exploit to install it. "Secure Boot" buys you *nothing* in this context. Similarly, I don't believe "Secure Boot" will do anything to make Windows 8 more resistant to viruses and malware.

However, "Secure Boot" CAN prevent the average *OWNER* of the machine from using the machine - once the "restricted boot" bit is set by some other party (e.g. the hardware vendor). In this context, the "Secure Boot" technology does indeed generally work. It makes "Restricted Boot" work.

"Secure Boot" will not help security on general purpose Linux machines, from capable attackers. The main class of people who could possibly be stymied by "Secure Boot" are the users. All the other instances of this technology, from Tivo to game-consoles, to phones, are being used to prevent *OWNERS* from having full access to their hardware.

To think "Secure Boot" is about helping owners secure their own machines against others seems very very naïve to me.

Garrett: Secure Boot and Restricted Boot

Posted Apr 7, 2013 9:41 UTC (Sun) by kleptog (subscriber, #1183) [Link] (42 responses)

I think you're being very pessimistic. Yes, it's possible to malware to simply stick something in the early boot sequence and it will get run. That's because nobody has ever bothered to build any verification in because there's no point unless you know the kernel you're running is trusted and until recently that was essentially impossible. A classic chicken and egg problem.

With secure boot you finally have a method to trust the kernel and early userspace which means it becomes feasible to start enforcing useful policy, such as "users may only run programs that come from signed packages".

Besides, you don't need to secure an entire Windows system, you only need to secure it far enough to be able to start your virus scanner without loading any malware first so the malware can't hide itself from the scanner.

Garrett: Secure Boot and Restricted Boot

Posted Apr 7, 2013 12:13 UTC (Sun) by hummassa (guest, #307) [Link] (2 responses)

My sistematic opposition to "secure" boot is based on the following argument:

1. yes, it *is* a (small) beachhead; BUT
2. it is a very strategic and hijack-able beachhead that can be used by a third player (not you nor the malware author) to support this third players's interests in detriment of yours; AND
3. it is a somewhat useless beachhead because you cannot secure the post-boot env enough.

Garrett: Secure Boot and Restricted Boot

Posted Apr 7, 2013 16:10 UTC (Sun) by raven667 (subscriber, #5198) [Link] (1 responses)

> strategic and hijack-able beachhead

How is that supposed to work?

Garrett: Secure Boot and Restricted Boot

Posted Apr 7, 2013 17:34 UTC (Sun) by hummassa (guest, #307) [Link]

By flipping the theoretical bit that separates "secure" boot from "restricted" boot. Then the only bootable things will be those that are approved by the third party (the original hw's OS vendor, in casu, Microsoft).

Garrett: Secure Boot and Restricted Boot

Posted Apr 7, 2013 12:29 UTC (Sun) by paulj (subscriber, #341) [Link] (38 responses)

So go "fix" the system so that all privileged code, kernel or userspace, that is guaranteed to run (i.e. cause it is involved in starting the system) is secure. And *then* implement Secure Boot.

Because, until you have something secure to actually boot, all that Secure Boot infrastructure will do is give vendors/media companies a very tempting switch to flip over to "Restricted Boot". This technology tends to only be "Secure" against normal computer users - i.e. the end-user, the owner of the device.

Do that, and *then* come back about Secure Boot. Until then, you're only handing the vendor/media companies a tool that is effective mostly for DRM. And some of the vendors are ALSO media companies.

I'm not being pessimistic. Making software secure is hard. Very very hard. Vendors have tried to get "Restricted Boot" on other platforms, and mostly they fail, despite having much more control over the code that will be run, and (often) that code being much reduced and having less scope for attack than on a Linux or Windows system.

Garrett: Secure Boot and Restricted Boot

Posted Apr 7, 2013 13:16 UTC (Sun) by kleptog (subscriber, #1183) [Link] (37 responses)

Things are being fixed. When going for an end goal it's usually a good idea to tackle all the remaining problems in parallel, rather than doing them serially. You correctly point out that solving each problem (boot, kernel, userspace) individually is useless, so they are being tackled all at the same time.

I don't understand your argument about DRM, since a system cannot determine whether it was booted securely or not. That makes it kinda pointless for DRM. All secure boot can do is refuse to boot if it finds something wrong.

You're right that securing software is hard, but the only goal here is to secure the boot process, not the entire system. This makes the problem much more tractable. Even if all we achieve is the extinction of boot malware then I think it all worthwhile.

Anyway, it seems to me that doing nothing is the worst option, since hardware with this enabled is shipping right now and doing nothing means Linux won't boot on those machines without extra steps.

Garrett: Secure Boot and Restricted Boot

Posted Apr 7, 2013 13:31 UTC (Sun) by hummassa (guest, #307) [Link] (1 responses)

> I don't understand your argument about DRM, since a system cannot determine whether it was booted securely or not. That makes it kinda pointless for DRM. All secure boot can do is refuse to boot if it finds something wrong.

Your argument is inconsistent. At the point where you restrict the boot, the system can determine that it was booted securely by the simple fact that it is running.

Garrett: Secure Boot and Restricted Boot

Posted Apr 7, 2013 15:42 UTC (Sun) by raven667 (subscriber, #5198) [Link]

No, I don't think it works that way because the verification is done in the previous layer of code and there is no reliable signalling to the next layer signifying whether it did any checks at all.

Anything that can be booted in Secure Boot mode can also be booted without Secure Boot enabled and it won't know the difference. Your Secure Boot capable bootloader/kernel can't refuse to start on a non-Secure Boot enabled system, or one that is faking Secure Boot checking. For example a VM.

Garrett: Secure Boot and Restricted Boot

Posted Apr 7, 2013 13:42 UTC (Sun) by paulj (subscriber, #341) [Link] (34 responses)

Yes, it may be better to do things in parallel, to achieve a task. However, you miss the point entirely.

The task - "Secure Boot" - is likely not achievable. At least it is not achievable against the class of attacker against whom Secure Boot is aimed at, those sophisticated enough to be able to subvert the system at runtime, so as to be able to subvert which software is booted. If they can do this, they can subvert the system at runtime *again* and *again*.

If the task is not achievable, then implementing the "Secure Boot" technology doesn't help get you there. However, it does get you toward "Restricted Boot", which *does* work - most computer users are not sophisticated enough to get around it on their own without help. Even if that help exists in the form of a ready to run unlock, it often has bricking-risks that not all users want to take.

As for DRM, DRM does NOT require a "determine whether it was booted securely flag". I've heard someone claim this was a requirement before, and it's simply a non-sense. It is *only* required IFF the system is designed to be allowed to booted unrestricted. IF the system ONLY allows "Restricted Boot", then there is NO NEED for a flag - the platform is *assumed* secure.

E.g., assume Windows "8+X" (X>=1) will specify boot MUST be restricted. Then any programme designed so it can only run on "8+X" has NO NEED for a flag in order to be able to assume it has been booted on a "Restricted Boot" platform.

Garrett: Secure Boot and Restricted Boot

Posted Apr 7, 2013 15:52 UTC (Sun) by raven667 (subscriber, #5198) [Link] (33 responses)

Even in your Win9+ case the running system still doesn't know whether integrity checking existed when it booted, it could be booted on a system without integrity checking and wouldn't know the difference. A system can't refuse to boot if Secure Boot isn't enabled as far as I know, so can be booted on non-Secure Boot enabled hardware (or VM) and have any "DRM" restrictions trivially bypassed. It wouldn't be useful for protecting anything valuable.

Wouldn't it be better to agitate against boot locking where it exists (in the ARM world) rather than where it explicitly isn't?

Garrett: Secure Boot and Restricted Boot

Posted Apr 7, 2013 16:51 UTC (Sun) by paulj (subscriber, #341) [Link] (32 responses)

It doesn't matter, if you simply can't buy a platform that doesn't have integrity checking. Further, the lack of a flag in Secure Boot does not preclude that flag being added. If/when it is added, it will not affect software that doesn't know about it.

The hard part to getting Restricted Boot deployed was always going to be the non-MS OSes and allowing them to still boot. The major non-MS PC OS has happily gone along with implementing the required interface. The lack of a flag today, or addition of any future one, will now not prevent those OSes booting in Restricted Boot mode, should the bit ever get flipped.

If that happens, the Linux vendors will no longer have any meaningful dog in the fight, with which to raise a stink about.

Garrett: Secure Boot and Restricted Boot

Posted Apr 7, 2013 17:15 UTC (Sun) by mjg59 (subscriber, #23239) [Link] (31 responses)

"the lack of a flag in Secure Boot does not preclude that flag being added"

Correct - it's the fact that it's impossible to add such a flag that precludes that flag being added.

Garrett: Secure Boot and Restricted Boot

Posted Apr 7, 2013 18:10 UTC (Sun) by paulj (subscriber, #341) [Link] (30 responses)

Why would it be impossible?

I think it'd be impossible for it to be impossible tbh.

Garrett: Secure Boot and Restricted Boot

Posted Apr 7, 2013 18:15 UTC (Sun) by mjg59 (subscriber, #23239) [Link] (29 responses)

If you can trust the firmware, there's no point in the firmware setting a flag to indicate that it's trusted. If you can't trust the firmware, you can't trust the state of any flag it's providing.

Garrett: Secure Boot and Restricted Boot

Posted Apr 7, 2013 18:46 UTC (Sun) by hummassa (guest, #307) [Link] (19 responses)

Garrett, you keep ignoring the point here; and that is: "secure" boot does not help securing the boot process, but it DOES help the bad guys to push restricted boot down the line.

Garrett: Secure Boot and Restricted Boot

Posted Apr 7, 2013 18:56 UTC (Sun) by mjg59 (subscriber, #23239) [Link] (18 responses)

>"secure" boot does not help securing the boot process

By that argument selinux doesn't improve security because there exist kernel exploits that allow you to disable it. Having a separate root account doesn't improve security because there exist userspace exploits that allow elevation of privileges. Passwords don't improve security because there are flaws in web browsers that allow attackers to run keyloggers.

Security isn't binary. Secure Boot on its own doesn't make the boot process entirely secure, but it does make it more secure. It's also a prerequisite for any real security implementation.

Garrett: Secure Boot and Restricted Boot

Posted Apr 7, 2013 20:35 UTC (Sun) by paulj (subscriber, #341) [Link] (17 responses)

raven667 also gave the "security isn't binary" argument before, my response to that is at: http://lwn.net/Articles/545877/

The problem with your example is that you have the pre-requisites the wrong way around. A more secure/controlled user-space, which technologies like SELinux try to give, is the *pre-requisite for Secure Boot*. Further, Secure Boot *also* requires a secure kernel, at least one a lot more secure than we have today. We are a *long* way from having this.

Now, once you have secured kernel and user-space to the point you can have some confidence that all software that is guaranteed to run (e.g. start-up) is unlikely to be subverted by the class of attacker you're worried about, then here's the funny thing: You don't need Secure Boot anymore!

The amazing thing about Secure Boot is that for it to worth anything to the owner, it requires the very thing that would render it moot.

However, Secure Boot is still worth something to others - it gets "Restricted Boot \ 1 flag" implemented, deployed and supported by Windows and all the major PC OSes. When that is done, then if someone flips that bit, there will be no Linux vendor left who can say "that breaks our boot".

Garrett: Secure Boot and Restricted Boot

Posted Apr 7, 2013 20:45 UTC (Sun) by mjg59 (subscriber, #23239) [Link] (8 responses)

And selinux would be unnecessary if userspace were already secure, so it's also pointless?

Garrett: Secure Boot and Restricted Boot

Posted Apr 7, 2013 22:33 UTC (Sun) by hummassa (guest, #307) [Link] (6 responses)

The problem here is that our argument is: deep "secure" boot support collaborates with future restriction of boot. SElinux, OTOH, does no such thing.

You can see another difference in nomenclature: one pretends to be "secure", the other explicitly states that it is "security-enhanced". Who is blatantly lying to the consumer? :-D

Garrett: Secure Boot and Restricted Boot

Posted Apr 7, 2013 22:40 UTC (Sun) by mjg59 (subscriber, #23239) [Link] (5 responses)

So it adds security, you just worry that it can be used for evil? That's not what you said earlier.

Garrett: Secure Boot and Restricted Boot

Posted Apr 11, 2013 13:39 UTC (Thu) by hummassa (guest, #307) [Link] (4 responses)

Actually, if you open this whole thread and search for my comments, you'll see that it's exactly what I have been saying all along.

Garrett: Secure Boot and Restricted Boot

Posted Apr 11, 2013 14:05 UTC (Thu) by mjg59 (subscriber, #23239) [Link] (3 responses)

You said

>"secure" boot does not help securing the boot process

in http://lwn.net/Articles/546340/ .

Garrett: Secure Boot and Restricted Boot

Posted Apr 11, 2013 17:29 UTC (Thu) by hummassa (guest, #307) [Link] (1 responses)

you redacted the important part of the sentence... ;-)

Garrett: Secure Boot and Restricted Boot

Posted Apr 11, 2013 17:36 UTC (Thu) by mjg59 (subscriber, #23239) [Link]

The rest of it says nothing about security, so I'm not sure how it's relevant to the case in hand.

Garrett: Secure Boot and Restricted Boot

Posted Apr 11, 2013 17:43 UTC (Thu) by hummassa (guest, #307) [Link]

I will complement my last comment, above, trying to clarify my position. English is not my native language, so I apologize if not everything I think about the subject came across.

1. I believe the difference between what is called "secure" and "restricted" boot modes is a single bit in policy.

2. I do believe "secure" boot adds to security -- like locking your door, it does not add a lot, but you only has to run faster than your campmate when the bear comes. Mixing metaphors rules!

3. It is my impression that, just like locking your door, "secure" boot is not a deterrent to a determined, targeted attack... and those are the ones that worry me more.

4. In my firm opinion, "secure" boot plays into the commercial interests of the same people that are pushing, and will continue pursuing, "restricted" boot.

5. In conclusion, it is my opinion that doing any more work WRT "secure" boot once the loading shim is already signed and working is a disservice to the free and open source software community.

6. Even so, it is also my believe that I don't have the right tell you (or anyone else) what free software you should or should not work on (unless I pay you to work in whatever I want only).

7. But I have the right to think that people are being silly and pointing it out.

Garrett: Secure Boot and Restricted Boot

Posted Apr 8, 2013 5:08 UTC (Mon) by paulj (subscriber, #341) [Link]

SELinux allows the admin to control how running software interacts, including software not critical to startup, and software that interacts with the outside world, and software that dumb/malicious users might run (inc. software they load into the box). It can restrict what compromised software can do. It brings tangible benefits to securing user-space, particularly for network facing software, despite its complexity.

Security in context: What does Secure Boot add against the type of attackers sophisticated enough to subvert the kernel and modify boot? Why _aren't_ these attackers also capable of just subverting the boot, again and again?

There's a whole class of software, and methods of attacking it, that have traditionally been viewed as "not security-sensitive", which suddenly become *front-line* once you have Secure Boot, from /etc config files, to state in /var, to kernel modules, to on-disk fs data structures (h/t Al). If those fail, then there'll still be a wealth of data read by non-privileged programmes from which to get started up and then run a kernel exploit.

The Google Chrome security bounties have demonstrated that we over-estimate the benefits of just adding additional hoops, and that the X-hats are incredibly capable at stringing together exploits of long chains of bugs into attacks.

Garrett: Secure Boot and Restricted Boot

Posted Apr 7, 2013 21:51 UTC (Sun) by kleptog (subscriber, #1183) [Link] (7 responses)

Secure Boot doesn't require a secure kernel. Let's assume the kernel is insecure, a reasonably valid assumption as you point out.

Case 1: Malware uses a vulnerability in the kernel to join a botnet and hide itself from userspace. This is out of scope for secure boot so not relevant.

Case 2: Malware uses a vulnerability in the kernel to modify the boot sector so it gets run the next time the computer starts up. The next boot the firmware checks the boot sector and complains to the user that there's an unverified boot sector and that the user should use a boot CD to clean it. Secure Boot achieves it's goal because it's impossible for the malware to install a boot sector that passes the test.

Now you can say that the malware will just install itself into /etc/rc.d/ instead and you'd be right. That's just because no-one has written the code to do any verification on that directory, not because it's not possible. Those tests would be effective at preventing the malware running on boot *even if the kernel was insecure*.

The only thing Microsoft (really Verisign) requires before signing a bootloader is that it can't be used by malware to subvert the windows boot process so it can pass the boot sector test. But this is a social problem which can't be solved by technical means. That's why a bootloader which says "Hi! You're booting MyBootLoader. If this is not what you're expecting contact technical support. Press any key to continue." would probably get signed since it won't allow malware to hide itself.

Garrett: Secure Boot and Restricted Boot

Posted Apr 7, 2013 22:44 UTC (Sun) by viro (subscriber, #7872) [Link] (6 responses)

Bullshit. Suppose the kernel hole in question is in e.g. parsing on-disk metadata. You are going to mount root fs, right? And all the "let's make sure /etc/rc.d/ isn't modified" crap in the world is not going to do anything about that, since no visible files need to be modified.

And before you go into "oh, but that reduces attack surface" - not really. Consider a combination of (1) hole in some piece of shit desktop software that goes through luser's homedir and cross-references his pr0n stash^W^Wphoto collection with (2) kernel exploit of any kind used by the code hidden in said collection and executed by (1). Sure, it'll wait until the luser logs in. BFD.

Once a box had been had, it's been had, period.

Garrett: Secure Boot and Restricted Boot

Posted Apr 8, 2013 2:10 UTC (Mon) by raven667 (subscriber, #5198) [Link]

That sounds like a nasty scenario but I don't think any general security technology can fix that but even in this case you could safely download an updated kernel and the most your fully owned system could do is block the update, it couldn't modify it.

Garrett: Secure Boot and Restricted Boot

Posted Apr 8, 2013 18:09 UTC (Mon) by kleptog (subscriber, #1183) [Link] (4 responses)

Sure, it'll wait until the luser logs in. BFD.
Actually, I find this a BFD. It means the virus scanner started at boot has a chance to download new signatures and scan for the malware before it has a chance to run. That's a significant improvement over the current situation.

Garrett: Secure Boot and Restricted Boot

Posted Apr 8, 2013 20:26 UTC (Mon) by viro (subscriber, #7872) [Link] (3 responses)

In which respect? That Scamantec and their ilk get money from more suckers? I had a front-seat view of some of their games and I'd trust a politician sooner than those shits. If you rely on their products, you deserve everything you get - stupidity must be punished, after all...

Garrett: Secure Boot and Restricted Boot

Posted Apr 8, 2013 22:37 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link] (2 responses)

So when is Linux going to be completely exploit-free with rigidly defined security sandboxes isolating applications' data?

What? You say "never"?

Garrett: Secure Boot and Restricted Boot

Posted Apr 9, 2013 11:32 UTC (Tue) by hummassa (guest, #307) [Link] (1 responses)

I seriously doubt this goal is even possible.

Garrett: Secure Boot and Restricted Boot

Posted Apr 9, 2013 15:27 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link]

And that's why antiviruses are a practical compromise. Yes, they are an ugly kludge but reality is also quite ugly.

If Linux were as popular as Windows then it would have needed antivirus-like applications as well.

And yes, Android actually already has an antivirus app that runs on Google's servers.

Garrett: Secure Boot and Restricted Boot

Posted Apr 7, 2013 20:36 UTC (Sun) by paulj (subscriber, #341) [Link] (8 responses)

Then this flag argument is generally specious, and there is no Restricted Boot that needs it.

Garrett: Secure Boot and Restricted Boot

Posted Apr 7, 2013 20:50 UTC (Sun) by mjg59 (subscriber, #23239) [Link] (7 responses)

Right. So Secure Boot is completely worthless as a DRM-enforcement mechanism. Restricted Boot is not.

Garrett: Secure Boot and Restricted Boot

Posted Apr 8, 2013 5:16 UTC (Mon) by paulj (subscriber, #341) [Link] (6 responses)

Restricted Boot doesn't need a flag either. There are systems which big media companies assume to be secure and have working DRM, simply by dint of platform information. No other flags needed. It might not be true, but it seems to be good enough for the likes of the BBC.

Garrett: Secure Boot and Restricted Boot

Posted Apr 8, 2013 6:32 UTC (Mon) by mjg59 (subscriber, #23239) [Link] (5 responses)

I have no idea what you're trying to say here, so I'm just going to reiterate that there's no way to use Secure Boot as a DRM mechanism and if you disagree then you can describe exactly how it's supposed to work.

Garrett: Secure Boot and Restricted Boot

Posted Apr 8, 2013 6:41 UTC (Mon) by paulj (subscriber, #341) [Link] (4 responses)

You recognise Restricted Boot is useful for building a DRM system (2 comments above this). You say a flag is pointless for Secure Boot, it is then equally pointless for Restricted Boot, by the very same argument. I don't even know why this flag issue was brought up (I didn't).

The fact still remains that "Secure Boot" differs from "Restricted Boot" by 1 bit of information, which is at the whim of a number of hardware vendors.

Garrett: Secure Boot and Restricted Boot

Posted Apr 8, 2013 6:55 UTC (Mon) by mjg59 (subscriber, #23239) [Link] (3 responses)

So… you're agreeing that Secure Boot isn't useful as a DRM mechanism? Like I said, I have no idea what you're trying to say here.

Garrett: Secure Boot and Restricted Boot

Posted Apr 8, 2013 7:23 UTC (Mon) by paulj (subscriber, #341) [Link] (2 responses)

You have said Restricted Boot is useful for a DRM system. You don't seem to quibble that Secure Boot and Restricted Boot differ by anything more significant than a bit of information controlled by the maker. I'm sure you're more than intelligent to understand what the implication is, should you be motivated to understand.

Garrett: Secure Boot and Restricted Boot

Posted Apr 8, 2013 14:34 UTC (Mon) by mjg59 (subscriber, #23239) [Link] (1 responses)

No, I think you're going to have to be explicit about what you're saying.

Garrett: Secure Boot and Restricted Boot

Posted Apr 8, 2013 18:21 UTC (Mon) by kleptog (subscriber, #1183) [Link]

Actually, I'd like clarification how Restricted Boot helps a DRM system. AFAICS it will merely lull media companies into a false sense of security because they might think it actually secures the system while it only secures the boot process.

Take any software that implements DRM, run it in a VM and you can bypass anything. You will need to arrange to run the exploit every boot though.

I find most interesting the contrast:

Securing a PC against malware - good
Securing an platform against hacks on the DRM - bad

While these two situations are technically indistinguishable.

Garrett: Secure Boot and Restricted Boot

Posted Apr 8, 2013 18:50 UTC (Mon) by raven667 (subscriber, #5198) [Link] (28 responses)

> However, fitting a lock to my front door would *not* be the best prioritisation of my resources if the windows and other external entrances still hadn't had window frames & glass, & doors fitted

I have two points here, 1) The development labor happens in parallel and independently so there is no prioritization implied, work on Secure Boot doesn't take away work from other security technologies, multiple things can be worked on at once. 2) There is already quite a depth of available security technologies from permissions to SELinux to various sandboxing and namespace technologies to whole VMs so it is not fair to say that other avenues of attack aren't covered in some way. Secure Boot is a fall back position to help recover a system when those other technologies have failed but those other technologies are on the front line of defense and are being worked on all the time.

> Because it is equally possible to write an exploit for early, privileged userspace, and use a general runtime exploit to install it. "Secure Boot" buys you *nothing* in this context.

This really depends on how far you can extend your prevention of unauthorized remote modification. At some point you have to allow arbitrary code to run but the farther you can push that out the more base OS tools you can fall back on to reliably clean out the later layers, including anti-malware software.

> However, "Secure Boot" CAN prevent the average *OWNER* of the machine from using the machine - once the "restricted boot" bit is set by some other party (e.g. the hardware vendor). In this context, the "Secure Boot" technology does indeed generally work. It makes "Restricted Boot" work.

Secure Boot _can't_ be used to prevent the owner of the machine from doing what they like because that's not how the policy works, so that's not how the technology works. Fighting against a policy change to enable boot locking, which is what the article is about and where you share common ground, doesn't require one to be against boot time signature verification in any form just because it uses the same technology.

You can join on the common ground of being generally against boot locking if you are willing to accept that some people do actually like the idea of user-controlled boot time signature verification.

I see this whole debate, of being generally anti-SecureBoot, as being the same arguments as being anti-encryption. The anti-encryption stance is that "bad guys" might use unbreakable encryption to "bad things" so therefore no one should be allowed to have encryption without allowing that the "good guys" use of encryption outweighs the potential for bad use.

Garrett: Secure Boot and Restricted Boot

Posted Apr 8, 2013 20:19 UTC (Mon) by paulj (subscriber, #341) [Link] (27 responses)

On the labour point: this only makes sense if:

a) The overall goal is achievable

OR

b) The sub-task delivers some benefit of its own, regardless of whether or not the overall goal is achievable.

It is highly doubtful that the overall goal is achievable, at least not with the way the software that compromises a Linux system is developed today. Indeed, it's highly uncertain the overall goal is achievable at all.

So then the question is about b, what does "Secure Boot" achieve, if it is booting software that is swiss cheese to any half-decent exploit writer (but not to ordinary users, necessarily)? If nothing, then it is (at best) labour wasted. At worst, it is deploying a system that will only secure systems against normal users, but not capable crackers (or those with access to the tools of such).

What exactly will "Secure Boot" achieve, in the context of a full system? What threats will it guard against?

Garrett: Secure Boot and Restricted Boot

Posted Apr 8, 2013 21:15 UTC (Mon) by raven667 (subscriber, #5198) [Link] (26 responses)

> What exactly will "Secure Boot" achieve, in the context of a full system? What threats will it guard against?

It gives you the benefits of booting off read-only media but with the ability to update software without changing physical media. It provides a small limit on the ways an attacker can hide their activity by modifying your system and gives you some control over the software that you run, how much control you have is up to how much control you implement.

>At worst, it is deploying a system that will only secure systems against normal users, but not capable crackers (or those with access to the tools of such).
> If nothing, then it is (at best) labour wasted.

Agreed there is no point in wasting a lot of time on fancy control schemes when malware writers have clearly demonstrated the ability to just bury their malware in deeper layers of the systems if they have to. That's one reason why there hasn't been a lot of work on anti-malware tools on Linux although there has been a lot of work on sandboxing and containment technologies.

Garrett: Secure Boot and Restricted Boot

Posted Apr 9, 2013 5:23 UTC (Tue) by paulj (subscriber, #341) [Link] (22 responses)

I don't understand the read-only media / update benefit? Secure Boot doesn't give you read-only media (see previous discussions about using existing data to exploit the "Secure Boot"ed software). You would need to heavily restrict the ability of the "Secure" software to load or read any external data, as well as restrict the ability of any user to modify any of the existing data. At that point, you no longer have a general purpose system.

The attackers that are controlled will be the unsophisticated ones, the ones who can't write an exploit to begin with, and who don't have access to the ones already written. I.e. users who aren't generally in the habit of subverting boxes anyway, aren't aware of / in the security/cracking scene. I.e. normal users.

What is your view on how the benefits to user-owners of "Secure Boot" weigh up against the risks that others use this technology to "Secure" the machine against the user-owner? E.g. those who control the software/machine before it is given to the user-owner, such as the vendor? Clearly you believe this system can be used to secure a machine to at least some extent (and I agree). So why not against the user-owner? All it takes is for the vendor to /remove/ one feature. That is 1 bit of information's difference to go from "Secure Boot" to "Restricted Boot". Why will this not happen?

Can you at least acknowledge this is a risk?

Garrett: Secure Boot and Restricted Boot

Posted Apr 9, 2013 16:31 UTC (Tue) by raven667 (subscriber, #5198) [Link] (15 responses)

> I don't understand the read-only media / update benefit?

I was just trying to say that the security properties it is trying to achieve are analogous to the properties of booting from read-only media, but with the ability to install updates even when running on Satan's Machine.

> You would need to heavily restrict the ability of the "Secure" software to load or read any external data, as well as restrict the ability of any user to modify any of the existing data. At that point, you no longer have a general purpose system.

There is definitely the possibility of implementation bugs that trigger on the data which is loaded from early boot or by the OS. Filesystem bugs have been demonstrated in practice on USB sticks and are very nasty indeed. The difference is that you still have the ability to reliably patch the system, the fix can't be modified in transit. I should also point out that there is a limited attack surface that can be modified remotely affecting early boot so a greater benefit from auditing the critical code paths that touch untrusted data.

> What is your view on how the benefits to user-owners of "Secure Boot" weigh up against the risks that others use this technology to "Secure" the machine against the user-owner?

I think it has a small but clearly tangible benefit while the risk is nebulous and in-tangible. There is a large installed base of systems such as Win7, Linux, *BSD which don't support a boot-locked, Tivoized system so I don't see the existing hardware getting firmware updates which change this behavior and break those installed systems. All of this is happening out in the open so it is no mystery if, in the future, a vendor tries to ship a boot-locked system or if MS tries to boot lock the next generation of hardware, there will be plenty of warning. That is something we all agree can and should be fought.

> Why will this not happen?

Even in the phone market where boot locking is very common many vendors don't boot lock their devices and some (Google Nexus) explicitly call out the openness as a feature. I don't think it a likely outcome that the general purpose PC market becomes _more_ restrictive and locked down than the smart phone market. If MS and the hardware vendors wanted the machines to be boot locked then there would probably just be different SKUs for Win8 bootlocked machines and general purpose machines, like you see in the smart phone industry, but that's not what happened.

> Can you at least acknowledge this is a risk?

Is there a reasonable risk that some vendor at some time will try an sell a boot locked x86 PC, sure that's possible, don't buy those machines and expect to run Linux on them, but is there a large risk that the vast majority of the market in the future, or the machines already shipped, become boot locked, I don't think that's a foreseeable outcome. I think it would be expensive and difficult to get hardware vendors and customers on that bandwagon for very little benefit as MS already gets a cut of most machine sales. Secure Boot can't even tell if you paid for the bits, only that they are signed, so it's useless against piracy.

Thanks for the lively and civil debate, I think we both understand each other's ideas now and we agree on the core argument that boot locking is bad but I don't see the value in rejecting any boot verification, even an open, user-controlled one, just because it works like boot locking.

Garrett: Secure Boot and Restricted Boot

Posted Apr 9, 2013 16:57 UTC (Tue) by paulj (subscriber, #341) [Link] (12 responses)

You can't patch a compromised system back to non-compromised status. The rootkit can just lie to you that it has installed the update. It can lie to you about the kernel version in boots there-after.

Once your box is compromised, you're hosed.

You're deluding yourself that Secure Boot gives you the equivalent of "read-only media, except to the software I trust", because the base OS is simply *way* too large to trust to be secure against exploits. At least, for a general purpose, generally programmable OS.

What you /really/ want is a "Secure Layer" between the software you don't trust (i.e. pretty much all software), and the software you have no choice but to trust (i.e. the base OS, which is on your side, but is too large and has to do too much low-level, fiddly work to be securable). Secure Boot doesn't give you that layer. The claimed security benefits are illusory.

Garrett: Secure Boot and Restricted Boot

Posted Apr 9, 2013 18:44 UTC (Tue) by raven667 (subscriber, #5198) [Link] (11 responses)

> You can't patch a compromised system back to non-compromised status. The rootkit can just lie to you that it has installed the update. It can lie to you about the kernel version in boots there-after.

It can fail to install the update but not hide that fact, it can't modify the boot procedure so you'd still be visibly booting the old kernel. If you can push update code into the verified part of the boot process, from the systemd recovery console maybe, then you might be able to update before the malware could even block it. You can certainly do that for the UEFI firmware itself which has a network stack and drivers that are available before your system could be re-exploited by malware.

Of course, as I mentioned in the other thread, an exploit through unvalidated data reads such as configs, variables or filesystem mounts could subvert your checking before it gets off the ground but that's true regardless of the security precautions, your SELinux or file permissions aren't much good after malicious code is running around in the kernel.

> What you /really/ want is a "Secure Layer" between the software you don't trust (i.e. pretty much all software), and the software you have no choice but to trust (i.e. the base OS, which is on your side, but is too large and has to do too much low-level, fiddly work to be securable). Secure Boot doesn't give you that layer. The claimed security benefits are illusory.

I think that's called a hypervisor 8-) Virtualizing x86 and using the extra layer of memory protection built into modern CPU/IOMMUs has a much lower vulnerability surface area than the userspace/kernelspace and has shown to be strong in practice given the low number of VM exploits compared to the number of kernel exploits. The fact that Secure Boot isn't a hypervisor doesn't detract or affect what it does try to do.

Garrett: Secure Boot and Restricted Boot

Posted Apr 9, 2013 18:55 UTC (Tue) by dlang (guest, #313) [Link] (10 responses)

> It can fail to install the update but not hide that fact, it can't modify the boot procedure so you'd still be visibly booting the old kernel.

Sure it could

the label that is shown to the user has no connection with the binary blob that gets loaded, it's only convention that keeps them matching.

Once the system boots the old kernel and loads the exploit, it can then lie about what version it is.

Garrett: Secure Boot and Restricted Boot

Posted Apr 9, 2013 19:08 UTC (Tue) by raven667 (subscriber, #5198) [Link] (9 responses)

I was thinking more about the message which are printed as the kernel boots up, the first of which is the version information.

Garrett: Secure Boot and Restricted Boot

Posted Apr 9, 2013 20:00 UTC (Tue) by paulj (subscriber, #341) [Link] (8 responses)

The messages which modern distros have hidden away behind user friendly splash screens?

Garrett: Secure Boot and Restricted Boot

Posted Apr 9, 2013 20:03 UTC (Tue) by paulj (subscriber, #341) [Link] (4 responses)

Oh, and under the control of the subverted software :)

Garrett: Secure Boot and Restricted Boot

Posted Apr 9, 2013 20:34 UTC (Tue) by raven667 (subscriber, #5198) [Link] (3 responses)

Yes, the messages are generally hidden behind splash screens but are still accessible (the display office is in a filing cabinet in a disused lavatory in the basement with a sign on the door "Beware of Leopard" 8-) Aside from the possibility of an exploit of the firmware or kernel from stored config or filesystem metadata the kernel can't be subverted at the time those messages are printed. A syslog which sends the logs remotely or which signs them so the can't be removed/modified on disk, like rsyslog or the systemd journal, could also prevent the malware from being hidden even if it tries to retroactively edit the dmesg buffer after the malware starts, presuming that the system software is started before the malware is allowed to.

The world is not a perfect place but it seems you still have more and better options with boot time validation than without any. Heck, the threat of failing a validation check should keep most malware away of the difficult to exploit protected parts and focused on the easier unprotected parts later in the boot process where it is simpler to deal with.

Garrett: Secure Boot and Restricted Boot

Posted Apr 9, 2013 20:52 UTC (Tue) by paulj (subscriber, #341) [Link] (2 responses)

You're assuming syslog gets to run before the system is re-subverted, alternatively, you're assuming syslog isn't subvertable through anything it reads. I'll grant those assumptions, while not rock-solid, aren't terribly far-fetched.

You still have a *massive* assumption: that the new kernel isn't subvertable.

While, perhaps, the subversion that compromised your box on the previous boot may be fixed, that doesn't mean there aren't still a number of other extant holes still unpatched, that only the exploit writers know about.

You're assuming the exploit has only laid 1 trap to ensnare the next boot.

Back to syslog: How many remotely syslog? Of those, how many would notice a discrepancy between the remotely logged version numbers and the local uname -a? Hell, how many would notice if the exploit didn't bother faking the version? :)

Garrett: Secure Boot and Restricted Boot

Posted Apr 9, 2013 21:15 UTC (Tue) by raven667 (subscriber, #5198) [Link] (1 responses)

> You still have a *massive* assumption: that the new kernel isn't subvertable.

I don't think that is assumed, I'd have had to make the claim that any and all kernel images are perfect and totally secure for you to make that claim, I didn't and that's not a reasonable claim.

> Of those, how many would notice a discrepancy between the remotely logged version numbers and the local uname -a? Hell, how many would notice if the exploit didn't bother faking the version? :)

Damn few, but once exploits in the wild start using that technique it becomes burned, some people will start putting automated checks in their logging systems and the technique will stop working. You see that happen with exploits, once they start circulating in the wild the vendor patches the vulnerability and it becomes less and less effective so that the cycle starts anew.

Garrett: Secure Boot and Restricted Boot

Posted Apr 10, 2013 6:29 UTC (Wed) by paulj (subscriber, #341) [Link]

Still though, you're putting your faith in a security technology whose effectiveness depends on an arms race where the "bad" guys are routinely way ahead. We simply do not know how to make software secure, and so there's no way we can make a large base OS secure. You're *will* regularly lose, if/when you're attacked.

To have any hope of winning the arms race, your faith must go into software that both a) is minimal in size b) is minimal in the services it presents to software that uses it c) and limits the scope of software using it. Userspace sand-boxing and VMs basically. The Android user-space is the state-of-the-art in the real-world, widely-deployed system space when it comes to security and isolation of code, I think. And note that that security model does NOT rely on "Secure Boot".

That's not OS hypervisors, note, because if you're simply running the same OS in the hypervisor you still have the same problem in your virtualised OS. You have a more secure OS underneath to do integrity checks from, I'd agree, but it does not give you any means to have any additional trust in the software you're using at runtime. You still are just as prone to runtime subversion because you still have no isolation/sandboxing between the code & data you don't trust and the rest of the software. Also, things like the Qemu hardware emulation (which seem to be used a lot elsewhere) can have relatively complex interfaces, and they weren't necessarily written in a "security first" way. There have been a number of exploits in this code over the years.

Garrett: Secure Boot and Restricted Boot

Posted Apr 9, 2013 20:22 UTC (Tue) by apoelstra (subscriber, #75205) [Link] (2 responses)

The messages which modern distros have hidden away behind user friendly splash screens?
Right now, without secure boot, it wouldn't help anything to display version information on boot because running 'uname -a' on the booted system would have the same effect. In a secure boot world if you've got a way to display a version and cryptographically prove that it is not a lie, it would be used.

Probably there would be a magic key (escape or F1 or something) to make the pretty boot screen go away. In fact, I think this is the case now.

Garrett: Secure Boot and Restricted Boot

Posted Apr 9, 2013 20:40 UTC (Tue) by paulj (subscriber, #341) [Link]

The uname -a version info the user might query would, by then, be with the kernel subverted again during (early?) boot.

Kernel info pre-boot, or kernel init might be harder to change with Secure Boot, but that doesn't get shown anymore by default. Fedora doesn't even mention version info in the default bootloader UI anymore.

Garrett: Secure Boot and Restricted Boot

Posted Apr 9, 2013 21:25 UTC (Tue) by mathstuf (subscriber, #69389) [Link]

> Probably there would be a magic key (escape or F1 or something) to make the pretty boot screen go away. In fact, I think this is the case now.

Escape will toggle Plymouth. Since it's on a TTY, pretty much any arrow or function key will generate '^[', so they all work :P .

Garrett: Secure Boot and Restricted Boot

Posted Apr 10, 2013 10:16 UTC (Wed) by paulj (subscriber, #341) [Link] (1 responses)

Oh, and yes, it has been a good debate. Thanks :). Hope some of my more terse posts didn't come over as too abrasive!

Re the risks and our outlook. I do understand that some phones aren't locked down, and this is a selling point in some segments. I can understand why you see this as progressive and hopeful. However, I think that's a short-term view of things.

Look at the long-term of computing. Over my lifetime, computers have become ever more closed and user-hostile. When I was very young, all computers had full programming information publically available, from peripheral hardware, to the CPU, to the software environment. Often these were supplied with the computer by default. Some computers even came with full schematics for the board and/or CPU, even the entire system. As time progressed, the programming information available became more limited. Vendors tried to restrict the information even more. Most systems today, even ostensibly "open" ones, tend to have many components that are not documented. Sometimes even CPU software programming interfaces are kept hidden. Further, vendors have even tried to control what software can be run at all, using a variety of schemes.

The phones you speak of that are not locked are still, from my perspective, extraordinarily closed systems. They often contain non-publically-documented CPUs and DSPs. We're in the position where a computer that is touted as being the BBC micro for this era, the "open" hackable computer for today's youth, the raspberry Pi, runs the "open" software only under the control of another, undocumented CPU that requires a proprietary blob to boot it.

From my perspective, "Secure Boot" - which we're agreed is "Restricted Boot" minus 1 bit of information (or policy as someone else put it), with that bit under control of the vendor - is another step down this path of ever more locked-down and inaccessible computing.

Your perspective clearly is more optimistic than mine though. ;)

Garrett: Secure Boot and Restricted Boot

Posted Apr 10, 2013 12:03 UTC (Wed) by paulj (subscriber, #341) [Link]

And yeah, I'm bunching together a number of issues here under "inaccessible" computing. :)

Garrett: Secure Boot and Restricted Boot

Posted Apr 9, 2013 19:56 UTC (Tue) by mathstuf (subscriber, #69389) [Link] (5 responses)

> At that point, you no longer have a general purpose system.

Some places might want to supply devices to others and ensure that it is indeed *not* a general purpose system for a legitimate reason. The user is not necessarily the owner in all cases (e.g., schools lending students laptops, employers, etc.). I can imagine schools wanting to make sure that no student can overwrite required software on the machine (possible excuses) and for IT support savings. This is "Restricted Boot" as far as the physical user of the machine is concerned, but "Secure Boot" from the actual owner's point of view. As far as vendors doing "Restricted Boot", yes, that's not good. However, *owners* being able to enforce "Restricted Boot" is not necessarily a bad thing.

Garrett: Secure Boot and Restricted Boot

Posted Apr 10, 2013 6:43 UTC (Wed) by paulj (subscriber, #341) [Link] (4 responses)

That's one legitimate use-case, agreed. With that in mind is why I wrote "user-owner" in some previous comments. :)

Personally, I'm happy to forego this use-case. I don't think the non-owner-user should necessarily be limited from using the device either. Further, generally it'd be better to keep restrict sensitive software to stay on owner-controlled servers as much as possible, rather than rely on "Restricted Boot", from a security perspective. When the device is returned, the owner can wipe and re-install.

Garrett: Secure Boot and Restricted Boot

Posted Apr 10, 2013 14:08 UTC (Wed) by mathstuf (subscriber, #69389) [Link] (3 responses)

> When the device is returned, the owner can wipe and re-install.

How do you know that you didn't just install to some malicious hypervisor? That's what Secure Boot helps with. With a blue pill virus, you have to wipe BIOS to be sure you are running what you installed. And if the user had full access, that's certainly a possibility.

Garrett: Secure Boot and Restricted Boot

Posted Apr 10, 2013 20:30 UTC (Wed) by paulj (subscriber, #341) [Link]

Yes, "Secure Boot" would make "blue pill" harder, and provide a window during which to be able to detect OS subversion. However, you don't need "Secure Boot" to wipe & re-install - firmware usually provides a way to do this independent of any existing media.

If you say the firmware could be exploited then "Secure Boot" might not help either, if there is any unsigned, modifiable data that is parsed by the firmware. The firmware then may be as open to re-exploitation as the base OS.

Garrett: Secure Boot and Restricted Boot

Posted Apr 10, 2013 20:33 UTC (Wed) by paulj (subscriber, #341) [Link]

Oh, the Linux foundation shim loader should make blue pill attacks viable, even with "Secure Boot". So we'll see how long it stays signed and useable...

Garrett: Secure Boot and Restricted Boot

Posted Apr 10, 2013 21:36 UTC (Wed) by PaXTeam (guest, #24616) [Link]

> How do you know that you didn't just install to some malicious hypervisor?

hypervisors are trivial to detect, no need for SB.

Garrett: Secure Boot and Restricted Boot

Posted Apr 9, 2013 5:26 UTC (Tue) by paulj (subscriber, #341) [Link] (2 responses)

Oh, on sand-boxing. Fully agreed with such technologies. These seem to be the best way we have to secure our software - by limiting and controlling the environment it is run on.

However, clearly, this does NOT require that the main OS environment be the one that is restricted, limited, sand-boxed, etc.. through things like Secure Boot.

Garrett: Secure Boot and Restricted Boot

Posted Apr 9, 2013 15:24 UTC (Tue) by raven667 (subscriber, #5198) [Link] (1 responses)

I'm not sure I'd use the words restriction, limitation or sand-box, as it can't prevent you from using the machine in any way you want, it just defines a signature checking and validation like Tripwire but with a way to update the database securely and a policy to not load files that haven't come through the owner's defined process.

Garrett: Secure Boot and Restricted Boot

Posted Apr 9, 2013 15:51 UTC (Tue) by paulj (subscriber, #341) [Link]

The Secure Boot code, and the signing infrastructure brought in for Secure Boot can become Restricted Boot, if some platform flips the equivalent of a bit of information (see, e.g., the MS Surface ARM "Secure Boot", or future platforms), do you agree on that?

If that abstract bit is flipped, it will be the "Secure Boot" code that stops you booting your own software, and restricts you to approved software. (Unless you have the expertise handy to the exploit the software - I don't).

And still I havn't seen any convincing explaination for how this code helps protect me against those who /do/ exploit software regularly, for fun & profit.

Garrett: Secure Boot and Restricted Boot

Posted Mar 28, 2013 16:27 UTC (Thu) by mjg59 (subscriber, #23239) [Link] (2 responses)

No, obviously I can't guarantee it. And that's why we have to make it clear that Restricted Boot is unacceptable *now*, not when it's found its way into the entire market.

Garrett: Secure Boot and Restricted Boot

Posted Apr 7, 2013 13:49 UTC (Sun) by paulj (subscriber, #341) [Link] (1 responses)

And that opposition is best made clear by implementing a specification which differs from "Restricted Boot" by 1 bit of information?

Garrett: Secure Boot and Restricted Boot

Posted Apr 7, 2013 15:53 UTC (Sun) by raven667 (subscriber, #5198) [Link]

If by one bit of information you mean the entire policy under which it operates...

Garrett: Secure Boot and Restricted Boot

Posted Mar 27, 2013 18:22 UTC (Wed) by njwhite (guest, #51848) [Link]

> The fundamental concept is actually very simple:
> If you are able to install and manage your own keys then secure boot is beneficial. If you are not then it's destructive.

I quite agree. It really isn't difficult to explain the difference to people. I think the FSF's choice to call the former "secure boot" and the latter "restricted boot" is sensible and reasonably clear, and Garrett's choice to follow that made sense. The full blog post did make this terminology clear; you shouldn't rely on quotes to include all necessary context.

Garrett: Secure Boot and Restricted Boot

Posted Mar 27, 2013 22:17 UTC (Wed) by geofft (subscriber, #59789) [Link] (12 responses)

You can blame the FSF for "Restricted Boot" as a term. It's not a term Microsoft or the UEFI Forum uses, and they use "Secure Boot" to cover both versions of this.

But, if you want to explain it to your grandmother, imagine that the auto industry had widespread problems with gas stations selling watered-down gasoline. You're driving along the highway, you refuel at the closest gas station, and two miles down our engine starts sputtering.

Ford says, "We've got a solution: we're making our cars with special patented gas tanks, that only fit our special patented gas nozzles. You can only fill up from Ford-run gas stations, and unapproved gas stations can't make nozzles that fit your car any more." While this does solve the problem as stated, it's also pretty anticompetitive. This is Restricted Boot -- you buy a computer, and you can only install operating systems that the computer vendor approves.

Customers complain, and Ford says "Okay, fine, you don't want us in control of where you get gas. Fine. We'll let you swap out the special gas tank cap. If you decide you like Chevron gas, go buy a Chevron-patented gas tank cap from them -- but we take no responsibility for whether Chevron is doing a good job of franchising their gas stations to trustworthy people. If you want to live dangerously, we'll even let you unscrew the connector and let _any_ nozzle fill fuel, but if your engine burns out, don't complain to us." That's Secure Boot. By default, the computer vendor restricts boot to OSes that they've vetted, but you as the computer owner can choose to change who's trusted to write OSes, or even trust anyone at all.

Chrome OS's solution (which Matthew has blogged about before) is like this story, except that there's no option for third-party fuel vendors to provide replacement special caps. You either have to trust Google, or trust everyone. It's a lot better than Restricted Boot, where you can't remove the special cap at all, but it's not quite as good as Secure Boot, since you have no protection if you opt out of trusting Google.

The distinction is that boot verification uses cryptography instead of patents, so it actually works. :)

Garrett: Secure Boot and Restricted Boot

Posted Mar 28, 2013 16:58 UTC (Thu) by hummassa (guest, #307) [Link] (3 responses)

> but if your engine burns out, don't complain to us.

More like: if anything happens, we will shift the fault to you unscrewing the nozzle, we will overcharge you for any kind of service in your car and, in some cases, we will even deny you any kind of service. Ah, some parking lots, part shops, or even some roads may deny you service also.

Garrett: Secure Boot and Restricted Boot

Posted Mar 29, 2013 2:52 UTC (Fri) by geofft (subscriber, #59789) [Link] (2 responses)

I think the car analogy is breaking down here, but as far as Secure Boot goes, that is simply impossible. There is no way for an OS to reliably know whether it was booted in Secure Boot mode or what keys were available -- you can very easily write a bootloader shim that intercepts the EFI APIs for accessing variables, loads an actual bootloader (like Windows'), and falsely reports that Secure Boot was enabled and only the MS key was trusted.

Remember that Secure Boot is for the hardware deciding whether to trust (and go ahead and execute) the OS, not vice versa. If you want the reverse, you want a TPM, which lets an OS decide whether to trust the hardware (and again, not vice versa).

Garrett: Secure Boot and Restricted Boot

Posted Mar 29, 2013 15:40 UTC (Fri) by ortalo (guest, #4654) [Link] (1 responses)

Also for the TPM: not vice versa? With a TPM you mean the hardware does not have a mean to decide if it can trust the OS?

Garrett: Secure Boot and Restricted Boot

Posted Mar 29, 2013 18:53 UTC (Fri) by geofft (subscriber, #59789) [Link]

Correct. The TPM is a little chip on the motherboard that can do cryptography. The usual way it's used is that it's configured to read in and hash every piece of code run in the boot process (starting with the TPM itself reading the BIOS code, then the BIOS passing option ROMs and the boot sector, then the boot sector passing on anything it loads). At this point the TPM has a "measurement" of the boot process; a salted hash of all code that runs with some secret burned into the TPM itself.

The TPM has the ability to "seal" or "unseal" an encryption key (just another level of encryption) based on the measurements. So you can use it for full-disk encryption, by sealing your encryption key against the measurement of the boot proess. If the boot process changes (e.g. there's a boot sector virus), or you move the disk to a machine with a different TPM, you can no longer unseal the key to the disk, because you don't have matching measuments any more. You can also use it for remote attestation, by having a network server send the OS a challenge that it gets the TPM to respond to, where the response can only be constructed if the measurements match.

One thing you'll note that the TPM does not have the ability to do is to _stop_ code from executing. It sits there quietly watching what code is executed. It can refuse to provide the encryption key, but it can't, for instance, prevent a malicious boot loader from playing a fake Windows boot animation, popping up a login screen, sending the password somewhere, removing itself, and bluescreening. User data is protected, but even so, it's a lot easier to mount attacks since the attacker has code running on your machine.

The other thing about Secure Boot is that it's possible to implement it just within the existing boot firmware, without requiring a separate processor for doing crypto. Yes, you could imagine the TPM having signature verification capabilities, but it's better to put it on the firmware that already ships with every machine, instead of requiring additional hardware on all machines.

Garrett: Secure Boot and Restricted Boot

Posted Mar 28, 2013 17:03 UTC (Thu) by hummassa (guest, #307) [Link] (7 responses)

> The distinction is that boot verification uses cryptography instead of patents, so it actually works. :)

OH MAN. NO. Please. NO.

Cryptography only works in transit. If you are in control of one of the endpoints of a communication, Cryptography is NOTHING.

A |--- E ---> B

Crypto only works so that E does not know the content of the message.

All DRM thingies (including "Secure" Boot) are like:

A |------> E/B

Tens of millions of jailbroken iPhones scream that DRM does not work and that "Secure" Boot does not work.

Garrett: Secure Boot and Restricted Boot

Posted Mar 28, 2013 18:01 UTC (Thu) by apoelstra (subscriber, #75205) [Link] (1 responses)

> Cryptography only works in transit. If you are in control of one of the endpoints of a communication, Cryptography is NOTHING.

In principle this is true, but if the endpoint you "control" requires an engineering degree and expensive equipment to analyze, you're effectively not in control. You cited the proliferation of jailbroken phones, but jailbreaking procedures usually find other bugs with which to bypass the encryption --- they can't do anything against the encryption itself.

Garrett: Secure Boot and Restricted Boot

Posted Apr 3, 2013 13:19 UTC (Wed) by xilun (guest, #50638) [Link]

This is even worse than that: you are not in effectively not in control because of the cost, but given the right incentive an opponent can take control in a way that locks you down completely out of control.

Garrett: Secure Boot and Restricted Boot

Posted Mar 28, 2013 19:11 UTC (Thu) by mjg59 (subscriber, #23239) [Link] (3 responses)

Most DRM technologies are theoretically breakable because they require the system to contain a secret but not to let you access that secret. Secure Boot contains no secrets at the client end. The failures of most Restricted Boot systems have been caused by flaws outside the cryptography, not the cryptographic checking itself.

The lack of a jailbreak for the AppleTV3 (and the resulting $130 premium that AppleTV2s command on ebay) is evidence that this can be done sufficiently well. Even the iOS 6 jailbreaks are forced to operate at higher levels than the boot verification - you can run arbitrary userspace code, but you couldn't replace the kernel.

Garrett: Secure Boot and Restricted Boot

Posted Mar 30, 2013 1:45 UTC (Sat) by hummassa (guest, #307) [Link] (2 responses)

I'll let you in a little secret, Garrett: atv3 was not jailbroken because there are better, more open, options in the market, and because it is a very small market. If the iPhone sold in its segments as little as the ATv, people would just buy Android too.

When geohot first jailbroke the iPhone, he had to physically open the case. One of my atv1 had to be cracked open, too. But, having other options to run Xbmc+Netflix/Hulu, why in the world would one buy an Apple TV? Unless, of course, you want to pay two dollars per tv episode -- but I can't put the subtitles I want on it...

Garrett: Secure Boot and Restricted Boot

Posted Mar 30, 2013 1:56 UTC (Sat) by mjg59 (subscriber, #23239) [Link] (1 responses)

"atv3 was not jailbroken because there are better, more open, options in the market"

That would be a perfectly reasonable explanation, other than the number of people willing to pay significantly more money for an atv2 than a new atv3 costs.

Garrett: Secure Boot and Restricted Boot

Posted Mar 30, 2013 11:42 UTC (Sat) by hummassa (guest, #307) [Link]

This is the minority like me: I *did* pass on the other options b/c I do have a reasonably-sized collection of thingies on iTMS... :-(

And I do think iTunesU is nice. Apple is *so* evil that they could hook me, even if I know it.

Garrett: Secure Boot and Restricted Boot

Posted Mar 29, 2013 3:33 UTC (Fri) by geofft (subscriber, #59789) [Link]

> Cryptography only works in transit. If you are in control of one of the endpoints of a communication, Cryptography is NOTHING.

This is a valid argument against restricted boot, but not so much against secure boot. The intention of restricted boot is to make sure that only the OS vendor controls the OS being run, and prevent the computer owner from choosing an OS. You're right that with physical control the user can probably win (although I can still imagine designs that involve writing everything in Coq and then epoxying the motherboard, or something).

But secure boot is intended to place the computer owner and the hardware vendor in control of the device, and keep malware away. The attacks people are worried about are boot sector _viruses_ (which have been around since the late '80s, btw; it's only with UEFI that we can do something meaningful about it). This involves a third party with access to your boot medium -- anything from a trojanned download of an Ubuntu CD, to a curious-looking thumbdrive lying around a conference. Here the attacker does not have control of the endpoint, until such time as they get code executing. Secure boot is intended to make sure the attacker's code never executes. So the cryptosystem is sound.

Simple explanation for non-techs.

Posted Mar 28, 2013 8:50 UTC (Thu) by Comet (guest, #11646) [Link]

"""
The device you paid a lot of money for? If it's yours, you own it, right? So, you get to decide what happens with it, and can take it to be serviced by anyone you want, and if you disagree with the default maintenance plan, you can switch?

Strange, that's not what the people who took your money think. They've set it up so only they get to decide what, fundamentally, the device is allowed to do, whose programs it will agree are acceptable to run. They've gotten laws passed so that if you disagree and try to take control of something you bought, because you think that as the owner you should control it, then you can face criminal charges for removing their locks around the core of your device.

If you want to really have control, if you really want to own it, you have very few options right now. Guess what? That big company, Google, that people are screaming about right now? Their phones and tablets, the ones with their brand (not just "Android") are about the only ones that don't put those chains and locks around the core of your device. It's ironic, I know. Just ... don't leave their software on it unless you're happy being part of Google's fiefdom. You might be, I am; but I'm an edgy serf, looking around and trying to figure out if it's worth leaving the comforts and security and heading out into the woods, for freedom. But hey, at least here, I'm not wearing manacles and I *can* leave.
"""

Garrett: Secure Boot and Restricted Boot

Posted Mar 27, 2013 16:49 UTC (Wed) by tshow (subscriber, #6411) [Link] (1 responses)

Whereas we have the same goals, I think we differ on strategy. My take on this is that once "Secure Boot" is entrenched, it's very easy for it to become the default. The OEMs just say "look, kid, you want to build your own kernel or boot loader, go talk to a signing authority" -- as far as they're concerned, there's a "go away, not our problem" answer they can give you. And if in practice it means only large distributions can get their kernels signed, well, does it mean ASUS or MSI or Gigabyte is selling fewer motherboards? If not, they'll have a very nice forum thread for you to preach to the choir on for as long as you like.

Without straying too far into Godwin's Law territory, I think "Secure Boot" is one of those things we have to treat as an abomination. Just because some of us can find a workable solution doesn't mean the whole thing shouldn't be burned to the ground. Half measures and workarounds just make it easier for the OEMs to make the business case to make "Always On Secure Boot" a feature list item on the box.

Garrett: Secure Boot and Restricted Boot

Posted Mar 28, 2013 17:04 UTC (Thu) by ortalo (guest, #4654) [Link]

On the other hand, there is some truth in what Matthew points out. The complaint raised in Spain seem to have targeted specifically Microsoft on SecureBoot on x86 (correct me if I am wrong) while I am not sure any complaint has been raised against Google or Apple on their own locking of their device. If they have not been raisen, the latter should have been give priority, that's my feeling too.

Garrett: Secure Boot and Restricted Boot

Posted Mar 27, 2013 22:24 UTC (Wed) by pr1268 (guest, #24648) [Link]

I, for one, wish to commend Matthew for his insightful and enlightening blog post. Since I'm the one who suggested the Linux users file EU complaint article to LWN, I assume some responsibility for how many misunderstand Secure Boot (myself included) and seem to be viciously attacking Microsoft. (A generalization on my part, based on the comments above, on Matthew's blog and also on the LWN summary for the EU Linux users article.)

Microsoft may have been the one company to impose this spec, and the HW manufacturers are (obviously) going to kowtow to MS's demands, but MS isn't the appropriate organization to which aggrieved users should be pointing their fingers (as Matthew has pointed out on several occasions).

Microsoft has had its good name sullied for years for software issues (shoddy device drivers, out-of-spec hardware, malware, etc.). I've noticed more often than not that MS gets the blame when 3rd-party software crashes (because the developers hideously abused the "system"). I can't blame MS for imposing Secure Boot (although I question their draconian restrictions on ARM); seems like MS is merely trying to eliminate one more attack vector for malware.

Thank you, Matthew, for your tireless efforts in getting a workable solution for Linux users with UEFI Secure Boot hardware, and also for your work in educating and enlightening the FLOSS community on what Secure Boot and Restricted Boot are (and aren't).

Garrett: Secure Boot and Restricted Boot

Posted Mar 28, 2013 16:52 UTC (Thu) by ortalo (guest, #4654) [Link] (3 responses)

The situation does not seem so complex to me.

Personally I'd sum up as:
- UEFI as SecureBoot: neutral. You can buy. (If it's mine or you ask me I'll deactivate it. If you want to activate, either ask M$ or -preferably- that Matthew from Nebula on the web).
- whatever as RestrictedBoot: negative. Do not buy. (Or, that's your money.)

It seems to me this is in support of Matthew's position, though probably not as much as he would like.

But hey, I would also like him to work on fancier things like relying on a smartcard to check kernel or program signatures efficiently and things like that (and possibly on phones or portable devices). Nobody's willing to fund him for that? (After all, he seems especially competent and interested in that field.) The end result might be interesting enough to compete with proprietary restricted boot solutions based on its own technical and security merits (like most of free software). General market adoption is another issue (remember once upon time, Apple and M$ also tried to replace TCP/IP, but then they stopped). I also know of a few very specific niches where it may make a lot of sense any time (but niche markets are niches of course).

Funnily, all the (interesting) debate around UEFI has not made me change my position so much: support the man and forget about the thing... Admittedly, if he asks me to actively support the technology, this will make up for a short schizophrenic stasis. But I'll see.

Garrett: Secure Boot and Restricted Boot

Posted Mar 29, 2013 2:41 UTC (Fri) by geofft (subscriber, #59789) [Link] (2 responses)

Just to make sure we're using the words right, "UEFI" is the name of the binary architecture and APIs for booting a computer in a way that doesn't involve it pretending to be an original IBM PC first. UEFI is (on paper) a Good Thing, because it means that the lives of bootloader and kernel authors suck less, and they get a reasonable API to the system and can write reasonable code in a reasonable development environment. (In practice, we're better at dealing with 16-bit BIOS implementations because of the quarter-century of experience than at 64-bit UEFI implementations that were just released, but that should change soon.)

Secure Boot is a cryptographic-validation feature that you can implement on top of UEFI, because it doesn't suck the way that BIOS sucks -- namely, since the firmware loads an entire 64-bit executable in a reasonable format instead of a 400-byte COM file, it's actually reasonable to expect the thing you loaded to do second-stage cryptographic validation. There are plenty of EFI / UEFI implementations that just don't involve Secure Boot at all, including every Mac made in the last several years.

"Secure Boot" and "Restricted Boot" as Matthew uses them in this article are policy requirements on top of the Secure Boot feature in the UEFI platform. (Incidentally, the arguments he makes apply equally well to cryptographic boot validation approaches on other platforms that don't really involve UEFI and thus technically aren't Secure Boot, including Android, iOS, and Chrome OS devices as well as game consoles, TiVos, etc. etc. etc.)

Garrett: Secure Boot and Restricted Boot

Posted Mar 29, 2013 3:32 UTC (Fri) by raven667 (subscriber, #5198) [Link]

That is a great way to put it, you win at internets.

Garrett: Secure Boot and Restricted Boot

Posted Mar 29, 2013 15:38 UTC (Fri) by ortalo (guest, #4654) [Link]

Thanks for the clarifications too. (Indeed, my own usage of the UEFI acronym was probably inexact; btw, I had equally in mind something more generic than one boot implementation as well as something more specific with respect to security.)


Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds