[AMD Official Use Only] > -----Original Message----- > From: Varad Gautam <varad.gautam@xxxxxxxx> > Sent: Friday, July 23, 2021 6:04 AM > To: Joerg Roedel <jroedel@xxxxxxx>; David Rientjes > <rientjes@xxxxxxxxxx>; Borislav Petkov <bp@xxxxxxxxx>; Andy Lutomirski > <luto@xxxxxxxxxx>; Sean Christopherson <seanjc@xxxxxxxxxx>; Andrew > Morton <akpm@xxxxxxxxxxxxxxxxxxxx>; Vlastimil Babka <vbabka@xxxxxxx>; > Kirill A. Shutemov <kirill.shutemov@xxxxxxxxxxxxxxx>; Andi Kleen > <ak@xxxxxxxxxxxxxxx>; Singh, Brijesh <brijesh.singh@xxxxxxx>; Lendacky, > Thomas <Thomas.Lendacky@xxxxxxx>; Grimm, Jon > <Jon.Grimm@xxxxxxx>; Thomas Gleixner <tglx@xxxxxxxxxxxxx>; Peter > Zijlstra <peterz@xxxxxxxxxxxxx>; Paolo Bonzini <pbonzini@xxxxxxxxxx>; > Ingo Molnar <mingo@xxxxxxxxxx>; Kaplan, David > <David.Kaplan@xxxxxxx>; Dario Faggioli <dfaggioli@xxxxxxxx> > Cc: x86@xxxxxxxxxx; linux-mm@xxxxxxxxx; linux-coco@xxxxxxxxxxxxxxx > Subject: Re: Runtime Memory Validation in Intel-TDX and AMD-SNP > > [CAUTION: External Email] > > On 7/19/21 2:58 PM, Joerg Roedel wrote: > > Hi, > > > > I'd like to get some movement again into the discussion around how to > > implement runtime memory validation for confidential guests and wrote > > up some thoughts on it. > > Below are the results in form of a proposal I put together. Please let > > me know your thoughts on it and whether it fits everyones requirements. > > > > Thanks, > > > > Joerg > > > > Proposal for Runtime Memory Validation in Secure Guests on x86 > > > ========================================================== > ==== > > > > This proposal describes a method and protocol for runtime validation > > of memory in virtualization guests running with Intel Trusted Domain > > Extensions (Intel-TDX) or AMD Secure Nested Paging (AMD-SNP). > > > > AMD-SNP and Intel-TDX use different terms to discuss memory page > states. > > In AMD-SNP memory has to be 'validated' while in Intel-TDX is will be > > 'accepted'. This document uses the term 'validated' for both. > > > > Problem Statement > > ----------------- > > > > Virtualization guests which run with AMD-SNP or Intel-TDX need to > > validate their memory before using it. The validation assigns a > > hardware state to each page which allows the guest to detect when the > > hypervisor tries to maliciously access or remap a guest-private page. > > The guest can only access validated pages. > > > > There are three ways the guest memory can be validated: > > > > I. The firmware validates all of guest memory at boot time. This > > is the simplest method which requires the least changes to > > the Linux kernel. But this method is also very slow and > > causes unwanted delays in the boot process, as verification > > can take several seconds (depending on guest memory size). > > > > II. The firmware only validates its own memory and memory > > validation happens as the memory is used. This significantly > > improves the boot time, but needs more intrusive changes to > > the Linux kernel and its boot process. > > > > > > III. Approach I. and II. can be combined. The firmware only > > validates the first X MB/GB of guest memory and the rest is > > validated on-demand. > > > > For method II. and III. the guest needs to track which pages have > > already been validated to detect hypervisor attacks. This information > > needs to be carried through the whole boot process. > > > > The need for tracking validity within the guest can be eliminated if: > - the guest has a trusted communication channel with the security > processor (PSP in the SNP case), and > - the security processor has access to the validation state (RMP table for > SNP) > > The guest kernel (linux or non-linux) can then just ask the security processor > for this information when needed, provided the communication ABI exists. > > I am not familiar with TDX specifics, but for SNP [1], I see that the PSP > firmware is able to dump the page validation state along with some other > information into a per-page metadata entry on the SNP_PAGE_SWAP_OUT > ABI call. This leads me to conclude that the PSP has access to the RMP table, > in which case it can probably be made to export the RMP state for a given > guest in a cleaner layout (eg, a guest 'GET_VALIDATION_TABLE' call)? > This is not supported currently in the SNP ABI and I would not recommend this path. The guest to PSP communication is slow and in order for the PSP to gather this information it would have to scan the entire RMP table which can be gigabytes in size. So I don't really see this being workable performance-wise, instead I believe the guest needs to track validation status itself in some way. --David Kaplan
