Messages in this thread | | | Date | Tue, 9 Aug 2022 14:38:27 +0300 | From | "Kirill A. Shutemov" <> | Subject | Re: [PATCHv7 10/14] x86/mm: Avoid load_unaligned_zeropad() stepping into unaccepted memory |
| |
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
| |