Garrett: Don't like Secure Boot? Don't buy a Chromebook

But the basic points remains - Very few people are interested in secure booting of Linux. Even when for many it would already be possible to do so.

Encrypt your hard drive, and then have an initramfs that requests a decryption key from the TPM and mounts the drive. Record the trust chain and tell the TPM to only yield the key if there is a match.

Sure, the system will boot anything, but nothing on the hard drive can be read unless the proper boot chain is used, and the initramfs can of course do all the verification it wants to, as can the rest of the OS.

Disclaimer - I've never actually tried any of this, but from what I understand this should be possible with Trusted GRUB and a TPM-aware kernel.

Or you can just buy hardware from a vendor that isn't a asshat. There are lots of ways to make sure your hardware is linux unfriendly. Taking advantage of secure boot is just one of them.

Being put in a situation where you are forced to depend on the competence of Microsoft (or even Google) is just absurd. It's especially so when you are also forbidden from fending for yourself.

YOU are probably far more dependable in this area than Microsoft.

This is an error.

Even with the ability to have a way of checking the checksums of your kernel and modules, there are ways to subvert the kernel and force the loading of a (signed or unsigned) kernel-module-root-kit.

So, even WITH "the ability to have a secure way to check the checksums your kernel and its kernel modules at boot up", it's still "impossible to know if your system has been subverted by a LKM root kit".

Helping some software and hardware manufacturers to maintain dominance is the only thing secure boot tech is effective at.

> You CANNOT depend on userland code, no matter how clever (aka rootkit detector or virus scanner) to verify the security of your system.

That's the problem. Both Windows' kernels and Other OS's kernels depend heavily on userland code and data, and can be manipulated by userland code and data via exploits to load and execute kernelland code. Rootkits abound on all platforms and secure boot initiative never resist attacks long. Non-Windows examples are jailbreaking Apple products, rooting originally-non-rootable Androids, unlocking Sony PS3s, PSPs, among other products.

Honorable mention for resilience so far to AppleTVs model 3, which some people claim are jailbreakable, but the method to do so has not been disclosed publicly yet.

> There are two ways I know of to effectively be able to check your system; One is to boot your system from external media or remove the drive. create a list of checksums of a known good state, and then periodically take your system off line to compare.

How exactly do you know your "checksums of known good state" are really from a good state? once you start checksumming, the system can already be compromised. Other thing: even if you get to "ok, at this point you have to be at what I'll call a known good state", unless you checksum the whole contents of RAM, you don't have any way to know if you do not have an invisible kernel module lurking around somewhere in RAM. Even if your boot media is read-only, it can contain vulnerabilities that make it rootable soon-after-boot (like happens in thethered jailbreaks for Apple products).

> The other way is to have a secure boot mechanism.

Which, for all reasons above, is not an effective way to check it either.

> Now I understand this form of 'secure boot' isn't perfect, but it's a good start.

That is the point: it's not a good start, not only because it isn't worth a damn, but because the thing it *is* good at is "preventing non-technical people from installing another OS in the device or customizing from a certain, manufactured-decided, point on".

Example: Apple. Unless you jailbreak your device (which is fairly simple today, but once upon a time was an ordeal that could need the owner to open up her hardware) you can't change iPhone keyboard layouts or interactions, nor install AppleTV third-party programs, much less install Linux on your AppleTV (which works very well, thank you very much).

The funny part of this example is that jailbreaks normally work by exploiting some unsecured bug on the device's original firmware that could be exploited by malicious third parties. IOW: the security of "secure boot" leaves the devices MORE vulnerable to exploits.

One more thing: rootkits worth their salt know if the system is trying to checksum some blocks on disk, and return the original blocks for the checksummer program to check, even if the system used other, different blocks to load.

VMware are going to be in for a bit of a shock.

Secure Boot here is doing defence in depth. It forces the bad guys to either subvert Secure Boot, or give up on totally hiding from the administrator and risk getting caught. How well it works in practice we likely won't know for a few years yet.

UEFI Secure Boot is an open standard that can be implemented without any license fees and which comes with a liberal set of patent grants. There's a fully functional sample implementation available under a free license. Google's verified boot, on the other hand, isn't standardised and Google don't (as far as I know) provide a patent grant. At a technical and legal level, there's little reason to prefer Google's implementation.

Of course, the reality is that Microsoft have control of their market in the same way that Google have control of their market. At present, anyone who wants to run an alternative operating system on these systems does so at the sufferance of a large multinational corporation. Many people feel that Google is more trustworthy than Microsoft, and I can certainly understand why - but in both cases, you're trusting a publicly traded company with a track record of evil activities to behave appropriately.

In this specific instance, Microsoft have insisted that end users be able to install their own keys and are willing to sign alternative operating systems - Google haven't and aren't. Microsoft could change their mind at any time, but that would lead to complicated contractual disputes that would be likely to attract regulatory bodies. Do I trust Microsoft? No. Do I think it's practical for Microsoft to screw the third-party OS market on x86 hardware at this point? No.

We shouldn't prefer Google merely because they're not Microsoft. We should prefer them because they do better, and in this case they're currently not doing better. I hope that changes.

"Software tools for that are already available and Microsoft requires Windows RT devices to have a jumper that allows replacing keys?"

Existing UEFI implementations all just keep the keys in unsigned form in flash. Acquiring an SPI programmer is left as an exercise for the reader.