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:
> > 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
