All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nick Piggin <npiggin@suse.de>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Duane Griffin <duaneg@dghda.com>,
	linux-kernel Mailing List <linux-kernel@vger.kernel.org>,
	stable@kernel.org
Subject: Re: 2.6.23 regression: accessing invalid mmap'ed memory from gdb causes unkillable spinning
Date: Thu, 1 Nov 2007 03:37:58 +0100	[thread overview]
Message-ID: <20071101023758.GA30613@wotan.suse.de> (raw)
In-Reply-To: <alpine.LFD.0.999.0710311602170.3342@woody.linux-foundation.org>

On Wed, Oct 31, 2007 at 04:08:21PM -0700, Linus Torvalds wrote:
> 
> 
> On Wed, 31 Oct 2007, Nick Piggin wrote:
> > 
> > No that would be great. Fingers crossed it won't cause any problems.
> 
> I actually doubt it will cause problems.
> 
> We made much bigger changes to ptrace support when we disallowed writing 
> to read-only shared memory areas (we used to do the magic per-page COW 
> thing).

Really? No, we still do that magic COW thing which creates anonymous
pages in MAP_SHARED vmas, don't we?

But I think that is pretty arbitrary as well. What the "force" argument to
get_user_pages on a MAP_SHARED vma effectively does is punt the permission
check from the vma permissions to the file permissions. If you've opened the
file WR but mmap()ed PROT_READ, it goes ahead and COWs, wheras if you've
opened the file RDONLY it -EFAULTs.

This seems strange wrong, because the act of COWing seems to be exactly
done in order to *absolve* us of file permissions (if we're COWing, why
should it matter if the file happened to be readonly or not).

Could we just try disallow COW for MAP_SHARED mappings?
Seeing as we're doing the break-ptrace thing this release already ;)
All the stuff I know of that requires forced COW (ie. gdb for breakpoints),
does so on MAP_PRIVATE mappings.

I know this is one of Hugh's bugbears. I don't know whether he's thought
out how to remove it, but I wonder if the appended patch is roughly in
the right direction?

> But if people have test-cases for ptrace and/or other magical users of 
> access_vm_pages() (things like core-dumping comes to mind - although I 
> think we don't dump pure file mappings at all, do we?) it would certainly 
> be good to run any such tests on the current -git tree...

We do for MAP_SHARED|MAP_ANONYMOUS, by the looks.

---
Index: linux-2.6/mm/memory.c
===================================================================
--- linux-2.6.orig/mm/memory.c
+++ linux-2.6/mm/memory.c
@@ -1563,13 +1563,11 @@ static int do_wp_page(struct mm_struct *
 			reuse = can_share_swap_page(old_page);
 			unlock_page(old_page);
 		}
-	} else if (unlikely((vma->vm_flags & (VM_WRITE|VM_SHARED)) ==
-					(VM_WRITE|VM_SHARED))) {
+	} else if (unlikely((vma->vm_flags & VM_SHARED))) {
 		/*
-		 * Only catch write-faults on shared writable pages,
-		 * read-only shared pages can get COWed by
-		 * get_user_pages(.write=1, .force=1).
+		 * Only catch write-faults on shared writable pages.
 		 */
+		BUG_ON(!(vma->vm_flags & VM_WRITE));
 		if (vma->vm_ops && vma->vm_ops->page_mkwrite) {
 			/*
 			 * Notify the address space that the page is about to
Index: linux-2.6/mm/mmap.c
===================================================================
--- linux-2.6.orig/mm/mmap.c
+++ linux-2.6/mm/mmap.c
@@ -980,9 +980,11 @@ unsigned long do_mmap_pgoff(struct file 
 			if (locks_verify_locked(inode))
 				return -EAGAIN;
 
-			vm_flags |= VM_SHARED | VM_MAYSHARE;
-			if (!(file->f_mode & FMODE_WRITE))
-				vm_flags &= ~(VM_MAYWRITE | VM_SHARED);
+			vm_flags |= VM_MAYSHARE;
+			if (file->f_mode & FMODE_WRITE)
+				vm_flags |= VM_SHARED;
+			if (!(vm_flags & VM_WRITE))
+				vm_flags &= ~VM_MAYWRITE;
 
 			/* fall through */
 		case MAP_PRIVATE:
@@ -998,6 +1000,7 @@ unsigned long do_mmap_pgoff(struct file 
 
 			if (!file->f_op || !file->f_op->mmap)
 				return -ENODEV;
+
 			break;
 
 		default:
@@ -1007,6 +1010,8 @@ unsigned long do_mmap_pgoff(struct file 
 		switch (flags & MAP_TYPE) {
 		case MAP_SHARED:
 			vm_flags |= VM_SHARED | VM_MAYSHARE;
+			if (!(vm_flags & VM_WRITE))
+				vm_flags &= ~VM_MAYWRITE;
 			break;
 		case MAP_PRIVATE:
 			/*

  reply	other threads:[~2007-11-01  2:38 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-10-31  0:45 2.6.23 regression: accessing invalid mmap'ed memory from gdb causes unkillable spinning Duane Griffin
2007-10-31  4:19 ` Nick Piggin
2007-10-31 10:27   ` Duane Griffin
2007-10-31 15:11   ` Linus Torvalds
2007-10-31 15:19     ` Nick Piggin
2007-10-31 15:59       ` Linus Torvalds
2007-10-31 17:19         ` Duane Griffin
2007-10-31 22:55         ` Nick Piggin
2007-10-31 23:08           ` Linus Torvalds
2007-11-01  2:37             ` Nick Piggin [this message]
2007-11-01 15:14               ` Linus Torvalds
2007-11-01 15:47                 ` Nick Piggin
2007-11-01 16:08                   ` Linus Torvalds
2007-11-01 23:56                     ` Nick Piggin
2007-11-02  1:17                       ` Linus Torvalds
2007-11-02  6:30                         ` Nick Piggin
2007-10-31  6:42 ` Nick Piggin
2007-10-31  6:56   ` David Miller
2007-10-31  7:41     ` Nick Piggin
2007-10-31  7:44       ` David Miller
2007-11-02  5:02         ` David Miller
2007-11-02 10:45           ` Nick Piggin
2007-11-02 15:36             ` Ingo Molnar

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20071101023758.GA30613@wotan.suse.de \
    --to=npiggin@suse.de \
    --cc=duaneg@dghda.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=stable@kernel.org \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.