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

[Erdem Aktas <erdemaktas@google.com>]

On Mon, Jul 19, 2021 at 8:30 PM Andy Lutomirski <luto@kernel.org> wrote:
> What’s the attack you have in mind?  With TDX, the guest using the wrong shared vs secure type should, at worst, cause > crashes.  With SEV, I can imagine it’s possible for a guest to read or write the ciphertext of a private page, but actually
> turning that into an attack seems like it would require convincing a guest to use the same page with both modes.

There are a couple of things that can go wrong (maybe more):

Imagine Guest set a page shared. It is assumed that the host should
remove the SEPT entry but it does not have to, so that entry might
stay there with a valid bit set.

Guest should accept a page before it accesses it the first time or
guest can accept a page as part of #VE handler when a PENDING page is
accessed.

Current guest patch series (v3) from intel does not have any #VE
handler to accept pages on the fly. It seems like it has an assumption
that all the pages are accepted by UEFI (I have not reviewed the code
yet in detail).

Now let's say the kernel wants to access a page for the first time, or
after a kexec it wants to make sure all the pages are private. it
needs to call tdx_hcall_gpa_intent or  tdg_accept_page individually.
If the page is already accepted, tdg_accept_page does not return any
error in the current implementation in v3. Depending on how this page
is being used, it's content is now "not zeroed" as opposed to what it
is being expected. Converting this to an attack is not trivial but
possible.

I did not see any #VE implementation to handle SEPT violations when a
page is in PENDING state. I am assuming that this needs to be
supported at some point (If not then we need to discuss the use cases
for such support).

In such an implementation, hypervisor can inject a zeroed page
anytime. This seems like a not big deal but IMO it is and it can be
used as an attack vector to change conditions, masking variables etc.

> >> At the risk of asking a potentially silly question, would it be
> >> reasonable to treat non-validated memory as not-present for kernel
> >> purposes and hot-add it in a thread as it gets validated?
>
> My concern with this is, it assumes that all the present memory is private. UEFI might have some pages which are shared therefore also are present.
>
>
> Why is this a problem?  In TDX, I don’t think shared pages need any sort of validation. The private memory needs acceptance, but only DoS should be possible by getting it wrong. If EFI passed in a messy map with shared and private transitions all over, there will be a lot of extents in the map, but what actually goes wrong?

I mean if the only attack vector is DoS (which is not part of the
threat model that TDX is addressing), then why do we even need
tdaccept? I thought we need tdaccept to prevent VMM to change the
content of a page without guest knowing it.
My comment was about if we assume all non-validated memory as
not-present, how we were going to handle the shared pages transferred
from UEFI to kernel. Those are not validated but the range is present.
How can the guest kernel read those shared pages if it does not know
that they need to be mapped as shared in the first place.

Depending on how the guest kernel is handling shared to private page
conversion or how it is initializing the private pages for the first
time, a lot of things can go wrong but I need to look at the code to
provide more concrete examples.

-Erdem