Re: [RFC] Expose a memory poison detector ioctl to user space.

[Jue Wang <juew@google.com>]

Thanks Erdem and Dave, as a summary:

1. Reading via direct mapping from guest private memory should not
generate #MC and it should result in expected memory error poisoning
behavior (to be confirmed).

2. Reading via direct mapping from SEV-SNP guest private memory does
not generate #MC or #PF.

Per seanjc@google.com:
TDX doesn't support #MC exception injection, but IRQ "injection" via
posted interrupts is supported. Accesses to machine check MSRs will
#VE, i.e. can be emulated by KVM, so CMCI should work fine for TDX
guests.

Proactively scanning for memory error should benefit TDX guests
preventing potential host shutdowns.

It seems the current proposed design can cover TDX & SEV-SNP if the
direct mapping to guest private memory is preserved?

Thanks,
-Jue

On Thu, Apr 28, 2022 at 9:34 AM Dave Hansen <dave.hansen@intel.com> wrote:
>
> On 4/28/22 09:15, Erdem Aktas wrote:
> >> On 4/26/22 12:23, Jue Wang wrote:
> >>> On Tue, Apr 26, 2022 at 11:18 AM Dave Hansen <dave.hansen@intel.com> wrote:
> >> I shouldn't speak for Intel as a whole, but I'll give you my personal
> >> perspective.
> >>
> >> Right now, hosts can't scan TDX private memory, period.  If you wanted
> >> to do scanning, the guest has to do it or you have to kill the guest and
> >> make the memory non-private.
> >
> > Actually, afaiu, the host can read tdx private memory. This should NOT generate
> > #MC due to integrity/TD ownership but return a fixed value of "0"s. I do not
> > know if this will also trigger #MCs due to memory errors.
>
> I think you're right, at least in the normal case where the access is
> performed with the TME KeyID.  "An introductory overview of the Intel
> TDX technology"[1] says:
>
> > The TD-bit associated with the line in memory seeks to
> > detect software or devices attempting to read memory
> > encrypted with private KeyID, using a shared KeyID, to reveal
> > the ciphertext. On such accesses, the MKTME returns a fixed
> > pattern to prevent ciphertext analysis.
>
> I guess, in practice, the read would need to go all the way out to the
> memory controller to get the TD-bit.  But, it's definitely not
> well-defined in the spec.
>
> 1.
> https://www.intel.com/content/www/us/en/developer/articles/technical/intel-trust-domain-extensions.html