 Hello, thanks for attending this session. I'm Gaucho working for Intel. Today I'm going to share with you a new extension to Intel VTX, the hypervisor manager, the linear address translation, or HLACT. So here is today's agenda. The first part is a problem statement. Basically, I will explain the problem in access control and the next background of the reason why HLACT is introduced. The second part is our introduction to HLACT. I will introduce these new hardware capabilities and the changes in hardware behavior. In the last part, I will describe HLACT based solution to enforce guest translation. And it's a secure value, it's impact to QVM and the guest corner. So the part one. Currently, access control is widely used in news corner to reduce the tech surface. For example, Linux corner marks executable code non-writeable in pit table and marks data non-useable in pit table. In general, pit table based access control is efficient. But in theory, if an attacker would write to actually memory by exploiting some kind of one-on-one base, it could override pit table. And bypass access control enforced by pit table. So to defend against a tax net override pit table, we need to enforce a guest translation integrity. In a virtual machine, we can use EBT to write up a tax CR3 pit table, but it leads to a high performance penalty. So we introduce it to address the performance issue. OK, let's look at the two typical pit table overriding attacks. One is AS mapping. For example, one virtual address is mapped to a Facebook page without the right permission. I assume that an attacker already has a habitual memory access, so he can set up a AS mapping to the Facebook page and then soon this AS mapping memory writes out loud so the attacker can modify the page's content. Maybe he can inject some share code into this page. Now I'm going to try to execute code. The share code is triggered. So another attack is a page remapping. The adversary doesn't need to modify the real page, just copy the content to another page and modify this page. And then the attack override the pit table to redirect the original virtual address to the modified page. Then part two, each slide introduction. Here is the each slide spec. You can download the spec from this link. And the goal of each slide is to enforce guest translation integrity and prevent attacks on that override page table. So here is the key idea of each slide. Each slide allows VMM to specify a virtual address range, so-called protected and linear range, or PRR, here. For virtual drives in PRR, CPU page worker performs address translations through each slide page table. For a virtual drive outside of PRR, CPU page worker performs address translation through CS3 page table. The main benefits of each slide are security and efficiency. But over by right-clicking each slide page instructions, the virtual drives in PRR won't be redirected to other page. So it is invulnerable to page remapping attack. And it's efficient compared with the EPG-based page table protection, because with each slide, VMM doesn't need to intercept the changes to CS3 page table. This page is about each slide's change to nested the page table work. This blue box here is the neck and seam nested the page table work. For given virtual drives, CPU page worker performs the first never address translation through the CS3 page table, and then gets the virtual drives. Then performs the EPD work to translate the get the virtual drives to host the virtual drives and cast a mapping to TRB. With each slide enabled, the CPU workers will perform a PRR check first. If the get the virtual drives is in the PRR, CPU page worker performs the address translation through each slide rather than CS3 page table. And during on each slide work, page worker may encounter restart between each slide page table entry. So in that case, page worker would restart the page work through CS3 page table. And each slide also introduce additional check in EPG. I will introduce them later. Each slide page instructions are almost the same as IA32E page instructions. It supports both the five-level and the four-level page. And the BT11 is the restart bit. Pating this bit results that page work restarts with CS3 page table. And during on each slide work, CPU would read page fault exception if page worker encounters non-present entry or misconveration, for example, reserved bits are set in each slide BDE. In that case, CPU sets bit seven of page fault error code to indicate that this page fault is on each slide terminal fault. Now, two new EBD control bits are introduced to track earlier mapping. One is the PagingRite. PagingRite allows CPU to update ADBs on page, even they are not readable to software. For example, previously, if it is set in EBD, read through the page and do ADBs update if the page is used as a page table. But if the read permission is cleared on EPD entry, then both software writes and the ADBs updates are denied and they call the EPD violation. If CPU tries to do so, PagingRite introduce a new configuration. If the read permission is cleared but the PagingRite is set in an EPD entry, then only software writes is denied. ADBs update are allowed. Basically, PagingRite can improve efficiency if VMM needs to read only guest page table under EPT. It can reduce VMM access due to ADBs update and relieve VMM flow ADB simulation. The other bit is the Verify PagingRite. Verify PagingRite enforces that all leave guest page structure page encountered during the next to the work has PW site on the EPT. Else generates an EPT violation. Specifically for this page, the VPW flag is set in EPD entry. Then CPU would verify that for all list guest page structure page, they have PagingRite site under EPT. Otherwise, an EPT violation is generated. VMM can use PW and VPW flags to prevent memory access through ADS mapping. For example, for guest physical memory to be protected, VMM can set VPW flag on the EPT and then set PW flag for each like the PagingStructure page. Because of the hardware check against VPW, this protective memory can only be exercised through HLite. If an attack try to set up ADS mapping to exercise VPW tag memory in CSV page table, memory exercise to VPW tag memory would cause the EPT violation due to low PW flag in ADS mapping. So then part three. Example of using HLite to reinforce guest translation integrity. This is the HLite architecture. Here we have VMM and the virtual machine on it. In the virtual machine guest column maintains two page tables, CSV page table and HLite page table. First guest column needs to identify guest pages on translations to be protected. Guest column, here we use column text and the raw data as an example. Guest column sets up a protected translation in HLite and write a text HLite page table on the EPT. So protected translations can be redirected. These translations are mapped to some guest physical page. For this guest physical page, VMM size VPW flag for the EPT and the side PW flag for HLite page structures. So if an attack wants to set up an ADS mapping to protected memory and to exercise this protected memory, the ADS mapping needs to have PW side on the EPT. So that the attacker needs to be able to call some help calls. Guest column may decide to protect or unprotect some translations at a random. In that case, Guest column needs to update the HLite page table, but all pages or HLite page page structures are read protected on the EPT. So to update the HLite page structures, Guest column needs to reverse read production on related HLite page instruction page, which is one to update through help call, then update the HLite page table and then apply write protection on HLite page table again. So as you can see to update the HLite, Guest column needs to call several help calls, then updating HLite is low, but it brings one benefit. Yeah, because HLite page table is read only on the EPT to override a PTE in HLite, an attacker must first invoke a help call to reverse write protection on HLite page table. So what's the security value of this solution? In theory, an attacker with arbitrary memory write capability can override the page table to make current attacks of raw data available and then override the current attacks of the raw data. If this solution is deployed in need of the kernel, overriding the HLite page table can't redirect the translation for current attacks and the raw data. And the override HLite page table is much harder because in most of the time HLite page table is read only on the EPT, the attacker needs to turn off HLite first or make HLite page table writeable on the EPT. Someone may have one question in mind, why does kernel not just write product sales with page table on the EPT? I think there are two reasons. HLite based solution is more efficient. It doesn't need to intercept the CR3 solution and it can use PRR and restart it in HLite page table to enforce translation and for key page granularity. Well, CR3 page table write protection will impact the setup and the teardown of other normal mappings. Secondly, I think HLite based solution is relatively clean because it doesn't need change in CR3 page table management. It use a new page table could adjust the focus on how to manage the new page table and doesn't need to, doesn't need intrusive change to current memory management and through our POC we think the change site is small. We have finished POC for this solution and this is a test model we use to demonstrate the effect of HLite's protection to get the translations. This model accepts a virtual drives and first you try to modify CR3 page table to grant write permission and then it writes a zero to this virtual drives. And then in our test, we pass the set address of current text to this module without the solution. This writes would succeed without any error but with this solution, this write would cause page fault and color ops. From the current message, here are dumps of two page table. The first line is from HLite page table and the second line is from CR3 page table. We can see that the page table is writeable in CR3 page table. It calls the bit one is set in PDE and the non-writeable in HLite. So based on our POC needs three major changes are needed in QM side to implement this solution. First QM advertiser or PV feature through CPU ID have a wider leaf. Generally, this feature cause guest and that guest can set the HLite route and the PRR through have call. And the guest also can set the VPWPW and RO flags for guest page on the EPD. To manage this EPD flags, we can just extend the existing page tracking mechanism in QM and as now guest is able to set the EPD flags then some EPD violations may result from guest setting. So from these EPD violation, QM doesn't need to handle it and just reports a virtualization exception. Guest kernel also needs to make some changes to implement this solution. Guest kernel needs to manage HLite page table and EPD flags for guest page. It just needs to place some hooks in set memory RO or RW APIs. These APIs are used to remove a set of write permissions in CR3 page table. Guest kernel also needs to handle page fault exception in page fault handler from the page fault area called kernel can know why the page fault is on HLite terminal fault or not. And if the photo drives is in the PRR, page fault handler may need to walk HLite page table by software. And the guest kernel also needs to handle virtualization exception and generate the means on attack is detected by hypervisor. Regarding our status, we finish a change on QVM guest kernel and develop some tests in QVM unit tests and a verify this solution simulator. And our plan is to send out the IFC page in the future and currently we focus on protecting non-writeable mappings in the future. I would like to explore the possibility of using HLite to enforce the integrity of non-isqeable mappings. So yeah, that's all I want to share. Do you have any question?