Re: [PATCH v13 10/24] gunyah: vm_mgr: Add/remove user memory regions

[Elliot Berman]

On 6/5/2023 7:18 AM, Will Deacon wrote:
> Hi Elliot,
>
> [+Quentin since he's looked at the MMU notifiers]
>
> Sorry for the slow response, I got buried in email during a week away.
>
> On Fri, May 19, 2023 at 10:02:29AM -0700, Elliot Berman wrote:
> > On 5/19/2023 4:59 AM, Will Deacon wrote:
> > > On Tue, May 09, 2023 at 01:47:47PM -0700, Elliot Berman wrote:
> > > > +	ret = account_locked_vm(ghvm->mm, mapping->npages, true);
> > > > +	if (ret)
> > > > +		goto free_mapping;
> > > > +
> > > > +	mapping->pages = kcalloc(mapping->npages, sizeof(*mapping->pages), GFP_KERNEL_ACCOUNT);
> > > > +	if (!mapping->pages) {
> > > > +		ret = -ENOMEM;
> > > > +		mapping->npages = 0; /* update npages for reclaim */
> > > > +		goto unlock_pages;
> > > > +	}
> > > > +
> > > > +	gup_flags = FOLL_LONGTERM;
> > > > +	if (region->flags & GH_MEM_ALLOW_WRITE)
> > > > +		gup_flags |= FOLL_WRITE;
> > > > +
> > > > +	pinned = pin_user_pages_fast(region->userspace_addr, mapping->npages,
> > > > +					gup_flags, mapping->pages);
> > > > +	if (pinned < 0) {
> > > > +		ret = pinned;
> > > > +		goto free_pages;
> > > > +	} else if (pinned != mapping->npages) {
> > > > +		ret = -EFAULT;
> > > > +		mapping->npages = pinned; /* update npages for reclaim */
> > > > +		goto unpin_pages;
> > > > +	}
> > >
> > > Sorry if I missed it, but I still don't see where you reject file mappings
> > > here.
> >
> > Sure, I can reject file mappings. I didn't catch that was the ask previously
> > and thought it was only a comment about behavior of file mappings.
>
> I thought the mention of filesystem corruption was clear enough! It's
> definitely something we shouldn't allow.

I tried preventing file mappings but this breaks memfd used by crosvm. I 
didn't understand the vector you were tracking for filesystem 
corruption. I ran a few basic experiments with real filesystem backed 
memory mappings and didn't observe corruption, but maybe my experiments 
weren't right.

[snip; response to other comments in 
https://lore.kernel.org/all/3bd86221-ee2e-d157-009b-11f6ada98537@xxxxxxxxxxx/]