Messages in this thread | | | Date | Thu, 29 Jun 2023 13:22:08 +0200 | Subject | Re: [PATCH v12 04/22] x86/cpu: Detect TDX partial write machine check erratum | From | David Hildenbrand <> |
| |
On 26.06.23 16:12, Kai Huang wrote: > TDX memory has integrity and confidentiality protections. Violations of > this integrity protection are supposed to only affect TDX operations and > are never supposed to affect the host kernel itself. In other words, > the host kernel should never, itself, see machine checks induced by the > TDX integrity hardware. > > Alas, the first few generations of TDX hardware have an erratum. A > partial write to a TDX private memory cacheline will silently "poison" > the line. Subsequent reads will consume the poison and generate a > machine check. According to the TDX hardware spec, neither of these > things should have happened. > > Virtually all kernel memory accesses operations happen in full > cachelines. In practice, writing a "byte" of memory usually reads a 64 > byte cacheline of memory, modifies it, then writes the whole line back. > Those operations do not trigger this problem. > > This problem is triggered by "partial" writes where a write transaction > of less than cacheline lands at the memory controller. The CPU does > these via non-temporal write instructions (like MOVNTI), or through > UC/WC memory mappings. The issue can also be triggered away from the > CPU by devices doing partial writes via DMA. > > With this erratum, there are additional things need to be done. Similar > to other CPU bugs, use a CPU bug bit to indicate this erratum, and > detect this erratum during early boot. Note this bug reflects the > hardware thus it is detected regardless of whether the kernel is built > with TDX support or not. > > Signed-off-by: Kai Huang <kai.huang@intel.com> > Reviewed-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> > ---
Reviewed-by: David Hildenbrand <david@redhat.com>
-- Cheers,
David / dhildenb
| |