6 ms·
How Windows 10 Rewrites OS Architecture: Battle of SKM and IUM [pdf]
- narrator 11y agoMaybe 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.
- pixelcort 11y agoWe already have consoles, smart devices, etc that can sometimes get bricked, so we're already halfway there.
- venomsnake 11y agoIt 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.
- josteink 11y ago> 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.
- pjmlp 11y agoThat is what happens when freedom gets abused.
- venomsnake 11y agoWhich freedom exactly was abused? Edit: also if something can be abused it is not a freedom but a granted temporary privilege.
- pjmlp 11y agoTo run software with full rights of $HOME or similar, acess the network and manipulate PC contents without the user knowing about it.
- Silhouette 11y agoLike 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?
- pjmlp 11y agoNo 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.
- Silhouette 11y agoI 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.
- pjmlp 11y agoThe 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.
- Silhouette 11y agoBut 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...
- mjg59 11y agoThe 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.
- vetinari 11y agoFor 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.
- mjg59 11y agoChromebooks 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
- gsnedders 11y agoNot all Chromebooks require physical modification for re-keying. (The Dell Chromebook 11 doesn't, for example.)
- keyboardwarrior 11y agoLets not fool ourselves into thinking this is about security. We are talking about microsoft here. its not like they would ever break anti-trust...
- TazeTSchnitzel 11y agoThis is possible today with firmware rootkits.
- kevin_b_er 11y agoIt 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.
- transpute 11y agoReddit 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_begin_shipping_skylake_cpus_with_sgx/ https://www.reddit.com/r/hardware/comments/3nn33x/intel_to_b...?
- mjg59 11y agoThe 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.
- mjg59 11y agoHuh that sounded far more negative than I meant. The rest of the discussion is excellent, and the functionality described is amazingly important.
- aionescu 11y agoAuthor 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.
- mjg59 11y agoYou 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.
- ossreality 11y agoDon't you need SecureBoot to start the process of the measured boot?