Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

DEF Con 32 – AMD Sinkclose Universal Ring-2 Privilege Escalation (Not Redacted) [pdf]

media.defcon.org

Post reply on HN
Print view View original

11–20 of 35 posts

Re: DEF Con 32 – AMD Sinkclose Universal Ring-2 Privilege Escalation (Not Redacted) [pdf]

#11

Post by veltas »

kaoD wrote: post #9
tux3 wrote: post #2

I was confused by the title, by "Ring-2" it means "Ring -2" (minus two), which is "traditionally" SMM (System Management Mode), a horrible relic that lets your BIOS/UEFI silently steal the CPU from the OS to implement janky drivers or workarounds directly in the firmware (occasionally causing all sorts of mayhem). (Actual Ring 2 is very rarely seen, so perhaps I should have known!)

Wait, there are negative rings!? I'd like to learn more about this but it's not a very easy to search term. Any pointers?

It's called System Management Mode, it's in official Intel documentation for x86.

Re: DEF Con 32 – AMD Sinkclose Universal Ring-2 Privilege Escalation (Not Redacted) [pdf]

#12

Post by BearOso »

kaoD wrote: post #9
tux3 wrote: post #2

I was confused by the title, by "Ring-2" it means "Ring -2" (minus two), which is "traditionally" SMM (System Management Mode), a horrible relic that lets your BIOS/UEFI silently steal the CPU from the OS to implement janky drivers or workarounds directly in the firmware (occasionally causing all sorts of mayhem). (Actual Ring 2 is very rarely seen, so perhaps I should have known!)

Wait, there are negative rings!? I'd like to learn more about this but it's not a very easy to search term. Any pointers?

I can't imagine it's a standard thing.

On X86 we have ring 0 and 3, with 1 and 2 never used and removed in newer CPUs. ARM has 3 or 4 privilege layers, but they're named differently.

They probably just called it ring -2 because it's a couple layers below ring 0.

Re: DEF Con 32 – AMD Sinkclose Universal Ring-2 Privilege Escalation (Not Redacted) [pdf]

#13

Post by okanat »

BearOso wrote: post #12
kaoD wrote: post #9

Earlier quoted context omitted.

Wait, there are negative rings!? I'd like to learn more about this but it's not a very easy to search term. Any pointers?

I can't imagine it's a standard thing. On X86 we have ring 0 and 3, with 1 and 2 never used and removed in newer CPUs. ARM has 3 or 4 privilege layers, but they're named differently. They probably just called it ring -2 because it's a couple layers below ring 0.

Ring -1 is the host system / virtual machine manager when the ring 0 OS is running as a VM. Ring -2 is more privileged than that since it can interrupt Ring -1 and can affect the execution of VM instructions.

Re: DEF Con 32 – AMD Sinkclose Universal Ring-2 Privilege Escalation (Not Redacted) [pdf]

#14

Post by hypeatei »

kaoD wrote: post #9
tux3 wrote: post #2

I was confused by the title, by "Ring-2" it means "Ring -2" (minus two), which is "traditionally" SMM (System Management Mode), a horrible relic that lets your BIOS/UEFI silently steal the CPU from the OS to implement janky drivers or workarounds directly in the firmware (occasionally causing all sorts of mayhem). (Actual Ring 2 is very rarely seen, so perhaps I should have known!)

Wait, there are negative rings!? I'd like to learn more about this but it's not a very easy to search term. Any pointers?

Good article on negative rings:

https://medium.com/swlh/negative-rings-in-intel-architecture...

Re: DEF Con 32 – AMD Sinkclose Universal Ring-2 Privilege Escalation (Not Redacted) [pdf]

#15

Post by dooglius »

kaoD wrote: post #9
tux3 wrote: post #2

I was confused by the title, by "Ring-2" it means "Ring -2" (minus two), which is "traditionally" SMM (System Management Mode), a horrible relic that lets your BIOS/UEFI silently steal the CPU from the OS to implement janky drivers or workarounds directly in the firmware (occasionally causing all sorts of mayhem). (Actual Ring 2 is very rarely seen, so perhaps I should have known!)

Wait, there are negative rings!? I'd like to learn more about this but it's not a very easy to search term. Any pointers?

I don't think there actually are, in the sense that there isn't a register somewhere with these values that gets compared against, the way there is with rings 0-3. I've only heard this in the context of reverse engineers describing the layers of access that undocumented parts of a modern CPU system have, I think it's just a made-up analogy. There is presumably some proprietary documentation out there with more official names.

Re: DEF Con 32 – AMD Sinkclose Universal Ring-2 Privilege Escalation (Not Redacted) [pdf]

#16

Post by adrian_b »

BearOso wrote: post #12
kaoD wrote: post #9

Earlier quoted context omitted.

Wait, there are negative rings!? I'd like to learn more about this but it's not a very easy to search term. Any pointers?

I can't imagine it's a standard thing. On X86 we have ring 0 and 3, with 1 and 2 never used and removed in newer CPUs. ARM has 3 or 4 privilege layers, but they're named differently. They probably just called it ring -2 because it's a couple layers below ring 0.

Arm (Aarch64) Exception Level 0 corresponds to Ring 3 of x86.

Arm (Aarch64) Exception Level 1 corresponds to Ring 0 of x86.

Arm (Aarch64) Exception Level 2 corresponds to the Hypervisor level a.k.a. Ring -1 of x86.

Arm (Aarch64) Exception Level 3 corresponds to the System Management Mode a.k.a. Ring -2 of x86.

Fortunately, in Arm EL3 the same instruction set is used as in any other level, unlike in x86, where SMM uses the obsolete 16-bit 8086 ISA, so for compiling programs that will be executed in SMM you have to use a special tool set.

