Re: [PATCH v2 13/16] iommufd: Persist iommu hardware pagetables for live update

[Pranjal Shrivastava <praan@google.com>]

On Wed, May 20, 2026 at 07:40:05PM +0000, Samiullah Khawaja wrote:
> On Wed, May 20, 2026 at 12:00:44AM +0000, Pranjal Shrivastava wrote:
> > On Mon, Apr 27, 2026 at 05:56:30PM +0000, Samiullah Khawaja wrote:
[...]

> > >  #include "double_span.h"
> > > @@ -1421,6 +1422,7 @@ struct iopt_pages *iopt_alloc_file_pages(struct file *file,
> > > 
> > >  {
> > >  	struct iopt_pages *pages;
> > > +	int seals;
> > > 
> > >  	pages = iopt_alloc_pages(start_byte, length, writable);
> > >  	if (IS_ERR(pages))
> > > @@ -1428,6 +1430,11 @@ struct iopt_pages *iopt_alloc_file_pages(struct file *file,
> > >  	pages->file = get_file(file);
> > >  	pages->start = start - start_byte;
> > >  	pages->type = IOPT_ADDRESS_FILE;
> > > +
> > > +	seals = memfd_get_seals(file);
> > > +	if (seals > 0)
> > > +		pages->seals = seals;
> > > +
> > 
> > Can caching memfd seals create a TOCTOU issue?
> > IIUC, iopt_alloc_file_pages happens at map time, However, the userspace
> > is allowed to map a memfd and then apply the F_ADD_SEALS via fcntl()
> > later in its setup sequence? For example a sequence like:
> > 
> > 1. VMM creates a memfd. It has 0 seals.
> > 2. VMM calls IOMMU_IOAS_MAP_FILE. IOMMUFD caches pages->seals = 0.
> > 3. VMM finishes its setup and calls:
> >   fcntl(fd, F_ADD_SEALS, F_SEAL_GROW | F_SEAL_SHRINK | F_SEAL_SEAL).
> > 
> > 4.VMM initiates Live Update.
> > 5.check_iopt_pages_preserved looks at the cached pages->seals
> >  (which is still 0), sees the seals are missing, & kills the LiveUpdate
> >  with -EINVAL, even though the file is properly sealed..
> 
> This is true and it is intentionally this way to make sure that the seal
> is applied during mapping otherwise user can apply the seal after
> resizing the memfd and preserve IOMMU mappings that are pointing to
> unpreserved pages. Consider following:
> 
> 1. VMM creates a memfd and seals is zero.
> 2. VMM maps memfd into ioas/hwpt.
> 3. VMM resizes the memfd.
> 4. VMM seals memfd
> 5. VMM preserves the memfd (it only preseves the current size).
> 6. VMM preserves iommufd and it succeeds as memfd is sealed.
> 
> But the pages being referred by the iommu mappings are refcounted in
> current kernel, but not preserved.
> 
> Check the comment in check_iopt_pages_preserved() also. I will add a
> comment here also.
> > 

I understand the intent to enforce a policy to Seal-at-Map to ensure
consistency. I am wondering if this policy is a little too restrictive. 
Should we consider performing a dynamic i_size check during preservation
instead? I can't think of a good use-case as of now.. (maybe let it be?)

However, if we decide to keep the current policy, we should probably 
check for the required seals during the IOMMU_IOAS_MAP_FILE ioctl itself. 
If the seals aren't present, we could pr_warn("Don't expect liveupdate 
preservation for this memory, bad seals") to let the user know that this 
specific mapping will be ineligible for Live Update preservation later. 

Thanks,
Praan