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

[Jue Wang <juew@google.com>]

On Tue, Apr 26, 2022 at 12:36 PM Dave Hansen <dave.hansen@intel.com> 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:
> >> What if you're in a normal (non-TDX) guest and some of the physical
> >> address space has been ballooned away?
> >
> > Accessing to memory that gets ballooned away will cause extra EPT
> > violations and have the memory faulted in on the host side, which is
> > transparent to the guest.
>
> Yeah, but it completely subverts the whole purpose of ballooning.  In
> other words, this is for all intents and purposes also mutually
> exclusive with ballooning.

True. We haven't thought too much about the TDX/SEV-SNP use cases.

For "normal" guests, the operating model is that it's sufficient for
the scanning to happen just on the host side with the ability to
inform / inject without interrupting execution the detected errors in
"real" time via UCNA injection being added to KVM.
>
> >> What does the kernel do when userspace asks it to poke a non-"System
> >> RAM" address?
> >
> > I expect the kernel should reject the request with -EINVAL.
>
> Right.  Only the kernel has the knowledge of what can actually _be_
> scanned.  So, why even bother exposing physical addresses to userspace?
>  Why is exposing the actual physical address any better than exposing a
> cookie?

Then the API needs some re-design, naively I can see it works this way:

init_as_start_page(&cookie);

while(cookie != END_SCAN) {
   ret = ioctl(, SCAN_SIZE, numa_id, &cookie /*input_output*/ );
   /* Handle errors, poison detected etc. */
   ... ...
}
>
> > Just curious, what could be recommendations from Intel's perspective
> > to make proactively poison detection work on TDX / SEV-SNP?
>
> 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.
>
> Going forward, guest memory scanning could be accomplished by allowing
> the VMM to migrate guest pages.  Let's say you want to scan page "A",
> you could move A->B and B->A.  That would certainly touch the page.
> This would need to be implemented in the TDX module.
>
> Or, the TDX module could have a special call to just touch the page.
>
> It would probably also need more work in the TDX module to be able to
> handle machine checks.  I don't think the handling in there is very
> robust today.
>
> It could also be implemented with some new VMM-side ISA which promises
> to touch the physical memory, but doesn't return any data, ignores the
> "TD bit" and doesn't do any integrity checking.
Thanks for the suggestions, Dave.

We will follow up offline with Google colleagues and look to bring
this up to some RAS discussion venue with Intel.