On Mon, Apr 03, 2023 at 03:28:36PM +0200, Vlastimil Babka wrote: > On 3/30/23 13:49, 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. > > > > There are three parts to fix this issue and comprehensively avoid access > > to unaccepted memory. Together these ensure that an extra "guard" page > > is accepted in addition to the memory that needs to be used. > > > > 1. Implicitly extend the range_contains_unaccepted_memory(start, end) > > checks up to end+2M if 'end' is aligned on a 2M boundary. It may > > require checking 2M chunk beyond end of RAM. The bitmap allocation is > > modified to accommodate this. > > 2. Implicitly extend accept_memory(start, end) to end+2M if 'end' is > > aligned on a 2M boundary. > > 3. Set PageUnaccepted() on both memory that itself needs to be accepted > > *and* memory where the next page needs to be accepted. Essentially, > > make PageUnaccepted(page) a marker for whether work needs to be done > > to make 'page' usable. That work might include accepting pages in > > addition to 'page' itself. > > > > Side note: This leads to something strange. Pages which were accepted > > at boot, marked by the firmware as accepted and will never > > _need_ to be accepted might have PageUnaccepted() set on > > them. PageUnaccepted(page) is a cue to ensure that the next > > page is accepted before 'page' can be used. > > At least the part about PageUnaccepted() is obsolete in v9, no? Ah, right. Nice catch. I removed PageUnaccepted() late in patchset preparation and forgot about this. -- Kiryl Shutsemau / Kirill A. Shutemov
