[patch 34/39] remap_file_pages protection support: restrict permission testing

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



From: Paolo 'Blaisorblade' Giarrusso <[email protected]>

Yet to test. Currently we install a PTE when one is missing
irrispective of the fault type, and if the access type is prohibited we'll
get another fault and kill the process only then. With this, we check the
access type on the 1st fault.

We could also use this code for testing present PTE's, if the current
assumption (fault on present PTE's in VM_NONUNIFORM vma's means access violation)
proves problematic for architectures other than UML (which I already fixed),
but I hope it's not needed.

Signed-off-by: Paolo 'Blaisorblade' Giarrusso <[email protected]>
---

 linux-2.6.git-paolo/mm/memory.c |   16 ++++++++++++++++
 1 files changed, 16 insertions(+)

diff -puN mm/memory.c~rfp-fault-sigsegv-3 mm/memory.c
--- linux-2.6.git/mm/memory.c~rfp-fault-sigsegv-3	2005-08-12 17:19:17.000000000 +0200
+++ linux-2.6.git-paolo/mm/memory.c	2005-08-12 17:19:17.000000000 +0200
@@ -1963,6 +1963,7 @@ static int do_file_page(struct mm_struct
 	unsigned long pgoff;
 	pgprot_t pgprot;
 	int err;
+	pte_t test_entry;
 
 	BUG_ON(!vma->vm_ops || !vma->vm_ops->nopage);
 	/*
@@ -1983,6 +1984,21 @@ static int do_file_page(struct mm_struct
 	pgoff = pte_to_pgoff(*pte);
 	pgprot = vma->vm_flags & VM_NONUNIFORM ? pte_to_pgprot(*pte): vma->vm_page_prot;
 
+	/* If this is not enabled, we'll get another fault after return next
+	 * time, check we handle that one, and that this code works. */
+#if 1
+	/* We just want to test pte_{read,write,exec} */
+	test_entry = mk_pte(0, pgprot);
+	if (unlikely(vma->vm_flags & VM_NONUNIFORM) && !pte_file(*pte)) {
+		if ((access_mask & VM_WRITE) && !pte_write(test_entry))
+			goto out_segv;
+		if ((access_mask & VM_READ) && !pte_read(test_entry))
+			goto out_segv;
+		if ((access_mask & VM_EXEC) && !pte_exec(test_entry))
+			goto out_segv;
+	}
+#endif
+
 	pte_unmap(pte);
 	spin_unlock(&mm->page_table_lock);
 
_
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]
  Powered by Linux