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

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.