[AMD Official Use Only]

-----Original Message-----
From: Varad Gautam <redacted>
Sent: Friday, July 23, 2021 6:04 AM
To: Joerg Roedel <redacted>; David Rientjes
[off-list ref]; Borislav Petkov [off-list ref]; Andy Lutomirski
[off-list ref]; Sean Christopherson [off-list ref]; Andrew
Morton [off-list ref]; Vlastimil Babka [off-list ref];
Kirill A. Shutemov [off-list ref]; Andi Kleen
[off-list ref]; Singh, Brijesh [off-list ref]; Lendacky,
Thomas [off-list ref]; Grimm, Jon
[off-list ref]; Thomas Gleixner [off-list ref]; Peter
Zijlstra [off-list ref]; Paolo Bonzini [off-list ref];
Ingo Molnar [off-list ref]; Kaplan, David
[off-list ref]; Dario Faggioli [off-list ref]
Cc: x86@kernel.org; linux-mm@kvack.org; linux-coco@lists.linux.dev
Subject: Re: Runtime Memory Validation in Intel-TDX and AMD-SNP

[CAUTION: External Email]

On 7/19/21 2:58 PM, Joerg Roedel wrote:

quoted

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

==========================================================
====

quoted

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.

quoted

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