Re: AMD SEV-SNP/Intel TDX: validation of memory pages

[Joerg Roedel <jroedel@suse.de>]

Hi,

On Mon, Feb 01, 2021 at 05:51:09PM -0800, David Rientjes wrote:
> I think quite invasive changes are needed for the guest to support lazy
> validation/acceptance to core areas that lots of people on the recipient
> list have strong opinions about.  Some things that come to mind:
> 
>  - Annotations for pages that must be pre-validated in the x86 boot
>    sequence, including IST stacks

The problem is two-fold:

	1. How to pass the information about pre-validated memory
	   through the whole boot process. This includes firmware,
	   boot-loader, Kernel decompressor and the early Linux boot
	   code.

	2. How to keep track of validated memory at systems runtime.

	(I omit the kexec case for now)

For 1. the best option I see is passing this information as part of the
Linux boot protocol:

	- First we should require from the firmware that everything in
	  the memmap which is not marked as E820 Usable is already
	  validated. This includes any memory used by the firmware
	  itself.

	- Then we can pass this information up the boot process by
	  extending struct boot_params. The bootloader can pass which
	  E820 usable memory it validated, same for the kernel
	  decompressor. The text+data (but not bss) of the running
	  kernel image is per definition validated by the decompressor
	  and does not need to be added explicitly to boot_params.

	- Once the running kernel image took over there are multiple
	  choices. The simplest is probably to keep a validation log,
	  but other data structures can work too until the memmap is set
	  up.

The benefit of passing it up via boot_params is that the whole process
does not necessarily rely on EFI. There are some use-cases for SNP and
TDX like lightweight container runtimes with only minimal or even no
firmware.

>  - Proliferation of these annotations throughout any kernel code that can
>    access memory for #VC or #VE
> 
>  - Handling lazy validation of guest memory through the core mm layer,
>    most likely involving a bit in struct page flags to track their status

Yes, I would also prefer tracking the validation info in 'struct page',
once those are set up. We can discuss different options, there is no
strict need for using struct page, it just seems natural to me.

>  - Any need for validating memory that is not backed by struct page that
>    needs to be special-cased

When everything that is not E820 Usable is already validated then this
should be a no-brainer. Shared memory with the HV and MMIO memory is not
guest private anyway, so there should be no issues. Just a page_is_ram()
check in the #VC/#VE handler is needed.

Regards,

	Joerg