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

[Pranjal Shrivastava]

On Fri, May 22, 2026 at 04:01:43PM +0000, Pranjal Shrivastava wrote:
> 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?)

On another thought, I guess we should go ahead with the current policy,
to ensure we preserve the right pages. If an unsealed file is shrunk and
then grown back to its original size before preservation we might have a
problem. We can ignore this comment.

Thanks,
Praan