Re: [PATCH v9 1/8] mm: Introduce memfd_restricted system call to create restricted user memory

Kirill A. Shutemov
2022-11-03T16:30:31Z

On Wed, Nov 02, 2022 at 05:07:00PM -0500, Michael Roth wrote:
> On Thu, Nov 03, 2022 at 12:14:04AM +0300, Kirill A. Shutemov wrote:
> > On Mon, Oct 31, 2022 at 12:47:38PM -0500, Michael Roth wrote:
> > >
> > > In v8 there was some discussion about potentially passing the page/folio
> > > and order as part of the invalidation callback, I ended up needing
> > > something similar for SEV-SNP, and think it might make sense for other
> > > platforms. This main reasoning is:
> > >
> > > 1) restoring kernel directmap:
> > >
> > > Currently SNP (and I believe TDX) need to either split or remove kernel
> > > direct mappings for restricted PFNs, since there is no guarantee that
> > > other PFNs within a 2MB range won't be used for non-restricted
> > > (which will cause an RMP #PF in the case of SNP since the 2MB
> > > mapping overlaps with guest-owned pages)
> >
> > That's news to me. Where the restriction for SNP comes from?
>
> Sorry, missed your first question.
>
> For SNP at least, the restriction is documented in APM Volume 2, Section
> 15.36.10, First row of Table 15-36 (preceeding paragraph has more
> context). I forgot to mention this is only pertaining to writes by the
> host to 2MB pages that contain guest-owned subpages, for reads it's
> not an issue, but I think the implementation requirements end up being
> the same either way:
>
> https://www.amd.com/system/files/TechDocs/24593.pdf

Looks like you wanted restricted memfd to be backed by secretmem rather
then normal memfd. It would help preserve directmap.

--
Kiryl Shutsemau / Kirill A. Shutemov