 Hello everyone. Thanks for attending this session. I'm Gao Chao. I'm working for Intel. Today we're going to talk about cooling integrity enforcement with H9 watch machine. Okay, let's get started. So here is today's agenda. The first part is about some background. I will explain why address translation integrity is important and what would happen if the integrity can be ensured. The second part is an introduction to H-Lite. We would introduce the hardware capability and how to change kind of hardware behavior. In the master part, I would describe the H-Lite-based solution to enforce color integrity and some security conservation and its secure value. So let's start from address translation integrity. As you know, page tables not only translate virtual drives to visual drives, but also define some permission control bits in page table entry. For example, the present bit, read-write bit, user-supervised bit, and execution-disabled bit. Many secure features to enforce access control are built on this permission piece. For example, in current latest kernel code and raw data are not the read-only in page table. It can reduce kernel's attack surface. And the kernel also marks its data stack as non-cruelable. Kernel also uses SMAP or SMAP to segregate user and kernel memory access. So one is access control methods are implemented in page table, but page table itself is readable, so it's vulnerable. For example, assuming that an unpowerful attack is about to excite the arbitrary memory by exploring some kernel vulnerabilities, it can inject shell coding to kernel with following steps. First, it can get page table location from test track. For example, as an MMM struct pointer in test track, and from MMM struct, we can locate the page table's root page. Then on the tag account, override the page table to set a kernel code writable. Then it can override the beginning of this call with shell code. So as you can see, the integrity of page table or translation is important. If the integrity isn't sure, access control can be easily bypassed. So let's look at the two typical page tables over write attack. One is asian alias mapping. For example, when virtual drive is mapped to a physical page without write permission, I assume a powerful attack or write it has arbitrary memory access. You can set up on alias mapping to the physical page and write the page. So you can modify the content and maybe inject some shell code. Now I'm going to try to execute a code with the original virtual drive to get a modified code. So the other attack is page remarking. In this attack, the adversary doesn't need to modify the real physical page. They just copy the content from the original page to a new physical page. And modify the content and then redirect the original virtual drive to this new physical page. Yeah, some VMMs use the EPT to enforce access control and enhance guest kernel security. But the EPT is the only responsible for translation from guest physical drive to host a physical drive. They can enforce the translation from guest virtual drive to guest physical drive. So even with access control in EPT, VMMs kernel is still vulnerable to page remarking attack. Here is an example. You can enforce access control at the EPT level. Now I'm going to read all in this physical page. But our attack still can copy the content to another physical page and redirect the guest virtual drive to another guest physical page. This attack can't be detected by the VMM. VMM does not monitor guest's page table change. Currently, we don't want to monitor guest's page table change because you will require the VMM to track, for example, move to the CS3 instruction and write the project to the CS3 page and audit each change to the page table. So it is similar to what ShadowPage does and what we know it would need to have significant performance penalty. So the part two about page light. Page light is short for hypervisor manager in linear drive translation. And here is the page light specification. If you are interested in it, you can download the stack from this link. The primary goal of each light is to enforce guest translation integrity and prevent page table override attacks. How does each light work? Here is the key idea. Each light allows VMM to specify a virtual drive range here. So-called PLR, which means protecting linear drive range. For virtual drive in PLR, the translation is done by a new page table called each light instead of the CS3 page table. And each light is management by VMM. VMM can use EBT to prevent guest occurrence from changing each light. Other virtual drives outside PLR are still translated with the CS3 page table. The main benefits of each light are security and efficiency. As PLR here and the each light are mentioned by VMM, they can be changed by guest OS. Then for guest virtual drives in PLR, linear translation isn't vulnerable to page renapping attack. And it's efficient compared with EBT based page table protection. Because with each light, VMM doesn't need to intercept change to CS3 page table. VMM only needs to specify PLR and construct each light page table. And this page is about each light as a change to last page table fuck. The last blue box is the next is a page table walk. For given virtual drives, page walker uses CS3 page table to translate the guest virtual drives to guest virtual drives. And the EBT translate against the virtual drives to host virtual drives. Then the mapping can be cached in TLP. With each light enabled, VMM defines the PLR, CPU dials the PLR check. If the guest virtual drive is in this PLR range, the CPU walks to each light rather than CS3 page to get a guest virtual drive and a cached mapping you find. During each light walk, CPU would encounter restart bit. After another CPU restart page walk, it's CS3 page table. And each light will also introduce additional checks in EBT power to occur later. So each page is about each light page structure. Each light page structure are almost the same as A32E page structure. It supports both the five-level and four-level hierarchy. And the BT11, which is previously ignored, is repurposed and restarted bit. Paying this bit result that page walker restarted from guest CS3 page table. And about page 4, if page walker encounters non-present entry or misconfigured entry, for example, the result bits are set in each light page structure. So if you report page 4 to software with a new page 4 error code, the bit 7, means the fault is each light terminal fault and the other page 4 error code are set as usual. Now two new EBT control bits are defined to help track alias mapping. One is the page-in-write. Page-in-write allows CPU to update ADBs on page, even if they are not readable to software. For example, previously, if write permission is set in EBT entry, then CPU is allowed to write through the page and ADBs update if the page is used as a page table. But if no write permission, both software writes and ADBs update would be delayed and cause EBT devaluation benefit. Page-in-writes introduce a new configuration. If a page is not readable but has page-in-write side, then direct software writes are delayed, but CPU update ADBs are allowed. Basically, page-in-writes improve efficiency if VMM needs to read only against the page table and the EBT. You can reduce VMM access due to ADBs update, and then VMM don't need to do ADBs evaluation. So the other bit is VIRTHA page-in-writes. VIRTHA page-in-writing enforcement will leave against the page-in-structure page encountered during master page table work as PW site on the EBT. Otherwise, it generates an EBT violation. Specifically, this page is set as VIRTHA page-in-write on the EBT here, and CPU with VIRTHA light all against the page table pays as PWA site on the EBT. Otherwise, an EBT is EBT violation generated. VMM can use VPW and PW as two EBT control ways to prevent memory access through ANS mining. For example, for memory to be protected, VMM said VPW flag and the EBT, and said PW flag for each slide page-in-structure on the EBT. Then the protected memory can only be accessed through each slide. If I tag a side of ANS mining in CR3 page table to access a protected memory, memory access to protected memory will cause EBT violation due to less than low PW flag in the ASM mining setup by an attacker. Let's look at how to use H9 to reinforce color integrity. This is the high-level architecture of using H9 to protect translation for color tags and raw data. Here we have a VMM and a virtual machine and a secure kernel for the virtual machine. In a virtual machine, there are two page tables to translate against a virtual device. One is the legacy CR3 page table, and the other is the only user to translate, for example, user memory, read, write data, and stack. The current code and the raw data is protected and translated with H9. H9 enforce read-only mapping on color tags and raw data. H9 itself is also read-only in the normal kernel's view and read-write in the secure kernel. When normal kernel wants to set up a new protected mapping, or tiered existing mapping, it can talk with secure kernel students' communication channel. Then the secure kernel can audit request and change H9 accordingly. In this architecture, we don't allow normal kernel to modify H9 page table because if normal kernel can modify H9 page table, the translation for color tags and raw data can be redirected. But trust entity is required to measure H9 to page instructions. We rely on secure kernel in this design, but trust entity can also be the VMM. In that case, there are a lot of intrusive changes, such as some policies needed to be implemented inside the VMM. Through this H9 management have called, secure kernel can set VPW flight for kernel tags and raw data on the EPT, and set PW flight for H9 page instructions on the EPT. By ensuring that the only secure kernel can invoke this have called. Normal kernel can't set up any of the mapping to excise the protected memory. Sometimes the guest kernel needs to set up when the tiered on protected memory inside runtime. For example, when guest knows a new module, it will insert some executable code in your kernel, and for the new code, neural translation also needs to be protected. During module unloading, we need to tier down the protected mapping, such that the virtual address range and the memory can be reused. But we need to avoid the build of tiered on operation. For example, on attack can just request a secure kernel to tier down protected mapping for kernel code and then modify kernel code. One feasible solution is we can utilize model-based execution control for EPT. For example, secure kernel ensures code has a correct signature when setting up protected mappings, and give execute for permission in supervisor mode. And if protecting mapping is torn down, then revoke execute for permission in supervisor mode. Actually, in news kernel, there are some valid and some important changes to kernel text and runtime. For example, function tracing for debugging, jump label, and all the labels. It should be allowed, but we can't allow normal kernel to do text passion directly. Ideally, text passion needs to be down in secure kernel, and secure kernel can implement a proper policy to audit the request based on the location to patch and all the patched out. So what's the security values of this solution? Yeah, basically it defends against code injection attacks like hook, syscore, or override IDT, and reads the bio exploiting kernel vulnerabilities. And with this solution, even if normal kernel is compromised, VMM with secure kernel can ensure the integrity of normal kernel's code and raw data. This is a summary to the next session. First, restricting access to code and raw data can reduce attack surface of kernel. But patch table attacks can bypass such restrictions. And the H9 providers are efficient way to reinforce the integrity of a guest translation, and VMM can use H9 and EPD contributors to reinforce the integrity of a kernel code and raw data. Yeah, this is the last page. Do you have any questions?