On Tue, Jul 26, 2022 at 01:17:13PM -0700, Andy Lutomirski wrote:

On Tue, Jun 14, 2022, at 5:02 AM, Kirill A. Shutemov wrote:

quoted

load_unaligned_zeropad() can lead to unwanted loads across page boundaries.
The unwanted loads are typically harmless. But, they might be made to
totally unrelated or even unmapped memory. load_unaligned_zeropad()
relies on exception fixup (#PF, #GP and now #VE) to recover from these
unwanted loads.

But, this approach does not work for unaccepted memory. For TDX, a load
from unaccepted memory will not lead to a recoverable exception within
the guest. The guest will exit to the VMM where the only recourse is to
terminate the guest.

Why is unaccepted memory marked present in the direct map in the first place?

Having kernel code assume that every valid address is followed by
several bytes of memory that may be read without side effects other than
#PF also seems like a mistake, but I probably won’t win that fight. But
sticking guard pages in front of definitely-not-logically present pages
seems silly to me.  Let’s just not map it.

It would mean no 1G pages in direct mapping for TDX as we accept 2M a
time.

(What if MMIO memory is mapped next to regular memory?  Doing random
unaligned reads that cross into MMIO seems unwise.)

MMIO is shared, not unaccpted private. We already handle the situation.
See 1e7769653b06 ("x86/tdx: Handle load_unaligned_zeropad() page-cross to
a shared page").

-- 
  Kiryl Shutsemau / Kirill A. Shutemov