| Message ID | 20241206212846.210835-1-lorenzo.stoakes@oracle.com (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | mm: perform all memfd seal checks in a single place | expand |
Hi Lorenzo, On Fri, 6 Dec 2024 21:28:46 +0000 Lorenzo Stoakes <lorenzo.stoakes@oracle.com> wrote: > We no longer actually need to perform these checks in the f_op->mmap() hook > any longer. > > We already moved the operation which clears VM_MAYWRITE on a read-only > mapping of a write-sealed memfd in order to work around the restrictions > imposed by commit 5de195060b2e ("mm: resolve faulty mmap_region() error > path behaviour"). > > There is no reason for us not to simply go ahead and additionally check to > see if any pre-existing seals are in place here rather than defer this to > the f_op->mmap() hook. > > By doing this we remove more logic from shmem_mmap() which doesn't belong > there, as well as doing the same for hugetlbfs_file_mmap(). We also remove > dubious shared logic in mm.h which simply does not belong there either. > > It makes sense to do these checks at the earliest opportunity, we know > these are shmem (or hugetlbfs) mappings whose relevant VMA flags will not > change from the invoking do_mmap() so there is simply no need to wait. > > This also means the implementation of further memfd seal flags can be done > within mm/memfd.c and also have the opportunity to modify VMA flags as > necessary early in the mapping logic. > > Signed-off-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com> > --- > fs/hugetlbfs/inode.c | 5 ---- > include/linux/memfd.h | 22 ++++++++--------- > include/linux/mm.h | 55 ------------------------------------------- > mm/memfd.c | 44 +++++++++++++++++++++++++++++++++- > mm/mmap.c | 12 +++++++--- > mm/shmem.c | 6 ----- > 6 files changed, 62 insertions(+), 82 deletions(-) > [...] > diff --git a/include/linux/memfd.h b/include/linux/memfd.h > index d437e3070850..d53408b0bd31 100644 > --- a/include/linux/memfd.h > +++ b/include/linux/memfd.h > @@ -7,7 +7,14 @@ > #ifdef CONFIG_MEMFD_CREATE > extern long memfd_fcntl(struct file *file, unsigned int cmd, unsigned int arg); > struct folio *memfd_alloc_folio(struct file *memfd, pgoff_t idx); > -unsigned int *memfd_file_seals_ptr(struct file *file); > +/* > + * Check for any existing seals on mmap, return an error if access is denied due > + * to sealing, or 0 otherwise. > + * > + * We also update VMA flags if appropriate by manipulating the VMA flags pointed > + * to by vm_flags_ptr. > + */ > +int memfd_check_seals_mmap(struct file *file, unsigned long *vm_flags_ptr); > #else > static inline long memfd_fcntl(struct file *f, unsigned int c, unsigned int a) > { > @@ -17,19 +24,10 @@ static inline struct folio *memfd_alloc_folio(struct file *memfd, pgoff_t idx) > { > return ERR_PTR(-EINVAL); > } > - > -static inline unsigned int *memfd_file_seals_ptr(struct file *file) > +int memfd_check_seals_mmap(struct file *file, unsigned long *vm_flags) Shouldn't we set this function as 'static inline'? Otherwise, build fails when CONFIG_MEMFD_CREATE is not defined, like below. ld: mm/mmap.o: in function `memfd_check_seals_mmap': mmap.c:(.text+0x...): multiple definition of `memfd_check_seals_mmap'; mm/gup.o:gup.c:(.text+0x...): first defined here ld: mm/secretmem.o: in function `memfd_check_seals_mmap': secretmem.c:(.text+0x...): multiple definition of `memfd_check_seals_mmap'; mm/gup.o:gup.c:(.text+0x...): first defined here Also a trivial nit. The second argument's name (vm_flags) is different from that for CONFIG_MEMFD_CREATE=y (vm_flags_ptr). > { > - return NULL; > + return 0; > } > #endif > > -/* Retrieve memfd seals associated with the file, if any. */ > -static inline unsigned int memfd_file_seals(struct file *file) > -{ > - unsigned int *sealsp = memfd_file_seals_ptr(file); > - > - return sealsp ? *sealsp : 0; > -} > - > #endif /* __LINUX_MEMFD_H */ Thanks, SJ [...]
Hi Lorenzo,
kernel test robot noticed the following build errors:
[auto build test ERROR on akpm-mm/mm-everything]
url: https://github.com/intel-lab-lkp/linux/commits/Lorenzo-Stoakes/mm-perform-all-memfd-seal-checks-in-a-single-place/20241207-053020
base: https://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm.git mm-everything
patch link: https://lore.kernel.org/r/20241206212846.210835-1-lorenzo.stoakes%40oracle.com
patch subject: [PATCH] mm: perform all memfd seal checks in a single place
config: microblaze-allnoconfig (https://download.01.org/0day-ci/archive/20241207/202412070928.cx0iqU0C-lkp@intel.com/config)
compiler: microblaze-linux-gcc (GCC) 14.2.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20241207/202412070928.cx0iqU0C-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202412070928.cx0iqU0C-lkp@intel.com/
All errors (new ones prefixed by >>):
microblaze-linux-ld: mm/mmap.o: in function `memfd_check_seals_mmap':
>> (.text+0x31c): multiple definition of `memfd_check_seals_mmap'; mm/gup.o:(.text+0x1324): first defined here
microblaze-linux-ld: fs/fcntl.o: in function `memfd_check_seals_mmap':
(.text+0x630): multiple definition of `memfd_check_seals_mmap'; mm/gup.o:(.text+0x1324): first defined here
Hi Lorenzo, kernel test robot noticed the following build errors: [auto build test ERROR on akpm-mm/mm-everything] url: https://github.com/intel-lab-lkp/linux/commits/Lorenzo-Stoakes/mm-perform-all-memfd-seal-checks-in-a-single-place/20241207-053020 base: https://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm.git mm-everything patch link: https://lore.kernel.org/r/20241206212846.210835-1-lorenzo.stoakes%40oracle.com patch subject: [PATCH] mm: perform all memfd seal checks in a single place config: x86_64-allnoconfig (https://download.01.org/0day-ci/archive/20241207/202412070908.wNlwD8Sk-lkp@intel.com/config) compiler: clang version 19.1.3 (https://github.com/llvm/llvm-project ab51eccf88f5321e7c60591c5546b254b6afab99) reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20241207/202412070908.wNlwD8Sk-lkp@intel.com/reproduce) If you fix the issue in a separate patch/commit (i.e. not just a new version of the same patch/commit), kindly add following tags | Reported-by: kernel test robot <lkp@intel.com> | Closes: https://lore.kernel.org/oe-kbuild-all/202412070908.wNlwD8Sk-lkp@intel.com/ All errors (new ones prefixed by >>): >> ld.lld: error: duplicate symbol: memfd_check_seals_mmap >>> defined at gup.c >>> mm/gup.o:(memfd_check_seals_mmap) in archive vmlinux.a >>> defined at mmap.c >>> mm/mmap.o:(.text+0x0) in archive vmlinux.a -- >> ld.lld: error: duplicate symbol: memfd_check_seals_mmap >>> defined at gup.c >>> mm/gup.o:(memfd_check_seals_mmap) in archive vmlinux.a >>> defined at secretmem.c >>> mm/secretmem.o:(.text+0x0) in archive vmlinux.a -- >> ld.lld: error: duplicate symbol: memfd_check_seals_mmap >>> defined at gup.c >>> mm/gup.o:(memfd_check_seals_mmap) in archive vmlinux.a >>> defined at fcntl.c >>> fs/fcntl.o:(.text+0x0) in archive vmlinux.a
On Sat, Dec 07, 2024 at 11:22:51AM -0800, SeongJae Park wrote: > Hi Lorenzo, > > On Fri, 6 Dec 2024 21:28:46 +0000 Lorenzo Stoakes <lorenzo.stoakes@oracle.com> wrote: > > > We no longer actually need to perform these checks in the f_op->mmap() hook > > any longer. > > > > We already moved the operation which clears VM_MAYWRITE on a read-only > > mapping of a write-sealed memfd in order to work around the restrictions > > imposed by commit 5de195060b2e ("mm: resolve faulty mmap_region() error > > path behaviour"). > > > > There is no reason for us not to simply go ahead and additionally check to > > see if any pre-existing seals are in place here rather than defer this to > > the f_op->mmap() hook. > > > > By doing this we remove more logic from shmem_mmap() which doesn't belong > > there, as well as doing the same for hugetlbfs_file_mmap(). We also remove > > dubious shared logic in mm.h which simply does not belong there either. > > > > It makes sense to do these checks at the earliest opportunity, we know > > these are shmem (or hugetlbfs) mappings whose relevant VMA flags will not > > change from the invoking do_mmap() so there is simply no need to wait. > > > > This also means the implementation of further memfd seal flags can be done > > within mm/memfd.c and also have the opportunity to modify VMA flags as > > necessary early in the mapping logic. > > > > Signed-off-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com> > > --- > > fs/hugetlbfs/inode.c | 5 ---- > > include/linux/memfd.h | 22 ++++++++--------- > > include/linux/mm.h | 55 ------------------------------------------- > > mm/memfd.c | 44 +++++++++++++++++++++++++++++++++- > > mm/mmap.c | 12 +++++++--- > > mm/shmem.c | 6 ----- > > 6 files changed, 62 insertions(+), 82 deletions(-) > > > [...] > > diff --git a/include/linux/memfd.h b/include/linux/memfd.h > > index d437e3070850..d53408b0bd31 100644 > > --- a/include/linux/memfd.h > > +++ b/include/linux/memfd.h > > @@ -7,7 +7,14 @@ > > #ifdef CONFIG_MEMFD_CREATE > > extern long memfd_fcntl(struct file *file, unsigned int cmd, unsigned int arg); > > struct folio *memfd_alloc_folio(struct file *memfd, pgoff_t idx); > > -unsigned int *memfd_file_seals_ptr(struct file *file); > > +/* > > + * Check for any existing seals on mmap, return an error if access is denied due > > + * to sealing, or 0 otherwise. > > + * > > + * We also update VMA flags if appropriate by manipulating the VMA flags pointed > > + * to by vm_flags_ptr. > > + */ > > +int memfd_check_seals_mmap(struct file *file, unsigned long *vm_flags_ptr); > > #else > > static inline long memfd_fcntl(struct file *f, unsigned int c, unsigned int a) > > { > > @@ -17,19 +24,10 @@ static inline struct folio *memfd_alloc_folio(struct file *memfd, pgoff_t idx) > > { > > return ERR_PTR(-EINVAL); > > } > > - > > -static inline unsigned int *memfd_file_seals_ptr(struct file *file) > > +int memfd_check_seals_mmap(struct file *file, unsigned long *vm_flags) > > Shouldn't we set this function as 'static inline'? Otherwise, build fails when > CONFIG_MEMFD_CREATE is not defined, like below. Yep thanks, I typo'd this, will send a fix-patch. > > ld: mm/mmap.o: in function `memfd_check_seals_mmap': > mmap.c:(.text+0x...): multiple definition of `memfd_check_seals_mmap'; mm/gup.o:gup.c:(.text+0x...): first defined here > ld: mm/secretmem.o: in function `memfd_check_seals_mmap': > secretmem.c:(.text+0x...): multiple definition of `memfd_check_seals_mmap'; mm/gup.o:gup.c:(.text+0x...): first defined here > > Also a trivial nit. The second argument's name (vm_flags) is different from > that for CONFIG_MEMFD_CREATE=y (vm_flags_ptr). > > > { > > - return NULL; > > + return 0; > > } > > #endif > > > > -/* Retrieve memfd seals associated with the file, if any. */ > > -static inline unsigned int memfd_file_seals(struct file *file) > > -{ > > - unsigned int *sealsp = memfd_file_seals_ptr(file); > > - > > - return sealsp ? *sealsp : 0; > > -} > > - > > #endif /* __LINUX_MEMFD_H */ > > > Thanks, > SJ > > [...]
On Mon, Dec 09, 2024 at 11:59:22AM +0800, kernel test robot wrote: > Hi Lorenzo, > > kernel test robot noticed the following build errors: Thanks for the report, I did a silly typo for which I'll send a fix-patch. > > [auto build test ERROR on akpm-mm/mm-everything] > > url: https://github.com/intel-lab-lkp/linux/commits/Lorenzo-Stoakes/mm-perform-all-memfd-seal-checks-in-a-single-place/20241207-053020 > base: https://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm.git mm-everything > patch link: https://lore.kernel.org/r/20241206212846.210835-1-lorenzo.stoakes%40oracle.com > patch subject: [PATCH] mm: perform all memfd seal checks in a single place > config: x86_64-allnoconfig (https://download.01.org/0day-ci/archive/20241207/202412070908.wNlwD8Sk-lkp@intel.com/config) > compiler: clang version 19.1.3 (https://github.com/llvm/llvm-project ab51eccf88f5321e7c60591c5546b254b6afab99) > reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20241207/202412070908.wNlwD8Sk-lkp@intel.com/reproduce) > > If you fix the issue in a separate patch/commit (i.e. not just a new version of > the same patch/commit), kindly add following tags > | Reported-by: kernel test robot <lkp@intel.com> > | Closes: https://lore.kernel.org/oe-kbuild-all/202412070908.wNlwD8Sk-lkp@intel.com/ > > All errors (new ones prefixed by >>): > > >> ld.lld: error: duplicate symbol: memfd_check_seals_mmap > >>> defined at gup.c > >>> mm/gup.o:(memfd_check_seals_mmap) in archive vmlinux.a > >>> defined at mmap.c > >>> mm/mmap.o:(.text+0x0) in archive vmlinux.a > -- > >> ld.lld: error: duplicate symbol: memfd_check_seals_mmap > >>> defined at gup.c > >>> mm/gup.o:(memfd_check_seals_mmap) in archive vmlinux.a > >>> defined at secretmem.c > >>> mm/secretmem.o:(.text+0x0) in archive vmlinux.a > -- > >> ld.lld: error: duplicate symbol: memfd_check_seals_mmap > >>> defined at gup.c > >>> mm/gup.o:(memfd_check_seals_mmap) in archive vmlinux.a > >>> defined at fcntl.c > >>> fs/fcntl.o:(.text+0x0) in archive vmlinux.a > > -- > 0-DAY CI Kernel Test Service > https://github.com/intel/lkp-tests/wiki
On Fri, Dec 06, 2024 at 09:28:46PM +0000, Lorenzo Stoakes wrote: > We no longer actually need to perform these checks in the f_op->mmap() hook > any longer. > > We already moved the operation which clears VM_MAYWRITE on a read-only > mapping of a write-sealed memfd in order to work around the restrictions > imposed by commit 5de195060b2e ("mm: resolve faulty mmap_region() error > path behaviour"). > > There is no reason for us not to simply go ahead and additionally check to > see if any pre-existing seals are in place here rather than defer this to > the f_op->mmap() hook. > > By doing this we remove more logic from shmem_mmap() which doesn't belong > there, as well as doing the same for hugetlbfs_file_mmap(). We also remove > dubious shared logic in mm.h which simply does not belong there either. > > It makes sense to do these checks at the earliest opportunity, we know > these are shmem (or hugetlbfs) mappings whose relevant VMA flags will not > change from the invoking do_mmap() so there is simply no need to wait. > > This also means the implementation of further memfd seal flags can be done > within mm/memfd.c and also have the opportunity to modify VMA flags as > necessary early in the mapping logic. > > Signed-off-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com> Hi Andrew, I made a rather silly typo in this patch which resulted in me failing to mark a static inline as such and therefore, the build bots got very cross with me :) Apologies to all for the noise! Could you apply the enclosed fix-patch to resolve this? Thanks, Lorenzo ----8<---- From 6cfef80e2ea5154302ba9b1925acd8e77ea6cd18 Mon Sep 17 00:00:00 2001 From: Lorenzo Stoakes <lorenzo.stoakes@oracle.com> Date: Mon, 9 Dec 2024 11:04:08 +0000 Subject: [PATCH] mm: fix typos in !memfd inline stub I typo'd the declaration of memfd_check_seals_mmap() in the case where CONFIG_MEMFD_CREATE is not defined, resulting in build failures. Fix this, and correct the misspelling of vm_flags which should be vm_flags_ptr at the same time. Signed-off-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com> --- include/linux/memfd.h | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/include/linux/memfd.h b/include/linux/memfd.h index d53408b0bd31..246daadbfde8 100644 --- a/include/linux/memfd.h +++ b/include/linux/memfd.h @@ -24,7 +24,8 @@ static inline struct folio *memfd_alloc_folio(struct file *memfd, pgoff_t idx) { return ERR_PTR(-EINVAL); } -int memfd_check_seals_mmap(struct file *file, unsigned long *vm_flags) +static inline int memfd_check_seals_mmap(struct file *file, + unsigned long *vm_flags_ptr) { return 0; } -- 2.47.1
On Mon, Dec 09, 2024 at 11:13:14AM +0000, Lorenzo Stoakes wrote: > On Fri, Dec 06, 2024 at 09:28:46PM +0000, Lorenzo Stoakes wrote: > > We no longer actually need to perform these checks in the f_op->mmap() hook > > any longer. > > > > We already moved the operation which clears VM_MAYWRITE on a read-only > > mapping of a write-sealed memfd in order to work around the restrictions > > imposed by commit 5de195060b2e ("mm: resolve faulty mmap_region() error > > path behaviour"). > > > > There is no reason for us not to simply go ahead and additionally check to > > see if any pre-existing seals are in place here rather than defer this to > > the f_op->mmap() hook. > > > > By doing this we remove more logic from shmem_mmap() which doesn't belong > > there, as well as doing the same for hugetlbfs_file_mmap(). We also remove > > dubious shared logic in mm.h which simply does not belong there either. > > > > It makes sense to do these checks at the earliest opportunity, we know > > these are shmem (or hugetlbfs) mappings whose relevant VMA flags will not > > change from the invoking do_mmap() so there is simply no need to wait. > > > > This also means the implementation of further memfd seal flags can be done > > within mm/memfd.c and also have the opportunity to modify VMA flags as > > necessary early in the mapping logic. > > > > Signed-off-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com> > ----8<---- > From 6cfef80e2ea5154302ba9b1925acd8e77ea6cd18 Mon Sep 17 00:00:00 2001 > From: Lorenzo Stoakes <lorenzo.stoakes@oracle.com> > Date: Mon, 9 Dec 2024 11:04:08 +0000 > Subject: [PATCH] mm: fix typos in !memfd inline stub > > I typo'd the declaration of memfd_check_seals_mmap() in the case where > CONFIG_MEMFD_CREATE is not defined, resulting in build failures. > > Fix this, and correct the misspelling of vm_flags which should be > vm_flags_ptr at the same time. > > Signed-off-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com> > --- > include/linux/memfd.h | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/include/linux/memfd.h b/include/linux/memfd.h > index d53408b0bd31..246daadbfde8 100644 > --- a/include/linux/memfd.h > +++ b/include/linux/memfd.h > @@ -24,7 +24,8 @@ static inline struct folio *memfd_alloc_folio(struct file *memfd, pgoff_t idx) > { > return ERR_PTR(-EINVAL); > } > -int memfd_check_seals_mmap(struct file *file, unsigned long *vm_flags) > +static inline int memfd_check_seals_mmap(struct file *file, > + unsigned long *vm_flags_ptr) > { > return 0; > } > -- > 2.47.1 Thanks for sending this out so quickly! I think this came out nicely, and makes the memfd sealing code easier to comprehend :). I applied both the patch that moves the memfd seal checks to one place and the fix up patch, and tested it out on my Pixel 6 device. The device boots, and I do not see any errors related to memfd. Please feel free to add my tested-by tag to the patch: Tested-by: Isaac J. Manjarres <isaacmanjarres@google.com> Thanks, Isaac
diff --git a/fs/hugetlbfs/inode.c b/fs/hugetlbfs/inode.c index a5ea006f403e..d8f852b52c56 100644 --- a/fs/hugetlbfs/inode.c +++ b/fs/hugetlbfs/inode.c @@ -99,7 +99,6 @@ static const struct fs_parameter_spec hugetlb_fs_parameters[] = { static int hugetlbfs_file_mmap(struct file *file, struct vm_area_struct *vma) { struct inode *inode = file_inode(file); - struct hugetlbfs_inode_info *info = HUGETLBFS_I(inode); loff_t len, vma_len; int ret; struct hstate *h = hstate_file(file); @@ -116,10 +115,6 @@ static int hugetlbfs_file_mmap(struct file *file, struct vm_area_struct *vma) vm_flags_set(vma, VM_HUGETLB | VM_DONTEXPAND | VM_MTE_ALLOWED); vma->vm_ops = &hugetlb_vm_ops; - ret = seal_check_write(info->seals, vma); - if (ret) - return ret; - /* * page based offset in vm_pgoff could be sufficiently large to * overflow a loff_t when converted to byte offset. This can diff --git a/include/linux/memfd.h b/include/linux/memfd.h index d437e3070850..d53408b0bd31 100644 --- a/include/linux/memfd.h +++ b/include/linux/memfd.h @@ -7,7 +7,14 @@ #ifdef CONFIG_MEMFD_CREATE extern long memfd_fcntl(struct file *file, unsigned int cmd, unsigned int arg); struct folio *memfd_alloc_folio(struct file *memfd, pgoff_t idx); -unsigned int *memfd_file_seals_ptr(struct file *file); +/* + * Check for any existing seals on mmap, return an error if access is denied due + * to sealing, or 0 otherwise. + * + * We also update VMA flags if appropriate by manipulating the VMA flags pointed + * to by vm_flags_ptr. + */ +int memfd_check_seals_mmap(struct file *file, unsigned long *vm_flags_ptr); #else static inline long memfd_fcntl(struct file *f, unsigned int c, unsigned int a) { @@ -17,19 +24,10 @@ static inline struct folio *memfd_alloc_folio(struct file *memfd, pgoff_t idx) { return ERR_PTR(-EINVAL); } - -static inline unsigned int *memfd_file_seals_ptr(struct file *file) +int memfd_check_seals_mmap(struct file *file, unsigned long *vm_flags) { - return NULL; + return 0; } #endif -/* Retrieve memfd seals associated with the file, if any. */ -static inline unsigned int memfd_file_seals(struct file *file) -{ - unsigned int *sealsp = memfd_file_seals_ptr(file); - - return sealsp ? *sealsp : 0; -} - #endif /* __LINUX_MEMFD_H */ diff --git a/include/linux/mm.h b/include/linux/mm.h index cd2b33157d5b..d642f637cef8 100644 --- a/include/linux/mm.h +++ b/include/linux/mm.h @@ -4091,61 +4091,6 @@ void mem_dump_obj(void *object); static inline void mem_dump_obj(void *object) {} #endif -static inline bool is_write_sealed(int seals) -{ - return seals & (F_SEAL_WRITE | F_SEAL_FUTURE_WRITE); -} - -/** - * is_readonly_sealed - Checks whether write-sealed but mapped read-only, - * in which case writes should be disallowing moving - * forwards. - * @seals: the seals to check - * @vm_flags: the VMA flags to check - * - * Returns whether readonly sealed, in which case writess should be disallowed - * going forward. - */ -static inline bool is_readonly_sealed(int seals, vm_flags_t vm_flags) -{ - /* - * Since an F_SEAL_[FUTURE_]WRITE sealed memfd can be mapped as - * MAP_SHARED and read-only, take care to not allow mprotect to - * revert protections on such mappings. Do this only for shared - * mappings. For private mappings, don't need to mask - * VM_MAYWRITE as we still want them to be COW-writable. - */ - if (is_write_sealed(seals) && - ((vm_flags & (VM_SHARED | VM_WRITE)) == VM_SHARED)) - return true; - - return false; -} - -/** - * seal_check_write - Check for F_SEAL_WRITE or F_SEAL_FUTURE_WRITE flags and - * handle them. - * @seals: the seals to check - * @vma: the vma to operate on - * - * Check whether F_SEAL_WRITE or F_SEAL_FUTURE_WRITE are set; if so, do proper - * check/handling on the vma flags. Return 0 if check pass, or <0 for errors. - */ -static inline int seal_check_write(int seals, struct vm_area_struct *vma) -{ - if (!is_write_sealed(seals)) - return 0; - - /* - * New PROT_WRITE and MAP_SHARED mmaps are not allowed when - * write seals are active. - */ - if ((vma->vm_flags & VM_SHARED) && (vma->vm_flags & VM_WRITE)) - return -EPERM; - - return 0; -} - #ifdef CONFIG_ANON_VMA_NAME int madvise_set_anon_name(struct mm_struct *mm, unsigned long start, unsigned long len_in, diff --git a/mm/memfd.c b/mm/memfd.c index 35a370d75c9a..5f5a23c9051d 100644 --- a/mm/memfd.c +++ b/mm/memfd.c @@ -170,7 +170,7 @@ static int memfd_wait_for_pins(struct address_space *mapping) return error; } -unsigned int *memfd_file_seals_ptr(struct file *file) +static unsigned int *memfd_file_seals_ptr(struct file *file) { if (shmem_file(file)) return &SHMEM_I(file_inode(file))->seals; @@ -327,6 +327,48 @@ static int check_sysctl_memfd_noexec(unsigned int *flags) return 0; } +static inline bool is_write_sealed(unsigned int seals) +{ + return seals & (F_SEAL_WRITE | F_SEAL_FUTURE_WRITE); +} + +static int check_write_seal(unsigned long *vm_flags_ptr) +{ + unsigned long vm_flags = *vm_flags_ptr; + unsigned long mask = vm_flags & (VM_SHARED | VM_WRITE); + + /* If a private matting then writability is irrelevant. */ + if (!(mask & VM_SHARED)) + return 0; + + /* + * New PROT_WRITE and MAP_SHARED mmaps are not allowed when + * write seals are active. + */ + if (mask & VM_WRITE) + return -EPERM; + + /* + * This is a read-only mapping, disallow mprotect() from making a + * write-sealed mapping writable in future. + */ + *vm_flags_ptr &= ~VM_MAYWRITE; + + return 0; +} + +int memfd_check_seals_mmap(struct file *file, unsigned long *vm_flags_ptr) +{ + int err = 0; + unsigned int *seals_ptr = memfd_file_seals_ptr(file); + unsigned int seals = seals_ptr ? *seals_ptr : 0; + + if (is_write_sealed(seals)) + err = check_write_seal(vm_flags_ptr); + + return err; +} + SYSCALL_DEFINE2(memfd_create, const char __user *, uname, unsigned int, flags) diff --git a/mm/mmap.c b/mm/mmap.c index 1c6bdffa13dd..902fe4266448 100644 --- a/mm/mmap.c +++ b/mm/mmap.c @@ -368,8 +368,8 @@ unsigned long do_mmap(struct file *file, unsigned long addr, if (file) { struct inode *inode = file_inode(file); - unsigned int seals = memfd_file_seals(file); unsigned long flags_mask; + int err; if (!file_mmap_ok(file, inode, pgoff, len)) return -EOVERFLOW; @@ -409,8 +409,6 @@ unsigned long do_mmap(struct file *file, unsigned long addr, vm_flags |= VM_SHARED | VM_MAYSHARE; if (!(file->f_mode & FMODE_WRITE)) vm_flags &= ~(VM_MAYWRITE | VM_SHARED); - else if (is_readonly_sealed(seals, vm_flags)) - vm_flags &= ~VM_MAYWRITE; fallthrough; case MAP_PRIVATE: if (!(file->f_mode & FMODE_READ)) @@ -430,6 +428,14 @@ unsigned long do_mmap(struct file *file, unsigned long addr, default: return -EINVAL; } + + /* + * Check to see if we are violating any seals and update VMA + * flags if necessary to avoid future seal violations. + */ + err = memfd_check_seals_mmap(file, &vm_flags); + if (err) + return (unsigned long)err; } else { switch (flags & MAP_TYPE) { case MAP_SHARED: diff --git a/mm/shmem.c b/mm/shmem.c index f4e9c94ed8ae..41d7a181ed89 100644 --- a/mm/shmem.c +++ b/mm/shmem.c @@ -2815,12 +2815,6 @@ int shmem_lock(struct file *file, int lock, struct ucounts *ucounts) static int shmem_mmap(struct file *file, struct vm_area_struct *vma) { struct inode *inode = file_inode(file); - struct shmem_inode_info *info = SHMEM_I(inode); - int ret; - - ret = seal_check_write(info->seals, vma); - if (ret) - return ret; file_accessed(file); /* This is anonymous shared memory if it is unlinked at the time of mmap */
We no longer actually need to perform these checks in the f_op->mmap() hook any longer. We already moved the operation which clears VM_MAYWRITE on a read-only mapping of a write-sealed memfd in order to work around the restrictions imposed by commit 5de195060b2e ("mm: resolve faulty mmap_region() error path behaviour"). There is no reason for us not to simply go ahead and additionally check to see if any pre-existing seals are in place here rather than defer this to the f_op->mmap() hook. By doing this we remove more logic from shmem_mmap() which doesn't belong there, as well as doing the same for hugetlbfs_file_mmap(). We also remove dubious shared logic in mm.h which simply does not belong there either. It makes sense to do these checks at the earliest opportunity, we know these are shmem (or hugetlbfs) mappings whose relevant VMA flags will not change from the invoking do_mmap() so there is simply no need to wait. This also means the implementation of further memfd seal flags can be done within mm/memfd.c and also have the opportunity to modify VMA flags as necessary early in the mapping logic. Signed-off-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com> --- fs/hugetlbfs/inode.c | 5 ---- include/linux/memfd.h | 22 ++++++++--------- include/linux/mm.h | 55 ------------------------------------------- mm/memfd.c | 44 +++++++++++++++++++++++++++++++++- mm/mmap.c | 12 +++++++--- mm/shmem.c | 6 ----- 6 files changed, 62 insertions(+), 82 deletions(-)