Re: [PATCH v11 04/20] x86/cpu: Detect TDX partial write machine check erratum

[David Hildenbrand <david@redhat.com>]

On 20.06.23 17:39, Dave Hansen wrote:
> On 6/19/23 05:21, David Hildenbrand wrote:
>> So, ordinary writes to TD private memory are not a problem? I thought
>> one motivation for the unmapped-guest-memory discussion was to prevent
>> host (userspace) writes to such memory because it would trigger a MC and
>> eventually crash the host.
> 
> Those are two different problems.
> 
> Problem #1 (this patch): The host encounters poison when going about its
> normal business accessing normal memory.  This happens when something in
> the host accidentally clobbers some TDX memory and *then* reads it.
> Only occurs with partial writes.
> 
> Problem #2 (addressed with unmapping): Host *userspace* intentionally
> and maliciously clobbers some TDX memory and then the TDX module or a
> TDX guest can't run because the memory integrity checks (checksum or TD
> bit) fail.  This can also take the system down because #MC's are nasty.
> 
> Host userspace unmapping doesn't prevent problem #1 because it's the
> kernel who screwed up with the _kernel_ mapping.

Ahh, thanks for verifying. I was hoping that problem #2 would get fixed 
in HW as well (and treated like a BUG).


Because problem #2 also sounds like something that directly violates the 
first paragraph of this patch description "violations of
this integrity protection are supposed to only affect TDX operations and
are never supposed to affect the host kernel itself."

So I would expect the TDX guest to fail hard, but not other TDX guests 
(or the host kernel).

-- 
Cheers,

David / dhildenb