Unfortunately, both the Arm EL3 and the x86 SMM allow the manufacturers of computing devices to do things that are either stupid or in direct contradiction with the interests of the owners of the devices and the owners may not be able to do anything to correct this, unless they can exploit vulnerabilities like the one that has now been patched by AMD.

There are no valid arguments for the existence of SMM and EL3 and the fact that they are not forbidden by law is a disgrace for the computing industry.

Arm EL3 has been created as an imitation of the Intel SMM. The Intel SMM has been created because Microsoft was too lazy to introduce the required power management functions in the Windows and MS-DOS operating systems, so they passed the task to the motherboard or laptop manufacturers, for which Intel has provided SMM, to enable this.

Re: DEF Con 32 – AMD Sinkclose Universal Ring-2 Privilege Escalation (Not Redacted) [pdf]

#17

Post by ngneer »

kaoD wrote: post #9
tux3 wrote: post #2

I was confused by the title, by "Ring-2" it means "Ring -2" (minus two), which is "traditionally" SMM (System Management Mode), a horrible relic that lets your BIOS/UEFI silently steal the CPU from the OS to implement janky drivers or workarounds directly in the firmware (occasionally causing all sorts of mayhem). (Actual Ring 2 is very rarely seen, so perhaps I should have known!)

Wait, there are negative rings!? I'd like to learn more about this but it's not a very easy to search term. Any pointers?

Just terminology. Whenever a new higher-privileged entity is created, it is sometimes described as a negative ring.

There was a time when people thought if we could put the secure code in a lower ring, then with it we could protect the rest of the system. With virtualization, the hypervisor is in ring -1, which is technically not a ring, but rather a mode called VMX root operation, post-VMXON. This enables things like the blue pill attack, where the hypervisor is itself presented with a false image of the underlying physical hardware, by a malicious layer. You can find the same pattern in ARM TrustZone, where the secure code is repeatedly broken.

"if only we had ring -N"

Re: DEF Con 32 – AMD Sinkclose Universal Ring-2 Privilege Escalation (Not Redacted) [pdf]

#18

Post by paulmd »

it's funny that they have to debunk the "root is root, why would AMD patch this" that goes around every time there's a serious issue that allows guest-root escape from virtualized containers.

the same thing happened with the ryzenfall/masterkey exploit, where people were just in utter denial there was an actual exploit there, because root is root! People literally spent more time talking about who released it and their background image than the actual exploit. AMD obvious cannot have exploits, that's only an intel thing. /s

"alleged" flaws" (rolls eyes) https://old.reddit.com/r/Amd/comments/845w8e/alleged_amd_zen...

assassination attempt* https://old.reddit.com/r/hardware/comments/849paz/assassinat...

doxxing the researchers: https://old.reddit.com/r/hardware/comments/845xks/some_backg...

https://old.reddit.com/r/Amd/comments/84tftt/clarification_a...

https://old.reddit.com/r/Amd/comments/8589t2/cts_labs_clarif...

HN discussions were not much better, although tpacek is cool.

https://news.ycombinator.com/item?id=16576342

https://news.ycombinator.com/item?id=16576516

https://news.ycombinator.com/item?id=16597626

Re: DEF Con 32 – AMD Sinkclose Universal Ring-2 Privilege Escalation (Not Redacted) [pdf]

#19

Post by transpute »

Android pKVM hypervisor tries to constrain vendor-specific Arm EL3 TrustZone (~x86 SMM Ring-2) on Pixel 7/8/9, https://lkml.org/lkml/2022/11/16/1241

  pKVM's primary goal is to protect guest pages from a compromised host by enforcing access control restrictions using stage-2 page-tables. Sadly, this cannot prevent TrustZone from accessing non-secure memory, and a compromised host could, for example, perform a 'confused deputy' attack by asking TrustZone to use pages that have been donated to protected guests. This would effectively allow the host to have TrustZone exfiltrate guest secrets on its behalf, hence breaking the isolation that pKVM intends to provide..

  FF-A provides (among other things) a set of memory management APIs allowing the Normal World to share, donate or lend pages with Secure. By monitoring these SMCs, pKVM can ensure that the pages that are shared, lent or donated to Secure by the host kernel are only pages that it owns.. the robustness of this approach relies on having all Secure Software on the device use the FF-A protocol for memory management transactions with the normal world, and not use vendor-specific SMCs that pKVM is unable to parse.
On x86, SMM attestation was introduced by Intel (PPAM / Hardware Shield, 11+ gen) and AMD, https://www.microsoft.com/en-us/security/blog/2020/11/12/sys...

> Because of its traditionally unfettered access to memory and device resources, SMM is a known vector of attack for gaining access to the OS and hardware.. One could have perfect code in SMM and still be affected by behavior like trampolining into secure kernel code.. Isolating SMM is implemented in three parts: OEMs implement a policy that states what they require access to; the chip vendor enforces this policy on SMIs; and the chip vendor reports compliance to this policy to the OS.

Re: DEF Con 32 – AMD Sinkclose Universal Ring-2 Privilege Escalation (Not Redacted) [pdf]

#20

Post by cesarb »

jandrese wrote: post #8

Sometimes it's nice to see SMP causing headaches for the "bad" guys for a change. They did eventually work around it, but half of this paper is working around problems where the second core gets out of sync and crashes as soon as they tried to exploit the system.

The most interesting part, to me, was that entering SMM pauses all cores at once, instead of doing the work in a single core like normal interrupts. That sounds like a performance killer, and I hope entering SMM is really rare in modern systems.
Post reply on HN