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

[Marc Orr <marcorr@google.com>]

On Mon, Jul 19, 2021 at 10:17 PM Andi Kleen <ak@linux.intel.com> wrote:
>
>
> On 7/19/2021 6:51 PM, Erdem Aktas wrote:
> >
> > > There's one exception to this, which is the previous memory view in
> > > crash kernels. But that's an relatively obscure case and there might be
> > > other solutions for this.
> >
> > I think this is an important angle. It might cause reliability issues.
> > if kexec kernel does not know which page is shared or private, it can
> > use a previously shared page as a code page which will not work. It is
> > also a security concern. Hosts can always cause crashes which forces
> > guests to do kexec for crash dump. If the kexec kernel does not know
> > which pages are validated before, it might be compromised with page
> > replay attacks.
>
> First I suspect for crash it's not a real security problem if a
> malicious hypervisor would inject zeroed pages. That means actual strong
> checks against revalidation/reaccept are not needed. That still leaves
> the issue of triggering an exception when the memory is not there. TDX
> has an option to trigger a #VE in this case, but we will actually force
> disable it to avoid #VE in the system call gap. But the standard crash
> dump tools already know how to parse mem_map to distinguish different
> types of pages. So they already would be able to do that. We just need
> some kind of safety mechanism to prevent any crashes, but that should be
> doable. Actually I'm not sure they're really needed because that's a
> root operation.

I'm not as familiar with TDX as SNP. So I'm not sure that I follow the
exact security threat that Erdem was alluding to. That being said, I
do want to chime in with the following: I think we should not assume
that the guest getting into a certain state is "probably" not a real
security issue. IMHO, we need to be completely certain that guest data
cannot be compromised if we're going to remove the requirement that
guest memory only be validated once in a certain state (e.g., from
within a crash kernel). Perhaps it is the case that we're certain that
guest data cannot be compromised from within a crash kernel -- but
it's not what I read in the email exchange.