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).<p>(Actual Ring 2 is very rarely seen, so perhaps I should have known!)
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)<p>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.
Android pKVM hypervisor tries to constrain vendor-specific Arm EL3 TrustZone (~x86 SMM Ring-2) on Pixel 7/8/9, <a href="https://lkml.org/lkml/2022/11/16/1241" rel="nofollow">https://lkml.org/lkml/2022/11/16/1241</a><p><pre><code> 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.
</code></pre>
On x86, SMM attestation was introduced by Intel (PPAM / Hardware Shield, 11+ gen) and AMD, <a href="https://www.microsoft.com/en-us/security/blog/2020/11/12/system-management-mode-deep-dive-how-smm-isolation-hardens-the-platform/" rel="nofollow">https://www.microsoft.com/en-us/security/blog/2020/11/12/sys...</a><p><i>> 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.</i>
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.<p>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<p><i>"alleged" flaws" (rolls eyes) <a href="https://old.reddit.com/r/Amd/comments/845w8e/alleged_amd_zen_security_flaws_megathread/" rel="nofollow">https://old.reddit.com/r/Amd/comments/845w8e/alleged_amd_zen...</a><p></i>assassination attempt* <a href="https://old.reddit.com/r/hardware/comments/849paz/assassination_attempt_on_amd_by_viceroy_research/" rel="nofollow">https://old.reddit.com/r/hardware/comments/849paz/assassinat...</a><p>doxxing the researchers: <a href="https://old.reddit.com/r/hardware/comments/845xks/some_background_information_on_the_new_amd/" rel="nofollow">https://old.reddit.com/r/hardware/comments/845xks/some_backg...</a><p><a href="https://old.reddit.com/r/Amd/comments/84tftt/clarification_about_the_recent_vulnerabilities/" rel="nofollow">https://old.reddit.com/r/Amd/comments/84tftt/clarification_a...</a><p><a href="https://old.reddit.com/r/Amd/comments/8589t2/cts_labs_clarifications_on_ryzenfall_masterkey/" rel="nofollow">https://old.reddit.com/r/Amd/comments/8589t2/cts_labs_clarif...</a><p>HN discussions were not much better, although tpacek is cool.<p><a href="https://news.ycombinator.com/item?id=16576342">https://news.ycombinator.com/item?id=16576342</a><p><a href="https://news.ycombinator.com/item?id=16576516">https://news.ycombinator.com/item?id=16576516</a><p><a href="https://news.ycombinator.com/item?id=16597626">https://news.ycombinator.com/item?id=16597626</a>