From: blaisorblade@yahoo.it
To: akpm@osdl.org
Cc: jdike@addtoit.com, linux-kernel@vger.kernel.org,
user-mode-linux-devel@lists.sourceforge.net,
blaisorblade@yahoo.it, mingo@elte.hu
Subject: [uml-devel] [patch 18/39] remap_file_pages protection support: add VM_FAULT_SIGSEGV
Date: Fri, 12 Aug 2005 20:21:45 +0200 [thread overview]
Message-ID: <20050812182145.DF52E24E7F3@zion.home.lan> (raw)
From: Ingo Molnar <mingo@elte.hu>
Since with remap_file_pages w/prot we may put PROT_NONE on a single PTE rather
than a VMA, we must handle that inside handle_mm_fault.
This value must be handled in the arch-specific fault handlers, and this
change must be ported to every arch on the world; now the new support is not
in a separate syscall, so this *must* be done unless we want stability /
security issues (the *BUG()* for unknown return values of handle_mm_fault() is
triggerable from userspace calling remap_file_pages, and on other archs, we
have VM_FAULT_OOM which is worse). However, I've alleviated this need via the
previous "safety net" patch.
This patch includes the arch-specific part for i386.
Note, however, that _proper_ support is more intrusive; we can allow a write
on a readonly VMA, but the arch fault handler currently stops that; it should
test VM_NONUNIFORM instead and call handle_mm_fault() in case it's set. And it
will have to do on its own all protection checks. This is in the following
patches.
Signed-off-by: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
---
linux-2.6.git-paolo/arch/i386/mm/fault.c | 2 ++
linux-2.6.git-paolo/include/linux/mm.h | 9 +++++----
linux-2.6.git-paolo/mm/memory.c | 12 ++++++++++++
3 files changed, 19 insertions(+), 4 deletions(-)
diff -puN arch/i386/mm/fault.c~rfp-add-vm_fault_sigsegv arch/i386/mm/fault.c
--- linux-2.6.git/arch/i386/mm/fault.c~rfp-add-vm_fault_sigsegv 2005-08-11 14:19:57.000000000 +0200
+++ linux-2.6.git-paolo/arch/i386/mm/fault.c 2005-08-11 14:19:58.000000000 +0200
@@ -351,6 +351,8 @@ good_area:
goto do_sigbus;
case VM_FAULT_OOM:
goto out_of_memory;
+ case VM_FAULT_SIGSEGV:
+ goto bad_area;
default:
BUG();
}
diff -puN include/linux/mm.h~rfp-add-vm_fault_sigsegv include/linux/mm.h
--- linux-2.6.git/include/linux/mm.h~rfp-add-vm_fault_sigsegv 2005-08-11 14:19:58.000000000 +0200
+++ linux-2.6.git-paolo/include/linux/mm.h 2005-08-11 14:19:58.000000000 +0200
@@ -632,10 +632,11 @@ static inline int page_mapped(struct pag
* Used to decide whether a process gets delivered SIGBUS or
* just gets major/minor fault counters bumped up.
*/
-#define VM_FAULT_OOM (-1)
-#define VM_FAULT_SIGBUS 0
-#define VM_FAULT_MINOR 1
-#define VM_FAULT_MAJOR 2
+#define VM_FAULT_OOM (-1)
+#define VM_FAULT_SIGBUS 0
+#define VM_FAULT_MINOR 1
+#define VM_FAULT_MAJOR 2
+#define VM_FAULT_SIGSEGV 3
#define offset_in_page(p) ((unsigned long)(p) & ~PAGE_MASK)
diff -puN mm/memory.c~rfp-add-vm_fault_sigsegv mm/memory.c
--- linux-2.6.git/mm/memory.c~rfp-add-vm_fault_sigsegv 2005-08-11 14:19:58.000000000 +0200
+++ linux-2.6.git-paolo/mm/memory.c 2005-08-11 14:19:58.000000000 +0200
@@ -1995,6 +1995,18 @@ static inline int handle_pte_fault(struc
return do_swap_page(mm, vma, address, pte, pmd, entry, write_access);
}
+ /*
+ * Generate a SIGSEGV if a PROT_NONE page is accessed; this is handled
+ * in arch-specific code if the whole VMA has PROT_NONE, and here if
+ * just this pte has PROT_NONE (which can be done only with
+ * remap_file_pages).
+ */
+ if (pgprot_val(pte_to_pgprot(entry)) == pgprot_val(__P000)) {
+ pte_unmap(pte);
+ spin_unlock(&mm->page_table_lock);
+ return VM_FAULT_SIGSEGV;
+ }
+
if (write_access) {
if (!pte_write(entry))
return do_wp_page(mm, vma, address, pte, pmd, entry);
_
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
next reply other threads:[~2005-08-12 18:15 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-08-12 18:21 blaisorblade [this message]
2005-08-15 9:40 ` [uml-devel] Re: [patch 18/39] remap_file_pages protection support: add VM_FAULT_SIGSEGV Russell King
2005-08-15 10:12 ` Nick Piggin
2005-08-15 10:15 ` Russell King
2005-08-23 8:45 ` Blaisorblade
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=20050812182145.DF52E24E7F3@zion.home.lan \
--to=blaisorblade@yahoo.it \
--cc=akpm@osdl.org \
--cc=jdike@addtoit.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=user-mode-linux-devel@lists.sourceforge.net \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox