linux-kernel - Re: [PATCH] procfs task exe symlink

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 19 Feb 2008 13:54:25 -0800
From:	Matt Helsley <matthltc@...ibm.com>
To:	Mike Frysinger <vapier.adi@...il.com>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	linux-mm <linux-mm@...ck.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Oleg Nesterov <oleg@...sign.ru>,
	David Howells <dhowells@...hat.com>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	Christoph Hellwig <chellwig@...ibm.com>,
	Al Viro <viro@...iv.linux.org.uk>,
	Hugh Dickins <hugh@...itas.com>, Bryan Wu <Bryan.Wu@...log.com>
Subject: Re: [PATCH] procfs task exe symlink


On Sat, 2008-02-16 at 07:12 -0500, Mike Frysinger wrote:
> On Feb 6, 2008 8:44 PM, Matt Helsley <matthltc@...ibm.com> wrote:
> > The kernel implements readlink of /proc/pid/exe by getting the file from the
> > first executable VMA. Then the path to the file is reconstructed and reported as
> > the result.
> >
> > Because of the VMA walk the code is slightly different on nommu systems. This
> > patch avoids separate /proc/pid/exe code on nommu systems. Instead of walking
> > the VMAs to find the first executable file-backed VMA we store a reference to
> > the exec'd file in the mm_struct.
> >
> > That reference would prevent the filesystem holding the executable file from
> > being unmounted even after unmapping the VMAs. So we track the number of
> > VM_EXECUTABLE VMAs and drop the new reference when the last one is unmapped.
> > This avoids pinning the mounted filesystem.
> >
> > Andrew, these are the updates I promised. Please consider this patch for
> > inclusion in -mm.
> 
> mm/nommu.c wasnt compiled tested, it's trivially broken:

Thanks for the report. I've looked into this and the "obvious" fix,
using vma->vm_mm, isn't correct since it's never set. This means the
portions of the procfs task exe symlink patch using vma->vm_mm in
mm/nommu.c are incorrect.

The patch below attempts to fix this by using current->mm during mmap
and passing the current mm to put_vma() as well.

Mike, does this patch fix the compile problem(s)?

Signed-off-by: Matt Helsley <matthltc@...ibm.com>

---
Mike, I don't have a nommu compile or test environment. I have yet
to to generate a good CONFIG_MMU=n config on i386 (got one?). Since I
don't have any nommu hardware I'm also looking into using qemu. It looks
like I may need to build my own image from scratch. Do you have any
recommendations on testing nommu configs without hardware?

 mm/nommu.c |   14 ++++++++------
 1 file changed, 8 insertions(+), 6 deletions(-)

Index: linux-2.6.24/mm/nommu.c
===================================================================
--- linux-2.6.24.orig/mm/nommu.c
+++ linux-2.6.24/mm/nommu.c
@@ -962,12 +962,14 @@ unsigned long do_mmap_pgoff(struct file 
 
 	INIT_LIST_HEAD(&vma->anon_vma_node);
 	atomic_set(&vma->vm_usage, 1);
 	if (file) {
 		get_file(file);
-		if (vm_flags & VM_EXECUTABLE)
-			added_exe_file_vma(mm);
+		if (vm_flags & VM_EXECUTABLE) {
+			added_exe_file_vma(current->mm);
+			vma->vm_mm = current->mm;
+		}
 	}
 	vma->vm_file	= file;
 	vma->vm_flags	= vm_flags;
 	vma->vm_start	= addr;
 	vma->vm_end	= addr + len;
@@ -1053,11 +1055,11 @@ unsigned long do_mmap_pgoff(struct file 
 EXPORT_SYMBOL(do_mmap_pgoff);
 
 /*
  * handle mapping disposal for uClinux
  */
-static void put_vma(struct vm_area_struct *vma)
+static void put_vma(struct mm_struct *mm, struct vm_area_struct *vma)
 {
 	if (vma) {
 		down_write(&nommu_vma_sem);
 
 		if (atomic_dec_and_test(&vma->vm_usage)) {
@@ -1078,11 +1080,11 @@ static void put_vma(struct vm_area_struc
 			askedalloc -= sizeof(*vma);
 
 			if (vma->vm_file) {
 				fput(vma->vm_file);
 				if (vma->vm_flags & VM_EXECUTABLE)
-					removed_exe_file_vma(vma->vm_mm);
+					removed_exe_file_vma(mm);
 			}
 			kfree(vma);
 		}
 
 		up_write(&nommu_vma_sem);
@@ -1116,11 +1118,11 @@ int do_munmap(struct mm_struct *mm, unsi
 	return -EINVAL;
 
  found:
 	vml = *parent;
 
-	put_vma(vml->vma);
+	put_vma(mm, vml->vma);
 
 	*parent = vml->next;
 	realalloc -= kobjsize(vml);
 	askedalloc -= sizeof(*vml);
 	kfree(vml);
@@ -1161,11 +1163,11 @@ void exit_mmap(struct mm_struct * mm)
 
 		mm->total_vm = 0;
 
 		while ((tmp = mm->context.vmlist)) {
 			mm->context.vmlist = tmp->next;
-			put_vma(tmp->vma);
+			put_vma(mm, tmp->vma);
 
 			realalloc -= kobjsize(tmp);
 			askedalloc -= sizeof(*tmp);
 			kfree(tmp);
 		}


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/