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

Thank you so much for your answer and sorry for keeping the discussion long.

On Tue, Jul 20, 2021 at 3:01 PM Andi Kleen [off-list ref] wrote:

You mean when the TDVF is changed? In this case the unaccepted memory
will be a different memory type, so not lazy accept enabled kernels wouldn't
use it.

Thanks Andi for the clarification. I also saw the Kirill's answer. It
makes sense.

But for the kexec crash case it would be just attacks against the crash
dump, which I assume are not a real security concern.

If the crash kernel is compromised, it can be used to dump the
customer memory content  to a shared location which is a real security
concern, is it not?

The crash kexec
mostly runs in its own memory, which doesn't need this, or is small
enough that it can be fully pre-accepted. And for the previous memory
view probably these issues are acceptable.

I think this is where I am getting confused. I agree that we can copy
the crashkernel to its own memory (all accepted) and run it. My
confusion is: crash kernel will dump the memory which might have some
shared pages between. we have 3 options:
1- We can either accept all the pages again, that includes the shared
pages and lose the content of it. If we do not care about the content
in shared pages, then this is okay.
2- Have a mechanism to transfer the private/shared page mapping and
map all the pages accordingly before dumping.
3- Have a #VE handler and to accept the pages on the flight or
identify if it is a shared page based on EPT-violation #VE
information.

I am not sure what crash kernel can do when it accesses a previously
shared page (no SEPT entry) as private with the lack of one of the
above options or similar one.

We actually plan to disable those #VEs, to avoid any problems with
the system call gap. Instead the plan is that the kernel will know
in advance what memory has been accepted or not, and accept it before
touching.

Make sense. Thanks Andi.

-Erdem