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!)
> Please refer to your OEM for the BIOS update specific to your product.
Unless running hardware also used by powerful hosting providers (some of which care for security), these mitigation will not reach many systems. Checked a few "client" samples, seems like MSI has provided updated binary blobs, ASRock has provided some, Gigabyte has provided broken ones first and then backdated the new ones, ASUS (ROG/RUF/CSM) and Biostar customers are still waiting.
The paper asks "why does this feature exist?" - probably they haven't gone far enough back in history (note I've worked on x86 clones I understand this stuff in far too great a detail)
Originally on x86 systems memory was in VERY short supply - SMM mode memory was the DRAM that the VGA window in low memory (0xa0000) overlaid - normal code couldn't access it because the video card claimed memory accesses to that range of addresses - so the north bridge when the CPU was in SMM mode switched data and instruction accesses to that range to go to DRAM rather than the VGA card .... that's great except remember that SMM mode was used for special setup stuff for laptops .... sometimes they need to be able to display on the screen .... that's what this special mode was originally for: so that SMM mode code can display on the screen (it's also likely why SMM mode graphics were so primitive, you're switching in and out of this mode for every pixel you write)
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.
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.
> 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.
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
PS: they did release technical details once the mitigations had been released etc. And these were released to tech researchers earlier, and proof of concepts were shown etc. https://youtu.be/QuqefIZrRWc?t=1005
And, like, the fact that AMD released an urgent patch for it should kind of speak to the severity of the issue in the first place. AMD doesn't patch "sudo lets you do root things", obviously, so it necessarily must have been more than that, and this was obvious even at the time. But we have to go through this dance with literally every single AMD exploit.
AMD has a unpatched exploit in all Zen3 and below processors that leaks data from kernel at a faster rate than meltdown did. It was discovered by the same researchers that discovered meltdown. AMD has chosen to leave that unpatched, and put out a weaselly deflection about "it doesn't cross address boundaries" but they also still refuse to turn KPTI on by default because it would hurt their benchmarks. And without KPTI there is no address boundary to cross, that's the weaselly part. AMD very craftily made it sound like they're saying there's not an issue, but in fact they are fully confirming the finding from the researcher, including the suggested mitigation (enabling KPTI), they just don't recommend that you do it. The statement is deliberately short to avoid inclusion of too many details that might dispel these misleading impressions.
This follows that same researcher (who previously discovered meltdown) uncovering a prior series of vulnerabilities in the cache ways predictor that also nullify KASLR... which AMD refused to patch because it "didn't leak actual data, only metadata"... the metadata being the page-table layouts. That one is still unpatched too - as the researchers note, AMD never actually mitigated this either, just more weasel words.
(this one literally doesn't even seem to have a security bulletin page for itself so I guess they have fully shoved this one down the memory hole now, but here's the news item from wayback) http://web.archive.org/web/20200325045817/https://www.amd.co...
After 6+ years of watching the community defend this behavior, downplay exploits from their favorite megacorporation, etc, it just gets old. Not liking how CTS labs did it or whatever is fine. It doesn't mean there's not a serious exploit, and so often that is where people end up with these AMD exploits, they like AMD so much that they argue against the existence or significance of the exploit, attack the researchers or whine about research grants, etc.
"Does this really deserve this CVE score" is a constant refrain in AMD vuln threads and it just gets so old. As tptacek noted... intel ME vulns are frontpage news and have people asking where they can buy a processor without ME in it. Literally nobody cares that AMD has had these vulnerabilities left open and unmitigated for years and years even though they're actually worse (as judged by the researcher who found both these issues and meltdown).
People would have flipped the fuck out if Intel left meltdown unpatched and released misleading statements implying that it wasn't an issue etc. It is wild just how much AMD is playing on story-mode difficulty with the average enthusiast, and honestly most people don't even realize they're doing it. And that drives me nuts - just decide if security issues are a problem or not, and if the answer is "not" then let's just turn all the mitigations off and see how long they remain un-exploited. If we want to have the security version of the drug-assisted olympics then fine, there is value in having dragsters that just do the thing as quickly as possible, right? But the double-standard people apply to anything AMD is crazy. Talk about your "tyranny of low expectations".
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?
AMD fix status: https://www.amd.com/en/resources/product-security/bulletin/a...
https://ubuntu.com/security/CVE-2023-31315
> Please refer to your OEM for the BIOS update specific to your product.
Unless running hardware also used by powerful hosting providers (some of which care for security), these mitigation will not reach many systems. Checked a few "client" samples, seems like MSI has provided updated binary blobs, ASRock has provided some, Gigabyte has provided broken ones first and then backdated the new ones, ASUS (ROG/RUF/CSM) and Biostar customers are still waiting.
The paper asks "why does this feature exist?" - probably they haven't gone far enough back in history (note I've worked on x86 clones I understand this stuff in far too great a detail)
Originally on x86 systems memory was in VERY short supply - SMM mode memory was the DRAM that the VGA window in low memory (0xa0000) overlaid - normal code couldn't access it because the video card claimed memory accesses to that range of addresses - so the north bridge when the CPU was in SMM mode switched data and instruction accesses to that range to go to DRAM rather than the VGA card .... that's great except remember that SMM mode was used for special setup stuff for laptops .... sometimes they need to be able to display on the screen .... that's what this special mode was originally for: so that SMM mode code can display on the screen (it's also likely why SMM mode graphics were so primitive, you're switching in and out of this mode for every pixel you write)
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.
These aren’t the “bad” guys. The “bad” guys are the people who put that backdoor in, deliberately or through lack of oversight.
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
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.
Is the recorded session available anywhere? Generally prefer the slides with the presenter walking us through them.
magnet:?xt=urn:btih:6b0c446541294d6b4ac0cfd6cdedf48e20034ad4&dn=defcon-talks&tr=udp%3A%2F%2Ftracker.opentrackr.org%3A1337%2Fannounce&tr=udp%3A%2F%2Fopen.tracker.cl%3A1337%2Fannounce&tr=udp%3A%2F%2Fopen.demonii.com%3A1337%2Fannounce&tr=udp%3A%2F%2Fopen.stealth.si%3A80%2Fannounce&tr=udp%3A%2F%2Ftracker.torrent.eu.org%3A451%2Fannounce&tr=udp%3A%2F%2Fexplodie.org%3A6969%2Fannounce
DEF CON recordings tend to take a while to appear. This one was supposedly recorded,[0] but I can't find it.
[0]: https://info.defcon.org/event/?id=54863
It was available live for a while. Defcon's video publishing kinda sucks.
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
PS: they did release technical details once the mitigations had been released etc. And these were released to tech researchers earlier, and proof of concepts were shown etc. https://youtu.be/QuqefIZrRWc?t=1005
And, like, the fact that AMD released an urgent patch for it should kind of speak to the severity of the issue in the first place. AMD doesn't patch "sudo lets you do root things", obviously, so it necessarily must have been more than that, and this was obvious even at the time. But we have to go through this dance with literally every single AMD exploit.
AMD has a unpatched exploit in all Zen3 and below processors that leaks data from kernel at a faster rate than meltdown did. It was discovered by the same researchers that discovered meltdown. AMD has chosen to leave that unpatched, and put out a weaselly deflection about "it doesn't cross address boundaries" but they also still refuse to turn KPTI on by default because it would hurt their benchmarks. And without KPTI there is no address boundary to cross, that's the weaselly part. AMD very craftily made it sound like they're saying there's not an issue, but in fact they are fully confirming the finding from the researcher, including the suggested mitigation (enabling KPTI), they just don't recommend that you do it. The statement is deliberately short to avoid inclusion of too many details that might dispel these misleading impressions.
https://www.usenix.org/system/files/sec22summer_lipp.pdf
https://www.amd.com/en/resources/product-security/bulletin/a...
proof of concept: https://github.com/amdprefetch/amd-prefetch-attacks/blob/mas...
tested a few months ago and it's still working: https://news.ycombinator.com/item?id=40850526
This follows that same researcher (who previously discovered meltdown) uncovering a prior series of vulnerabilities in the cache ways predictor that also nullify KASLR... which AMD refused to patch because it "didn't leak actual data, only metadata"... the metadata being the page-table layouts. That one is still unpatched too - as the researchers note, AMD never actually mitigated this either, just more weasel words.
https://www.tomshardware.com/news/new-amd-side-channel-attac...
https://mlq.me/download/takeaway.pdf
(this one literally doesn't even seem to have a security bulletin page for itself so I guess they have fully shoved this one down the memory hole now, but here's the news item from wayback) http://web.archive.org/web/20200325045817/https://www.amd.co...
After 6+ years of watching the community defend this behavior, downplay exploits from their favorite megacorporation, etc, it just gets old. Not liking how CTS labs did it or whatever is fine. It doesn't mean there's not a serious exploit, and so often that is where people end up with these AMD exploits, they like AMD so much that they argue against the existence or significance of the exploit, attack the researchers or whine about research grants, etc.
"Does this really deserve this CVE score" is a constant refrain in AMD vuln threads and it just gets so old. As tptacek noted... intel ME vulns are frontpage news and have people asking where they can buy a processor without ME in it. Literally nobody cares that AMD has had these vulnerabilities left open and unmitigated for years and years even though they're actually worse (as judged by the researcher who found both these issues and meltdown).
People would have flipped the fuck out if Intel left meltdown unpatched and released misleading statements implying that it wasn't an issue etc. It is wild just how much AMD is playing on story-mode difficulty with the average enthusiast, and honestly most people don't even realize they're doing it. And that drives me nuts - just decide if security issues are a problem or not, and if the answer is "not" then let's just turn all the mitigations off and see how long they remain un-exploited. If we want to have the security version of the drug-assisted olympics then fine, there is value in having dragsters that just do the thing as quickly as possible, right? But the double-standard people apply to anything AMD is crazy. Talk about your "tyranny of low expectations".
[flagged]
[flagged]