[patch 18/39] remap_file_pages protection support: add VM_FAULT_SIGSEGV

[patch 18/39] remap_file_pages protection support: add VM_FAULT_SIGSEGV

[blaisorblade]

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);
_

Re: [patch 18/39] remap_file_pages protection support: add VM_FAULT_SIGSEGV

[Russell King]

On Fri, Aug 12, 2005 at 08:21:45PM +0200, blaisorblade@yahoo.it wrote:
> @@ -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)
>  

Please arrange for "success" values to be numerically larger than "failure"
values.  This will avoid breaking ARM.

Is there a reason why we don't use -ve numbers for failure and +ve for
success here?

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core

Re: [patch 18/39] remap_file_pages protection support: add VM_FAULT_SIGSEGV

[Nick Piggin]

Russell King wrote:
> On Fri, Aug 12, 2005 at 08:21:45PM +0200, blaisorblade@yahoo.it wrote:
> 
>>@@ -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)
>> 
> 
> 
> Please arrange for "success" values to be numerically larger than "failure"
> values.  This will avoid breaking ARM.
> 
> Is there a reason why we don't use -ve numbers for failure and +ve for
> success here?
> 

Well there is now, and that is we are now using a bit in the 2nd
byte as flags. So I had to do away with -ve numbers there entirely.

You could achieve a similar thing by using another bit in that byte
#define VM_FAULT_FAILED 0x20
and make that bit present in VM_FAULT_OOM and VM_FAULT_SIGBUS, then
do an unlikely test for that bit in your handler and branch away to
the slow path.

-- 
SUSE Labs, Novell Inc.

Send instant messages to your online friends http://au.messenger.yahoo.com 

Re: [patch 18/39] remap_file_pages protection support: add VM_FAULT_SIGSEGV

[Russell King]

On Mon, Aug 15, 2005 at 08:12:54PM +1000, Nick Piggin wrote:
> Well there is now, and that is we are now using a bit in the 2nd
> byte as flags. So I had to do away with -ve numbers there entirely.
> 
> You could achieve a similar thing by using another bit in that byte
> #define VM_FAULT_FAILED 0x20
> and make that bit present in VM_FAULT_OOM and VM_FAULT_SIGBUS, then
> do an unlikely test for that bit in your handler and branch away to
> the slow path.

That'll do as well, thanks.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core

Re: [patch 18/39] remap_file_pages protection support: add VM_FAULT_SIGSEGV

[Russell King]

On Mon, Aug 15, 2005 at 11:15:48AM +0100, Russell King wrote:
> On Mon, Aug 15, 2005 at 08:12:54PM +1000, Nick Piggin wrote:
> > Well there is now, and that is we are now using a bit in the 2nd
> > byte as flags. So I had to do away with -ve numbers there entirely.
> > 
> > You could achieve a similar thing by using another bit in that byte
> > #define VM_FAULT_FAILED 0x20
> > and make that bit present in VM_FAULT_OOM and VM_FAULT_SIGBUS, then
> > do an unlikely test for that bit in your handler and branch away to
> > the slow path.
> 
> That'll do as well, thanks.

Note that Ingo will not get replies from me anymore - Ingo is doing
sender callback checks on the From:/Sender: headers.  Since my joejob
protection ensures that I never receive bounces to those addresses,
such callbacks fail.  Hence his server rejects my messages.

I am not changing my policy on this - I get hammered with a tremendous
amount of such crap which tools like SA seem completely incapable of
dealing with, sorry.

(Note: this means that other folk, eg dwmw2, are in a similar position.)

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core

Re: [patch 18/39] remap_file_pages protection support: add VM_FAULT_SIGSEGV

[Blaisorblade]

On Monday 15 August 2005 12:15, Russell King wrote:
> On Mon, Aug 15, 2005 at 08:12:54PM +1000, Nick Piggin wrote:
> > Well there is now, and that is we are now using a bit in the 2nd
> > byte as flags. So I had to do away with -ve numbers there entirely.

> > You could achieve a similar thing by using another bit in that byte
> > #define VM_FAULT_FAILED 0x20
> > and make that bit present in VM_FAULT_OOM and VM_FAULT_SIGBUS, then
> > do an unlikely test for that bit in your handler and branch away to
> > the slow path.
 
> That'll do as well, thanks.
Note that what Nick said is about mainline kernels, not only my brave patch.

Currently Linus fixed up ARM26 by disabling the optimization: see git commit 
6e346228c76506e07e297744a28464022c6806ad.
-- 
Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!".
Paolo Giarrusso, aka Blaisorblade (Skype ID "PaoloGiarrusso", ICQ 215621894)
http://www.user-mode-linux.org/~blaisorblade


	

	
		
___________________________________ 
Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB 
http://mail.yahoo.it