The discussion about enforcing Secure Boot is kind of missing the point - if Secure Boot isn't enabled, earlier code could simply pass a fake pointer to the EFI runtime services table and fake GetVariable(), making it look like Secure Boot is enabled and appropriately configured. There's no real programmatic way to verify that Secure Boot is enabled[1], you pretty much just have to assert that it is.

[1] Well, kind of. The Secure Boot configuration state is measured into PCR 7 on the TPM, so you can seal a secret to it and then have it fail if the Secure Boot configuration changes. But that's made difficult because updates to dbx (but not dbt) invalidate the state, so you need a lot of very careful handshaking in blacklist updates.

Huh that sounded far more negative than I meant. The rest of the discussion is excellent, and the functionality described is amazingly important.

Author here.

The problem I was trying to get to is that VSM allows itself to be activated without SB (which as you note, can also be done with malicious SB) and therefore there is no way to really 'trust' the VSM implementation.

Possible fixes to this would be to rely on SGX/TXT. But even that can be messed with -- but the attack surface is much harder than EDK-II.

You can never really trust a system's assertion about its Secure Boot state, so refusing to run when Secure Boot appears to be disabled would be more of a feel-good approach than anything else. You really need a measured boot process here, and if you have that then Secure Boot's not buying you a great deal in this case.

Don't you need SecureBoot to start the process of the measured boot?

No, Secure Boot only comes into play at the point where the firmware starts executing external code (option ROMs or bootloaders). You need to start measurement way before that.

Maybe I'm being cynical, but I'm expecting a day when all this security backfires and you have to throw out your computer when you get attacked by certain malware that gets inside of these trusted computing areas. The part about not being able to read certain memory areas, even with hardware access, is especially disturbing.

We already have consoles, smart devices, etc that can sometimes get bricked, so we're already halfway there.

This is possible today with firmware rootkits.

It isn't your computer anymore. The device no longer trusts YOU and will not obey you. It obeys its owners: The corporation that made it.

Therefor your point is moot. It isn't your device, so you aren't throwing out anything you own.

It is all about DRM. Make no mistakes. They want to turn PC into Consoles. And the effort is underway.

Unless MS provide way to build and sign your copy of windows yourself. As with any other tech - the important thing is who holds the keys.

The root of trust is in Secure Boot, and you have control of those keys. That means you maintain control of your machine - it's always possible for you to boot modified code that checks your signatures instead of any manufacturer's.

For PCs you do control MOKs, for now.

For mobile devices, or for devices like Chromebooks, you don't. It is only matter of time, until PCs change too, with apologies like 'nobody uses it anyway, why complicate things' etc. The frog must be boiled slowly, otherwise it backfires.

Chromebooks are explicitly designed to permit re-keying, although it does require you to physically disassemble the machine[1]. And if anything, we're seeing more user-unlockable mobile devices now than we did in the past. At the high end, server vendors want to maintain control of their keys, and there are large companies who want to do the same for corporate desktops and laptops. At the current rate, the frog's going to die of old age before it notices anything.

[1] The reasons for this design choice are understandable, even if I disagree with them

Not all Chromebooks require physical modification for re-keying. (The Dell Chromebook 11 doesn't, for example.)

> As with any other tech - the important thing is who holds the keys.

I may not agree with your whole post, bit this is key.

It's about control of your own hardware and it's gradually being taken away. One piece at a time.

That is what happens when freedom gets abused.

Like the freedom to run my own choice of operating system?

Or the freedom to reset my device to a known-good state from read-only media so I know it's safe to use again after potentially being compromised through these slightly-too-clever new reprogrammable systems?

No the freedom that any programm has full rights of $HOME, to access the network, to manipulate everything that the user under it runs also can.

I don't see the connection.

Your point seems to be about the chosen operating software's security model. I agree that flexibility here is woefully lacking in all the major desktop OSes today.

However, the original concern in this case seems to be about being able to choose the basic operating software for the system itself, which is an orthogonal issue to the one you're raising as I understand your comment.

The lack of security for major OSes and the exploits that were caused by the freedom to install software from any source, which lead to the said software being able to do anything in user's name, is what lead to solutions like application stores and things like SGX.

Because the average Joe and Jane users don't understand anything about security, and prefer to loose freedom than having their computer exploited.

But the modern measures about locking down the hardware itself, which are the subject of this discussion, have nothing to do with app sandboxing and app stores...

Which freedom exactly was abused?

Edit: also if something can be abused it is not a freedom but a granted temporary privilege.

To run software with full rights of $HOME or similar, acess the network and manipulate PC contents without the user knowing about it.

Lets not fool ourselves into thinking this is about security. We are talking about microsoft here.

its not like they would ever break anti-trust...

Reddit discussion (68 comments) on Skylake SGX enclaves, which will bring similar concepts to other x86 operating systems, https://www.reddit.com/r/hardware/comments/3nn33x/intel_to_b...?