I finally received my AAEON UP Xtreme i12 Alder Lake board in the mail. This board is unique because, in addition to being able to debug it with JTAG using the Intel Direct Connect Interface (DCI), the Core i7-1270PE CPU therein has support for Virtualization Technology Redirect Protection: VT-rp. VT-rp is a foundational requirement for advanced security features, specifically Hypervisor-managed Linear Address Translation (HLAT), Paging-Write (PW), and Guest-Paging Verification (GPV).
This will be the first installment of a series of articles to deal with this topic: there is a lot to unpack here, and very little public domain information is available on it. And I don’t pretend to be an expert. But I do have a raging curiosity, and some good tools to work with, which makes it interesting. And the intent of these articles is to chronicle the learning journey, so that when others follow in these footsteps, it’ll be much easier and quicker.
Firstly, to learn more about the underlying technology so that some of this makes sense, I highly recommend Satoshi Tanda’s Intel VT-rp – Part 1. remapping attack and HLAT and Intel VT-rp – Part 2. paging-write and guest-paging verification; Andrea Allievi’s Alder Lake and the new Intel Features; and Connor McGarr’s Exploit Development: No Code Execution? No Problem! Living The Age of VBS, HVCI, and Kernel CFG; and finally the joint presentation by Andrea and Satoshi at REcon, Hypervisor-enforced Paging Translation – The end of non data-driven Kernel Exploits? Having read at least some of these articles, and having a nodding familiarity with the topics, will help immensely.
And with that, let’s get started:
It was Andrea’s Alder Lake article, written in January 2022, that kicked off my interest in this topic; it contains a very easy-to-understand initial description of VT-rp and HLAT and the reasoning behind them:
After the introduction of the Shadow Stack in the 11th generation CPUs (Tiger Lake), there was still just a weak point that needed enhanced hardware protection, the possibility of an attacker to be able to remap one or more protected memory pages, simply by writing in the kernel page tables. The system has no way to prevent an exploiter to write in the page tables, and even Hyperguard (as described in the good article that Yarden Shafir recently published) is not totally able to non-deterministically protect against this kind of remapping…
And a quote caught my eye at the time:
Curious readers would ask if Windows already implements HLAT. The answer is ‘we are working on it’.
Given that this article was written in 2022, I jumped to the conclusion that it would be operational today in current Windows releases. I found out later to my peril that I guessed wrong….keep reading.
The downside of these great security features is the strict hardware requirements: the silicon must support it, and very few Intel CPUs do. And AMD does not support it at all (or, at least, to the best of Satoshi’s knowledge as of July 2023; and my knowledge as of now). It took me a lot of digging before finally finding a suitable target that supported JTAG debug as well. And the information that was available in the Intel ARK was initially wrong. But finally, I discovered that the AAEON UP Xtreme i12 board equipped with the Intel Core i7-1270PE Alder Lake CPU met the needed criteria. I forked over the cash (yes, the board is over $1,000 at the time of this writing), and got my toy.
The very first thing I did was to check if HLAT was enabled “out of the box” on this target, or if there were any specific configurations that had to be tweaked. I booted the target up, connected to it using JTAG with SourcePoint, and looked at the VMCS tertiary controls:
All zeros: hmmmm. Not good. At least bit position 1 needs to be set, per the Intel SDM, Table 25-8:
So, I had to dig a little more to turn it on. A small image in Satoshi’s Part 1 article gave me a hint:
When I opened System Information on my target, I saw the following (excuse the graininess of the image: I’m projecting the HDMI output of my AAEON target onto the same PC that I’m running SourcePoint on, using an HDMI-to-USB converter going into OBS Studio):
I noticed that Satoshi had VBS services “Secure Launch” and “SMM Firmware Measurement” enabled, but mine were not. The article System Guard Secure Launch and SMM protection provided the following guidance to enable these:
Select Start > Settings > Update & Security > Windows Security > Open Windows Security > Device security > Core isolation > Firmware protection
Alas, my screen looks somewhat different:
Maybe enabling this is a multi-stage process? I turned on “Kernel-mode Hardware-enforced Stack Protection”, did a restart, and ran msinfo32 again:
OK, I thought that was better, in that the Hardware-enforced Stack Protection (which enables Control Flow Enforcement Technology (CET) for kernel mode) is running, but I still don’t see Secure Launch. It occurred to me to perform the registry hack as described in Microsoft’s System Guard Secure Launch and SMM protection article, where you enter the new key SystemGuard and enable it. This seems redundant with toggling on the Firmware protection toggle in the Device Security window, but since the Firmware protection toggle is missing, I thought I’d give it a try. But there wasn’t any progress there.
At this point I was a little stumped: by searching around on the web, though, I found a couple of obscure references to the Hardware-enforced Stack Protection that said “it was bundled together with other security features in later Windows releases”. So, the implications was that it should not even show up as an option in the Device security window. Curiouser and curiouser.
I then tried a huge number of things:
I also tried to enable it via Group Policy, by launching gpedit, going to:
Computer Configuration->Administrative Templates->System->Device Guard
and double-clicking on ‘Turn on VBS’ and setting the Secure Launch selection to Enabled, among other settings:
In the AAEON board’s Advanced CRB BIOS menu, I turned on Secure Boot, and Intel TXT. I will circle back at some point to understand if these are required.
Still nothing. Although Secure Launch is Configured, it is not yet Running.
Then an idea came into my head. Maybe my current version of Windows didn’t yet support it? It’s certainly true that in Satoshi’s Part 1 article, he created a custom hypervisor to enable HLAT, and his target was sitting at build 10.0.22621.1848; nothing special. But I wanted to test this with Windows, and my target was sitting at build 10.0.22635.4145. And then I noticed a small note in Twitter that Windows 24H2 enables HVPT (VT-rp/HLAT) to prevent remapping attacks. That was the key to the kingdom! Thanks to Satoshi and Yarden for corresponding on this (but, dang, it was hard to find).
So I enabled Insider Preview on my Alder Lake target (DEV, not Canary), installed Build 10.0.26120.1542 (anything above 10.0.26100 is 24H2). Then, I turned everything off that I had updated previously using Device Security, regedit, and gpedit. All I then needed to do was to use gpedit to Enable VBS per the exact screenshot shown below from System Guard Secure Launch and SMM protection:
Reboot, and then, voila! That was all that was needed. I didn’t even need to go into Device Security to turn on Firmware protection (I still don’t see that toggle button, anyway). Delightfully, Hypervisor-Enforced Paging Translation (aka HLAT) is enabled:
To verify this, I rebooted the target again, and stopped early after VTL1 entry to ensure that all of the HLAT tables were set up, and looked again at the VMCS to confirm:
HLAT, EPT Page-Write Control and Guest Paging Verification are all enabled; very sweet!
This is incredible, and very exciting. Now, it’s time to start poking at it, and I’ll write about that in an upcoming article.
