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

From: Erdem Aktas <erdemaktas@google.com>
To: Andi Kleen <ak@linux.intel.com>
Cc: Andy Lutomirski <luto@kernel.org>, Joerg Roedel <jroedel@suse.de>,
	 David Rientjes <rientjes@google.com>,
	Borislav Petkov <bp@alien8.de>,
	 Sean Christopherson <seanjc@google.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	 Vlastimil Babka <vbabka@suse.cz>,
	"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
	 Brijesh Singh <brijesh.singh@amd.com>,
	Tom Lendacky <thomas.lendacky@amd.com>,
	 Jon Grimm <jon.grimm@amd.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	 "Peter Zijlstra (Intel)" <peterz@infradead.org>,
	Paolo Bonzini <pbonzini@redhat.com>,
	 Ingo Molnar <mingo@redhat.com>,
	"Kaplan, David" <David.Kaplan@amd.com>,
	 Varad Gautam <varad.gautam@suse.com>,
	Dario Faggioli <dfaggioli@suse.com>,
	 "the arch/x86 maintainers" <x86@kernel.org>,
	linux-mm@kvack.org, linux-coco@lists.linux.dev
Subject: Re: Runtime Memory Validation in Intel-TDX and AMD-SNP
Date: Tue, 20 Jul 2021 16:55:22 -0700	[thread overview]
Message-ID: <CAAYXXYwbt4_FcM1=3PRgiacfdFoztwt53CAukBaW61EyGeecnQ@mail.gmail.com> (raw)
In-Reply-To: <20210720220113.GA535804@tassilo.jf.intel.com>

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 <ak@linux.intel.com> 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