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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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





[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux