So you already have to be in ring 0. Pretty click baity title.
So you already have to be in ring 0. Pretty click baity title.
That said, I'm not particularly convinced that (unvirtualized) ring 0 to SMM is really a violation of a security policy... it's not like SMM really tries to confine what ring 0 can do, it just wants things like interrupt priority.
Also later ring 0 code can't get rid of code installed into SMM earlier (that may still trigger through events or timers).
it reminds me of the unlimited data plans that are limited after 5Gb.
Not sure what happened to language :)
"universal if you are root/can insmod/etc."
.. only needs to be true once, and from that point on the hardware no longer belongs to the owner.
So, if you could for example get your secretNSA$hit installed on the Linux box that is used to test hardware at the PC assembly/manufacturing plant, before its sent off to be 'securely configured' by the sysadmin/ops as supposedly fresh equipment.
Lots of ways that can happen, of course its theatrical to consider it, but little in security these days is without drama it seems.
Truly, not being able to trust the microcode in my CPU is a worry, but it always has been. There are no guarantees that there aren't already CPU embeds that are configured to ship data to some quantum-bearing government spy satellite, and thus we're all fools for thinking we have any kind of security on this theatrical stage at all ..
http://en.wikipedia.org/wiki/Protection_ring
Multics supported 8+ rings, OpenVMS 3 rings, OS/2 3 rings, Windows NT and Unix only 2 rings. Some hypervisor like XEN use afaik ring 1 (Intel VT-x "Vanderpool").
We need better ring support in modern operating systems and hypervisors (VM hosts).
"The x86-processors have four different modes divided into four different rings. Programs that run in Ring 0 can do anything with the system, and code that runs in Ring 3 should be able to fail at any time without impact to the rest of the computer system. Ring 1 and Ring 2 are rarely used, but could be configured with different levels of access."
https://www.destroyallsoftware.com/talks/the-birth-and-death...
I found little resource about the project, but there is a discussion on Reddit: http://www.reddit.com/r/compsci/comments/25w7vt/javascript_b...
And we had the discussion on HN too: https://news.ycombinator.com/item?id=7605687
Nevertheless an interesting topic, that doesn't deserve a downvote of my parent.
It's more that a ring 0 can manipulate an alternate context, but only for contexts that it can create. So guests can themselves be hypervisors for contexts that they themselves create. There's nothing stopping a guest from executing virtualization instructions[1].
That being said there is a sort of ring -1 called SMM mode.
[0] And this is why you shouldn't rely on wiki. Particularly since it looks like the deletionists are winning their war. It's source is informationweek in this case...
[1] Well, that's not totally true. When setting up the context for a guest you can signal that you as the hypervisor want to get trapped on lots of different types of privileged operations. ie. you can optionally, explicitly disallow the guest to use virtualization extensions. But it's opt in, not policy set by AMD/Intel.
Yes, but the article implies that you can e.g. do bad things in a bootloader and then have the OS run while the exploit stays resident and undetected by the OS.
This definitely has previously undocumented exploit potential if you can force the target to e.g. boot from a malicious USB device.
If you can control the boot media, aren't you already past the point where you need further exploits to control the machine?