Re: Runtime Memory Validation in Intel-TDX and AMD-SNP

[Joerg Roedel <jroedel@suse.de>]

On Mon, Jul 19, 2021 at 10:17:36PM -0700, Andi Kleen wrote:
> For non crash kexec it's fine to reaccept/validate memory because we don't
> care about the old contents anymore, except for the kernel itself and
> perhaps your stack/page tables. So something very simple is enough for that
> too.

I am not sure how it is implemented in TDX hardware, but for SNP the
guest _must_ _not_ double-validate or even double-invalidate memory.

What I sent here is actually v2 of my proposal, v1 had a much more lazy
approach like you are proposing here. But as I learned what can happen
is this:

	* Hypervisor maps GPA X to HPA A
	* Guest validates GPA X
	  Hardware enforces that HPA A always maps to GPA X
	* Hypervisor remaps GPA X to HPA B
	* Guest lazily re-validates GPA X
	  Hardware enforces that HPA B always maps to GPA X
	
The situation we have now is that host pages A and B are validated for
the same guest page, and the hypervisor can switch between them at will,
without the guest being able to notice it.

This can open various attack vectors from the hypervisor towards the
guest, like tricking the guest into a code-path where it accidentially
reveals its secrets.

For that reason the guest needs to know at any time whether a given page
has already been validated/accepted. And the guest needs to pass along
this fine-grained information even in the case of kexec/kdump.

> If the device filter is active it won't.

We are not going to pohibit dma_alloc_coherent() in SNP guests just
because we are too lazy to implement memory re-validation.

Regards,

	Joerg