On Wed, 1 Mar 2023 08:56:05 -0800 Dave Hansen <dave.hansen@xxxxxxxxx> wrote: > On 2/20/23 10:37, Michael Roth wrote: > > The RMP check is enforced as soon as SEV-SNP is enabled. Not every memory > > access requires an RMP check. In particular, the read accesses from the > > hypervisor do not require RMP checks because the data confidentiality is > > already protected via memory encryption. When hardware encounters an RMP > > checks failure, it raises a page-fault exception. If RMP check failure > > is due to the page-size mismatch, then split the large page to resolve > > the fault. > > What does this all _mean_? > Unlike TDX which implements secure EPT to hold the restricted memory mapping, SEV-SNP is still using one NPT (similar to Intel EPT) while adding another level of HW-enforced check controlled by the "RMP" table. Similar to TDX, it has firmware calls to modify the attributes in the RMP table to achieve isolation and shared-private memory conversion. The purpose and structure of RMP is quite similar to the PAMT table in TDX from the perspective of managing the per-page attributes. Each system page has a collection of attribute bits. But TDX only uses the PAMT as metadata as it has a separate secure EPT to achieve HW-enforced check. The RMP memory access checks has its own schematics. E.g. data write, page table access from VMM will be checked, but data read is not, mostly I guess, due to performance consideration. More details can be found from Table 15-39. RMP Memory Access Checks in [1]. > When does the kernel need to care about a "page-size mismatch"? The RMP table has the ability to describe a large page (similar to a large page with a description of large-page PAMT entry in TDX that can be demoted via TDX SEAMCALLs). E.g. 2MB page. When the userspace sets the memory attribute of a GFN range through the restricted memory ioctl, the sev logic (sev_update_mem_attr() in PATCH 48, to be precise) will try to build a large page description in the RMP table if the PFNs are continuous. When kernel mm breaks the the large page due to THP, KVM updates the NPT accordingly. Then there will be a page-size mismatch between NPT and RMP. It will be resolved by a RMP fault later. Kinda of lazy sync. [1] https://www.amd.com/system/files/TechDocs/24593.pdf
