From: David Hildenbrand <hidden> Date: 2021-08-16 19:49:16
This series removes all in-tree usage of MAP_DENYWRITE from the kernel
and removes VM_DENYWRITE. We stopped supporting MAP_DENYWRITE for
user space applications a while ago because of the chance for DoS.
The last renaming user is binfmt binary loading during exec and
legacy library loading via uselib().
With this change, MAP_DENYWRITE is effectively ignored throughout the
kernel. Although the net change is small (well, we actually add code and
comments), I think the cleanup in mmap() is quite nice.
There are some (minor) user-visible changes with this series:
1. We no longer deny write access to shared libaries loaded via legacy
uselib(); this behavior matches modern user space e.g., via dlopen().
2. We no longer deny write access to the elf interpreter after exec
completed, treating it just like shared libraries (which it often is).
3. We always deny write access to the file linked via /proc/pid/exe:
sys_prctl(PR_SET_MM_MAP/EXE_FILE) will fail if write access to the file
cannot be denied, and write access to the file will remain denied
until the link is effectivel gone (exec, termination,
sys_prctl(PR_SET_MM_MAP/EXE_FILE)) -- just as if exec'ing the file.
There is a related problem [2] with overlayfs, that should at least partly
be tackled by this series. I don't quite understand the interaction of
overlayfs and deny_write_access()/allow_write_access() at exec time:
If we end up denying write access to the wrong file and not to the
realfile, that would be fundamentally broken. We would have to reroute
our deny_write_access()/ allow_write_access() calls for the exec file to
the realfile -- but I leave figuring out the details to overlayfs guys, as
that would be a related but different issue.
There was a lengthy discussion in [3] whether to remove deny_write_access()
completely; however, if we decide to go that way, it would ideally be done
on top, because it could be that some applications even rely on the current
behavior.
v1 -> v2:
- "kernel/fork: factor out replacing the current MM exe_file"
-- Call the function "replace_mm_exe_file()" instead
-- Add some doc, similar to set_mm_exe_file()
-- Update patch subject/description
- "kernel/fork: always deny write access to current MM exe_file"
-- Introduce dup_mm_exe_file()
-- Make set_mm_exe_file() return an error to make the code easier to
grasp.
-- Improve comments
- Added ACKs
- Mention "sys_prctl(PR_SET_MM_MAP/EXE_FILE)" everywhere instead of
only "sys_prctl(PR_SET_MM_EXE_FILE)".
RFC -> v1:
- "binfmt: remove in-tree usage of MAP_DENYWRITE"
-- Add a note that this should fix part of a problem with overlayfs
[1] https://lore.kernel.org/r/20210423131640.20080-1-david@redhat.com/
[2] https://lore.kernel.org/r/YNHXzBgzRrZu1MrD@miu.piliscsaba.redhat.com/
[3] https://lkml.kernel.org/r/20210812084348.6521-1-david@redhat.com
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Thomas Gleixner <redacted>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>
Cc: Alexey Dobriyan <redacted>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Arnaldo Carvalho de Melo <acme@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Jiri Olsa <redacted>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Petr Mladek <pmladek@suse.com>
Cc: Sergey Senozhatsky <redacted>
Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Cc: Kees Cook <redacted>
Cc: "Eric W. Biederman" <redacted>
Cc: Greg Ungerer <gerg@linux-m68k.org>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Mike Rapoport <rppt@kernel.org>
Cc: Vlastimil Babka <redacted>
Cc: Vincenzo Frascino <vincenzo.frascino@arm.com>
Cc: Chinwen Chang <redacted>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: "Matthew Wilcox (Oracle)" <willy@infradead.org>
Cc: Huang Ying <redacted>
Cc: Jann Horn <jannh@google.com>
Cc: Feng Tang <redacted>
Cc: Kevin Brodsky <redacted>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Shawn Anastasio <redacted>
Cc: Steven Price <steven.price@arm.com>
Cc: Nicholas Piggin <npiggin@gmail.com>
Cc: Christian Brauner <redacted>
Cc: Jens Axboe <axboe@kernel.dk>
Cc: Gabriel Krisman Bertazi <redacted>
Cc: Peter Xu <peterx@redhat.com>
Cc: Suren Baghdasaryan <surenb@google.com>
Cc: Shakeel Butt <redacted>
Cc: Marco Elver <elver@google.com>
Cc: Daniel Jordan <daniel.m.jordan@oracle.com>
Cc: Nicolas Viennot <redacted>
Cc: Thomas Cedeno <redacted>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Miklos Szeredi <miklos@szeredi.hu>
Cc: Chengguang Xu <redacted>
Cc: "Christian König" <ckoenig.leichtzumerken@gmail.com>
Cc: Florian Weimer <redacted>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: David Laight <redacted>
Cc: linux-unionfs@vger.kernel.org
Cc: linux-api@vger.kernel.org
Cc: x86@kernel.org
Cc: linux-fsdevel@vger.kernel.org
Cc: linux-mm@kvack.org
David Hildenbrand (7):
binfmt: don't use MAP_DENYWRITE when loading shared libraries via
uselib()
kernel/fork: factor out replacing the current MM exe_file
kernel/fork: always deny write access to current MM exe_file
binfmt: remove in-tree usage of MAP_DENYWRITE
mm: remove VM_DENYWRITE
mm: ignore MAP_DENYWRITE in ksys_mmap_pgoff()
fs: update documentation of get_write_access() and friends
arch/x86/ia32/ia32_aout.c | 8 ++-
fs/binfmt_aout.c | 7 ++-
fs/binfmt_elf.c | 6 +--
fs/binfmt_elf_fdpic.c | 2 +-
fs/exec.c | 4 +-
fs/proc/task_mmu.c | 1 -
include/linux/fs.h | 19 ++++---
include/linux/mm.h | 4 +-
include/linux/mman.h | 4 +-
include/trace/events/mmflags.h | 1 -
kernel/events/core.c | 2 -
kernel/fork.c | 95 ++++++++++++++++++++++++++++++----
kernel/sys.c | 33 +-----------
lib/test_printf.c | 5 +-
mm/mmap.c | 29 ++---------
mm/nommu.c | 2 -
16 files changed, 119 insertions(+), 103 deletions(-)
base-commit: 7c60610d476766e128cc4284bb6349732cbd6606
--
2.31.1
From: David Hildenbrand <hidden> Date: 2021-08-16 19:49:49
uselib() is the legacy systemcall for loading shared libraries.
Nowadays, applications use dlopen() to load shared libraries, completely
implemented in user space via mmap().
For example, glibc uses MAP_COPY to mmap shared libraries. While this
maps to MAP_PRIVATE | MAP_DENYWRITE on Linux, Linux ignores any
MAP_DENYWRITE specification from user space in mmap.
With this change, all remaining in-tree users of MAP_DENYWRITE use it
to map an executable. We will be able to open shared libraries loaded
via uselib() writable, just as we already can via dlopen() from user
space.
This is one step into the direction of removing MAP_DENYWRITE from the
kernel. This can be considered a minor user space visible change.
Acked-by: "Eric W. Biederman" <redacted>
Signed-off-by: David Hildenbrand <redacted>
---
arch/x86/ia32/ia32_aout.c | 2 +-
fs/binfmt_aout.c | 2 +-
fs/binfmt_elf.c | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
@@ -293,7 +293,7 @@ static int load_aout_library(struct file *file)/* Now use mmap to map the library into memory. */error=vm_mmap(file,start_addr,ex.a_text+ex.a_data,PROT_READ|PROT_WRITE|PROT_EXEC,-MAP_FIXED|MAP_PRIVATE|MAP_DENYWRITE|MAP_32BIT,+MAP_FIXED|MAP_PRIVATE|MAP_32BIT,N_TXTOFF(ex));retval=error;if(error!=start_addr)
@@ -309,7 +309,7 @@ static int load_aout_library(struct file *file)/* Now use mmap to map the library into memory. */error=vm_mmap(file,start_addr,ex.a_text+ex.a_data,PROT_READ|PROT_WRITE|PROT_EXEC,-MAP_FIXED|MAP_PRIVATE|MAP_DENYWRITE,+MAP_FIXED|MAP_PRIVATE;N_TXTOFF(ex));retval=error;if(error!=start_addr)
From: David Hildenbrand <hidden> Date: 2021-08-16 19:50:14
Let's factor the main logic out into replace_mm_exe_file(), such that
all mm->exe_file logic is contained in kernel/fork.c.
While at it, perform some simple cleanups that are possible now that
we're simplifying the individual functions.
Acked-by: Christian Brauner <redacted>
Acked-by: "Eric W. Biederman" <redacted>
Signed-off-by: David Hildenbrand <redacted>
---
include/linux/mm.h | 1 +
kernel/fork.c | 44 +++++++++++++++++++++++++++++++++++++++++---
kernel/sys.c | 33 +--------------------------------
3 files changed, 43 insertions(+), 35 deletions(-)
@@ -1170,6 +1168,46 @@ void set_mm_exe_file(struct mm_struct *mm, struct file *new_exe_file)fput(old_exe_file);}+/**+*replace_mm_exe_file-replaceareferencetothemm'sexecutablefile+*+*Thischangesmm'sexecutablefile(shownassymlink/proc/[pid]/exe),+*dealingwithconcurrentinvocationandwithoutgrabbingthemmaplockin+*writemode.+*+*Mainuserissys_prctl(PR_SET_MM_MAP/EXE_FILE).+*/+intreplace_mm_exe_file(structmm_struct*mm,structfile*new_exe_file)+{+structvm_area_struct*vma;+structfile*old_exe_file;+intret=0;++/* Forbid mm->exe_file change if old file still mapped. */+old_exe_file=get_mm_exe_file(mm);+if(old_exe_file){+mmap_read_lock(mm);+for(vma=mm->mmap;vma&&!ret;vma=vma->vm_next){+if(!vma->vm_file)+continue;+if(path_equal(&vma->vm_file->f_path,+&old_exe_file->f_path))+ret=-EBUSY;+}+mmap_read_unlock(mm);+fput(old_exe_file);+if(ret)+returnret;+}++/* set the new file, lockless */+get_file(new_exe_file);+old_exe_file=xchg(&mm->exe_file,new_exe_file);+if(old_exe_file)+fput(old_exe_file);+return0;+}+/***get_mm_exe_file-acquireareferencetothemm'sexecutablefile*
@@ -1869,40 +1868,10 @@ static int prctl_set_mm_exe_file(struct mm_struct *mm, unsigned int fd)if(err)gotoexit;-/*-*Forbidmm->exe_filechangeifoldfilestillmapped.-*/-exe_file=get_mm_exe_file(mm);-err=-EBUSY;-if(exe_file){-structvm_area_struct*vma;--mmap_read_lock(mm);-for(vma=mm->mmap;vma;vma=vma->vm_next){-if(!vma->vm_file)-continue;-if(path_equal(&vma->vm_file->f_path,-&exe_file->f_path))-gotoexit_err;-}--mmap_read_unlock(mm);-fput(exe_file);-}--err=0;-/* set the new file, lockless */-get_file(exe.file);-old_exe=xchg(&mm->exe_file,exe.file);-if(old_exe)-fput(old_exe);+err=replace_mm_exe_file(mm,exe.file);exit:fdput(exe);returnerr;-exit_err:-mmap_read_unlock(mm);-fput(exe_file);-gotoexit;}/*
From: David Hildenbrand <hidden> Date: 2021-08-16 19:50:37
We want to remove VM_DENYWRITE only currently only used when mapping the
executable during exec. During exec, we already deny_write_access() the
executable, however, after exec completes the VMAs mapped
with VM_DENYWRITE effectively keeps write access denied via
deny_write_access().
Let's deny write access when setting or replacing the MM exe_file. With
this change, we can remove VM_DENYWRITE for mapping executables.
Make set_mm_exe_file() return an error in case deny_write_access()
fails; note that this should never happen, because exec code does a
deny_write_access() early and keeps write access denied when calling
set_mm_exe_file. However, it makes the code easier to read and makes
set_mm_exe_file() and replace_mm_exe_file() look more similar.
This represents a minor user space visible change:
sys_prctl(PR_SET_MM_MAP/EXE_FILE) can now fail if the file is already
opened writable. Also, after sys_prctl(PR_SET_MM_MAP/EXE_FILE) the file
cannot be opened writable. Note that we can already fail with -EACCES if
the file doesn't have execute permissions.
Acked-by: "Eric W. Biederman" <redacted>
Signed-off-by: David Hildenbrand <redacted>
---
fs/exec.c | 4 +++-
include/linux/mm.h | 2 +-
kernel/fork.c | 50 ++++++++++++++++++++++++++++++++++++++++------
3 files changed, 48 insertions(+), 8 deletions(-)
@@ -1270,7 +1270,9 @@ int begin_new_exec(struct linux_binprm * bprm)*notvisibileuntilthen.Thisalsoenablestheupdate*tobelockless.*/-set_mm_exe_file(bprm->mm,bprm->file);+retval=set_mm_exe_file(bprm->mm,bprm->file);+if(retval)+gotoout;/* If the binary is not readable then enforce mm->dumpable=0 */would_dump(bprm,bprm->file);
@@ -2580,7 +2580,7 @@ static inline int check_data_rlimit(unsigned long rlim,externintmm_take_all_locks(structmm_struct*mm);externvoidmm_drop_all_locks(structmm_struct*mm);-externvoidset_mm_exe_file(structmm_struct*mm,structfile*new_exe_file);+externintset_mm_exe_file(structmm_struct*mm,structfile*new_exe_file);externintreplace_mm_exe_file(structmm_struct*mm,structfile*new_exe_file);externstructfile*get_mm_exe_file(structmm_struct*mm);externstructfile*get_task_exe_file(structtask_struct*task);
@@ -493,7 +507,7 @@ static __latent_entropy int dup_mmap(struct mm_struct *mm,mmap_write_lock_nested(mm,SINGLE_DEPTH_NESTING);/* No ordering required: file already has been exposed. */-RCU_INIT_POINTER(mm->exe_file,get_mm_exe_file(oldmm));+dup_mm_exe_file(mm,oldmm);mm->total_vm=oldmm->total_vm;mm->data_vm=oldmm->data_vm;
@@ -1201,10 +1227,22 @@ int replace_mm_exe_file(struct mm_struct *mm, struct file *new_exe_file)}/* set the new file, lockless */+ret=deny_write_access(new_exe_file);+if(ret)+return-EACCES;get_file(new_exe_file);+old_exe_file=xchg(&mm->exe_file,new_exe_file);-if(old_exe_file)+if(old_exe_file){+/*+*Don'tracewithdup_mmap()gettingthefileanddisallowing+*writeaccesswhilesomeonemightopenthefilewritable.+*/+mmap_read_lock(mm);+allow_write_access(old_exe_file);fput(old_exe_file);+mmap_read_unlock(mm);+}return0;}
From: David Hildenbrand <hidden> Date: 2021-08-16 19:50:54
At exec time when we mmap the new executable via MAP_DENYWRITE we have it
opened via do_open_execat() and already deny_write_access()'ed the file
successfully. Once exec completes, we allow_write_acces(); however,
we set mm->exe_file in begin_new_exec() via set_mm_exe_file() and
also deny_write_access() as long as mm->exe_file remains set. We'll
effectively deny write access to our executable via mm->exe_file
until mm->exe_file is changed -- when the process is removed, on new
exec, or via sys_prctl(PR_SET_MM_MAP/EXE_FILE).
Let's remove all usage of MAP_DENYWRITE, it's no longer necessary for
mm->exe_file.
In case of an elf interpreter, we'll now only deny write access to the file
during exec. This is somewhat okay, because the interpreter behaves
(and sometime is) a shared library; all shared libraries, especially the
ones loaded directly in user space like via dlopen() won't ever be mapped
via MAP_DENYWRITE, because we ignore that from user space completely;
these shared libraries can always be modified while mapped and executed.
Let's only special-case the main executable, denying write access while
being executed by a process. This can be considered a minor user space
visible change.
While this is a cleanup, it also fixes part of a problem reported with
VM_DENYWRITE on overlayfs, as VM_DENYWRITE is effectively unused with
this patch and will be removed next:
"Overlayfs did not honor positive i_writecount on realfile for
VM_DENYWRITE mappings." [1]
[1] https://lore.kernel.org/r/YNHXzBgzRrZu1MrD@miu.piliscsaba.redhat.com/
Reported-by: Chengguang Xu <redacted>
Acked-by: "Eric W. Biederman" <redacted>
Signed-off-by: David Hildenbrand <redacted>
---
arch/x86/ia32/ia32_aout.c | 6 ++----
fs/binfmt_aout.c | 5 ++---
fs/binfmt_elf.c | 4 ++--
fs/binfmt_elf_fdpic.c | 2 +-
4 files changed, 7 insertions(+), 10 deletions(-)
@@ -1788,22 +1784,12 @@ unsigned long mmap_region(struct file *file, unsigned long addr,vma->vm_pgoff=pgoff;if(file){-if(vm_flags&VM_DENYWRITE){-error=deny_write_access(file);-if(error)-gotofree_vma;-}if(vm_flags&VM_SHARED){error=mapping_map_writable(file->f_mapping);if(error)-gotoallow_write_and_free_vma;+gotofree_vma;}-/* ->mmap() can change vma->vm_file, but must guarantee that-*vma_link()belowcandenywrite-accessifVM_DENYWRITEisset-*andmapwritablyifVM_SHAREDisset.Thisusuallymeansthe-*newfilemustnothavebeenexposedtouser-space,yet.-*/vma->vm_file=get_file(file);error=call_mmap(file,vma);if(error)
@@ -1860,13 +1846,9 @@ unsigned long mmap_region(struct file *file, unsigned long addr,vma_link(mm,vma,prev,rb_link,rb_parent);/* Once vma denies write, undo our temporary denial count */-if(file){unmap_writable:-if(vm_flags&VM_SHARED)-mapping_unmap_writable(file->f_mapping);-if(vm_flags&VM_DENYWRITE)-allow_write_access(file);-}+if(file&&vm_flags&VM_SHARED)+mapping_unmap_writable(file->f_mapping);file=vma->vm_file;out:perf_event_mmap(vma);
@@ -1906,9 +1888,6 @@ unsigned long mmap_region(struct file *file, unsigned long addr,charged=0;if(vm_flags&VM_SHARED)mapping_unmap_writable(file->f_mapping);-allow_write_and_free_vma:-if(vm_flags&VM_DENYWRITE)-allow_write_access(file);free_vma:vm_area_free(vma);unacct_error:
From: David Hildenbrand <hidden> Date: 2021-08-16 19:51:34
Let's also remove masking off MAP_DENYWRITE from ksys_mmap_pgoff():
the last in-tree occurrence of MAP_DENYWRITE is now in LEGACY_MAP_MASK,
which accepts the flag e.g., for MAP_SHARED_VALIDATE; however, the flag
is ignored throughout the kernel now.
Add a comment to LEGACY_MAP_MASK stating that MAP_DENYWRITE is ignored.
Acked-by: "Eric W. Biederman" <redacted>
Signed-off-by: David Hildenbrand <redacted>
---
include/linux/mman.h | 3 ++-
mm/mmap.c | 2 --
mm/nommu.c | 2 --
3 files changed, 2 insertions(+), 5 deletions(-)
@@ -1626,8 +1626,6 @@ unsigned long ksys_mmap_pgoff(unsigned long addr, unsigned long len,returnPTR_ERR(file);}-flags&=~MAP_DENYWRITE;-retval=vm_mmap_pgoff(file,addr,len,prot,flags,pgoff);out_fput:if(file)
@@ -1296,8 +1296,6 @@ unsigned long ksys_mmap_pgoff(unsigned long addr, unsigned long len,gotoout;}-flags&=~MAP_DENYWRITE;-retval=vm_mmap_pgoff(file,addr,len,prot,flags,pgoff);if(file)
From: David Hildenbrand <hidden> Date: 2021-08-16 19:51:55
As VM_DENYWRITE does no longer exists, let's spring-clean the
documentation of get_write_access() and friends.
Acked-by: "Eric W. Biederman" <redacted>
Signed-off-by: David Hildenbrand <redacted>
---
include/linux/fs.h | 19 ++++++++++++-------
1 file changed, 12 insertions(+), 7 deletions(-)
From: Christian König <christian.koenig@amd.com> Date: 2021-08-17 11:01:37
Am 16.08.21 um 21:48 schrieb David Hildenbrand:
This series removes all in-tree usage of MAP_DENYWRITE from the kernel
and removes VM_DENYWRITE. We stopped supporting MAP_DENYWRITE for
user space applications a while ago because of the chance for DoS.
The last renaming user is binfmt binary loading during exec and
legacy library loading via uselib().
With this change, MAP_DENYWRITE is effectively ignored throughout the
kernel. Although the net change is small (well, we actually add code and
comments), I think the cleanup in mmap() is quite nice.
There are some (minor) user-visible changes with this series:
1. We no longer deny write access to shared libaries loaded via legacy
uselib(); this behavior matches modern user space e.g., via dlopen().
2. We no longer deny write access to the elf interpreter after exec
completed, treating it just like shared libraries (which it often is).
3. We always deny write access to the file linked via /proc/pid/exe:
sys_prctl(PR_SET_MM_MAP/EXE_FILE) will fail if write access to the file
cannot be denied, and write access to the file will remain denied
until the link is effectivel gone (exec, termination,
sys_prctl(PR_SET_MM_MAP/EXE_FILE)) -- just as if exec'ing the file.
There is a related problem [2] with overlayfs, that should at least partly
be tackled by this series. I don't quite understand the interaction of
overlayfs and deny_write_access()/allow_write_access() at exec time:
If we end up denying write access to the wrong file and not to the
realfile, that would be fundamentally broken. We would have to reroute
our deny_write_access()/ allow_write_access() calls for the exec file to
the realfile -- but I leave figuring out the details to overlayfs guys, as
that would be a related but different issue.
There was a lengthy discussion in [3] whether to remove deny_write_access()
completely; however, if we decide to go that way, it would ideally be done
on top, because it could be that some applications even rely on the current
behavior.
v1 -> v2:
- "kernel/fork: factor out replacing the current MM exe_file"
-- Call the function "replace_mm_exe_file()" instead
-- Add some doc, similar to set_mm_exe_file()
-- Update patch subject/description
- "kernel/fork: always deny write access to current MM exe_file"
-- Introduce dup_mm_exe_file()
-- Make set_mm_exe_file() return an error to make the code easier to
grasp.
-- Improve comments
- Added ACKs
- Mention "sys_prctl(PR_SET_MM_MAP/EXE_FILE)" everywhere instead of
only "sys_prctl(PR_SET_MM_EXE_FILE)".
RFC -> v1:
- "binfmt: remove in-tree usage of MAP_DENYWRITE"
-- Add a note that this should fix part of a problem with overlayfs
This is unfortunately way beyond my understanding of the fs layer to
actually review this.
But from the ten mile high view it looks like a really nice cleanup to
me and makes my live in the DRM subsystem much easier.
Feel free to add a Acked-by: Christian König [off-list ref]
to the series.
Thanks,
Christian.
[1] https://lore.kernel.org/r/20210423131640.20080-1-david@redhat.com/
[2] https://lore.kernel.org/r/YNHXzBgzRrZu1MrD@miu.piliscsaba.redhat.com/
[3] https://lkml.kernel.org/r/20210812084348.6521-1-david@redhat.com
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Thomas Gleixner <redacted>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>
Cc: Alexey Dobriyan <redacted>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Arnaldo Carvalho de Melo <acme@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Jiri Olsa <redacted>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Petr Mladek <pmladek@suse.com>
Cc: Sergey Senozhatsky <redacted>
Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Cc: Kees Cook <redacted>
Cc: "Eric W. Biederman" <redacted>
Cc: Greg Ungerer <gerg@linux-m68k.org>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Mike Rapoport <rppt@kernel.org>
Cc: Vlastimil Babka <redacted>
Cc: Vincenzo Frascino <vincenzo.frascino@arm.com>
Cc: Chinwen Chang <redacted>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: "Matthew Wilcox (Oracle)" <willy@infradead.org>
Cc: Huang Ying <redacted>
Cc: Jann Horn <jannh@google.com>
Cc: Feng Tang <redacted>
Cc: Kevin Brodsky <redacted>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Shawn Anastasio <redacted>
Cc: Steven Price <steven.price@arm.com>
Cc: Nicholas Piggin <npiggin@gmail.com>
Cc: Christian Brauner <redacted>
Cc: Jens Axboe <axboe@kernel.dk>
Cc: Gabriel Krisman Bertazi <redacted>
Cc: Peter Xu <peterx@redhat.com>
Cc: Suren Baghdasaryan <surenb@google.com>
Cc: Shakeel Butt <redacted>
Cc: Marco Elver <elver@google.com>
Cc: Daniel Jordan <daniel.m.jordan@oracle.com>
Cc: Nicolas Viennot <redacted>
Cc: Thomas Cedeno <redacted>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Miklos Szeredi <miklos@szeredi.hu>
Cc: Chengguang Xu <redacted>
Cc: "Christian König" <ckoenig.leichtzumerken@gmail.com>
Cc: Florian Weimer <redacted>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: David Laight <redacted>
Cc: linux-unionfs@vger.kernel.org
Cc: linux-api@vger.kernel.org
Cc: x86@kernel.org
Cc: linux-fsdevel@vger.kernel.org
Cc: linux-mm@kvack.org
David Hildenbrand (7):
binfmt: don't use MAP_DENYWRITE when loading shared libraries via
uselib()
kernel/fork: factor out replacing the current MM exe_file
kernel/fork: always deny write access to current MM exe_file
binfmt: remove in-tree usage of MAP_DENYWRITE
mm: remove VM_DENYWRITE
mm: ignore MAP_DENYWRITE in ksys_mmap_pgoff()
fs: update documentation of get_write_access() and friends
arch/x86/ia32/ia32_aout.c | 8 ++-
fs/binfmt_aout.c | 7 ++-
fs/binfmt_elf.c | 6 +--
fs/binfmt_elf_fdpic.c | 2 +-
fs/exec.c | 4 +-
fs/proc/task_mmu.c | 1 -
include/linux/fs.h | 19 ++++---
include/linux/mm.h | 4 +-
include/linux/mman.h | 4 +-
include/trace/events/mmflags.h | 1 -
kernel/events/core.c | 2 -
kernel/fork.c | 95 ++++++++++++++++++++++++++++++----
kernel/sys.c | 33 +-----------
lib/test_printf.c | 5 +-
mm/mmap.c | 29 ++---------
mm/nommu.c | 2 -
16 files changed, 119 insertions(+), 103 deletions(-)
base-commit: 7c60610d476766e128cc4284bb6349732cbd6606
So I like this series.
However, logically, I think this part in replace_mm_exe_file() no
longer makes sense:
On Mon, Aug 16, 2021 at 12:50 PM David Hildenbrand [off-list ref] wrote:
+ /* Forbid mm->exe_file change if old file still mapped. */
+ old_exe_file = get_mm_exe_file(mm);
+ if (old_exe_file) {
+ mmap_read_lock(mm);
+ for (vma = mm->mmap; vma && !ret; vma = vma->vm_next) {
+ if (!vma->vm_file)
+ continue;
+ if (path_equal(&vma->vm_file->f_path,
+ &old_exe_file->f_path))
+ ret = -EBUSY;
+ }
+ mmap_read_unlock(mm);
+ fput(old_exe_file);
+ if (ret)
+ return ret;
+ }
and should just be removed.
NOTE! I think it makes sense within the context of this patch (where
you just move code around), but that it should then be removed in the
next patch that does that "always deny write access to current MM
exe_file" thing.
I just quoted it in the context of this patch, since the next patch
doesn't actually show this code any more.
In the *old* model - where the ETXTBUSY was about the mmap() of the
file - the above tests make sense.
But in the new model, walking the mappings just doesn't seem to be a
sensible operation any more. The mappings simply aren't what ETXTBUSY
is about in the new world order, and so doing that mapping walk seems
nonsensical.
Hmm?
Linus
From: David Hildenbrand <hidden> Date: 2021-08-20 08:46:55
On 19.08.21 22:51, Linus Torvalds wrote:
So I like this series.
However, logically, I think this part in replace_mm_exe_file() no
longer makes sense:
On Mon, Aug 16, 2021 at 12:50 PM David Hildenbrand [off-list ref] wrote:
quoted
+ /* Forbid mm->exe_file change if old file still mapped. */
+ old_exe_file = get_mm_exe_file(mm);
+ if (old_exe_file) {
+ mmap_read_lock(mm);
+ for (vma = mm->mmap; vma && !ret; vma = vma->vm_next) {
+ if (!vma->vm_file)
+ continue;
+ if (path_equal(&vma->vm_file->f_path,
+ &old_exe_file->f_path))
+ ret = -EBUSY;
+ }
+ mmap_read_unlock(mm);
+ fput(old_exe_file);
+ if (ret)
+ return ret;
+ }
and should just be removed.
NOTE! I think it makes sense within the context of this patch (where
you just move code around), but that it should then be removed in the
next patch that does that "always deny write access to current MM
exe_file" thing.
I just quoted it in the context of this patch, since the next patch
doesn't actually show this code any more.
In the *old* model - where the ETXTBUSY was about the mmap() of the
file - the above tests make sense.
But in the new model, walking the mappings just doesn't seem to be a
sensible operation any more. The mappings simply aren't what ETXTBUSY
is about in the new world order, and so doing that mapping walk seems
nonsensical.
Hmm?
I think this is somewhat another kind of "stop user space trying
to do stupid things" thingy, not necessarily glued to ETXTBUSY:
don't allow replacing exe_file if that very file is still mapped
and consequently eventually still in use by the application.
I don't think it necessarily has many things to do with ETXTBUSY:
we only check if there is a VMA mapping that file, not that it's
a VM_DENYWRITE mapping.
That code originates from
commit 4229fb1dc6843c49a14bb098719f8a696cdc44f8
Author: Konstantin Khlebnikov [off-list ref]
Date: Wed Jul 11 14:02:11 2012 -0700
c/r: prctl: less paranoid prctl_set_mm_exe_file()
"no other files mapped" requirement from my previous patch (c/r: prctl:
update prctl_set_mm_exe_file() after mm->num_exe_file_vmas removal) is too
paranoid, it forbids operation even if there mapped one shared-anon vma.
Let's check that current mm->exe_file already unmapped, in this case
exe_file symlink already outdated and its changing is reasonable.
The statement "exe_file symlink already outdated and its
changing is reasonable" somewhat makes sense.
Long story short, I think this check somehow makes a bit of sense, but
we wouldn't lose too much if we drop it -- just another sanity check.
Your call :)
--
Thanks,
David / dhildenb
From: David Hildenbrand <hidden> Date: 2021-09-03 09:45:11
On 16.08.21 21:48, David Hildenbrand wrote:
This series removes all in-tree usage of MAP_DENYWRITE from the kernel
and removes VM_DENYWRITE. We stopped supporting MAP_DENYWRITE for
user space applications a while ago because of the chance for DoS.
The last renaming user is binfmt binary loading during exec and
legacy library loading via uselib().
So, how do we want to continue with this? Pick it up for v5.15? Have it
in -next for a while and eventually pick it up for v5.16?
I think the "remove ETXTBSY completely" and "remove the sanity mapping
check" thingies should be done on top.
--
Thanks,
David / dhildenb
On Fri, Sep 3, 2021 at 2:45 AM David Hildenbrand [off-list ref] wrote:
So, how do we want to continue with this? Pick it up for v5.15? Have it
in -next for a while and eventually pick it up for v5.16?
I'm ok with the series. If you have a git tree, do the normal pull
request, and we can do it for 5.15 and see if anybody notices.
As you say, any final removal of ETXTBSY should be a separate and
later patch on top.
Linus
On Mon, Aug 16, 2021 at 09:48:34PM +0200, David Hildenbrand wrote:
quoted hunk
uselib() is the legacy systemcall for loading shared libraries.
Nowadays, applications use dlopen() to load shared libraries, completely
implemented in user space via mmap().
For example, glibc uses MAP_COPY to mmap shared libraries. While this
maps to MAP_PRIVATE | MAP_DENYWRITE on Linux, Linux ignores any
MAP_DENYWRITE specification from user space in mmap.
With this change, all remaining in-tree users of MAP_DENYWRITE use it
to map an executable. We will be able to open shared libraries loaded
via uselib() writable, just as we already can via dlopen() from user
space.
This is one step into the direction of removing MAP_DENYWRITE from the
kernel. This can be considered a minor user space visible change.
Acked-by: "Eric W. Biederman" <redacted>
Signed-off-by: David Hildenbrand <redacted>
---
arch/x86/ia32/ia32_aout.c | 2 +-
fs/binfmt_aout.c | 2 +-
fs/binfmt_elf.c | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
@@ -293,7 +293,7 @@ static int load_aout_library(struct file *file)/* Now use mmap to map the library into memory. */error=vm_mmap(file,start_addr,ex.a_text+ex.a_data,PROT_READ|PROT_WRITE|PROT_EXEC,-MAP_FIXED|MAP_PRIVATE|MAP_DENYWRITE|MAP_32BIT,+MAP_FIXED|MAP_PRIVATE|MAP_32BIT,N_TXTOFF(ex));retval=error;if(error!=start_addr)
@@ -309,7 +309,7 @@ static int load_aout_library(struct file *file)/* Now use mmap to map the library into memory. */error=vm_mmap(file,start_addr,ex.a_text+ex.a_data,PROT_READ|PROT_WRITE|PROT_EXEC,-MAP_FIXED|MAP_PRIVATE|MAP_DENYWRITE,+MAP_FIXED|MAP_PRIVATE;N_TXTOFF(ex));
Guess someone didn't care compile testing their code. This is now in
mainline.
Guenter
On Sun, Sep 5, 2021 at 8:32 AM Guenter Roeck [off-list ref] wrote:
Guess someone didn't care compile testing their code. This is now in
mainline.
To be fair, a.out is disabled pretty much on all relevant platforms these days.
Only alpha and m68k left, I think.
I applied the obvious patch from Geert.
Linus
From: David Hildenbrand <hidden> Date: 2021-09-05 19:08:15
On 05.09.21 19:17, Linus Torvalds wrote:
On Sun, Sep 5, 2021 at 8:32 AM Guenter Roeck [off-list ref] wrote:
quoted
Guess someone didn't care compile testing their code. This is now in
mainline.
To be fair, a.out is disabled pretty much on all relevant platforms these days.
Yes, and it seems like it was disabled in all configs I used. (I did not
compile all-yes configs; usually my stuff goes via -mm where it will end
up in -next for a while ... this one was special)
Only alpha and m68k left, I think.
I applied the obvious patch from Geert.