linux-kernel - Re: [git pull] x86 PAT changes

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]

Message-ID: <20080426183212.GA15007@linux-os.sc.intel.com>
Date:	Sat, 26 Apr 2008 11:32:12 -0700
From:	Venki Pallipadi <venkatesh.pallipadi@...el.com>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	"Pallipadi, Venkatesh" <venkatesh.pallipadi@...el.com>,
	Ingo Molnar <mingo@...e.hu>, "H. Peter Anvin" <hpa@...or.com>,
	linux-kernel@...r.kernel.org,
	Andrew Morton <akpm@...ux-foundation.org>,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [git pull] x86 PAT changes

On Sat, Apr 26, 2008 at 10:15:33AM -0700, Linus Torvalds wrote:
> 
> 
> On Sat, 26 Apr 2008, Pallipadi, Venkatesh wrote:
> > 
> > Agreed that NONPROMISC_DEVMEM is not really needed for read/write. But,
> > we will still need it for /dev/mem.
> 
> If so, just disable it unconditionally for mmap.
> 
> As mentioned, that's really just a return to original Linux /dev/mmap 
> semantics: long ago (well, not _that_ long ago) we never used to be able 
> to mmap() normal kernel memory, because the page counts would get screwed 
> up on pages that weren't marked PG_Reserved.
> 
> So the traditional Linux behavior for mmap() on /dev/mem was always to 
> only allow it on memory that either had no "struct page *" backing at all, 
> or that was marked PG_Reserved (ie the ISA hole ay 640k-1M and things like 
> the BIOS tables etc).
> 
> Going back to that doesn't sound horrible.
> 

OK. Below is the quick to disable /dev/mem mmap of RAM with PAT.
This should go along with Ingo's patch that removes PAT dependency on
NONPROMISC_DEVMEM.  It makes things safer and eliminates aliasing.
Still somewhat unclean as the range_is_allowed is duplicated.
And also, just compile tested right now.


Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@...el.com>

---
 arch/x86/mm/pat.c |   31 +++++++++++++++++++++++++++++++
 1 file changed, 31 insertions(+)

Index: linux-2.6/arch/x86/mm/pat.c
===================================================================
--- linux-2.6.orig/arch/x86/mm/pat.c	2008-04-26 09:34:31.000000000 -0700
+++ linux-2.6/arch/x86/mm/pat.c	2008-04-26 11:25:57.000000000 -0700
@@ -16,6 +16,7 @@
 #include <asm/msr.h>
 #include <asm/tlbflush.h>
 #include <asm/processor.h>
+#include <asm/page.h>
 #include <asm/pgtable.h>
 #include <asm/pat.h>
 #include <asm/e820.h>
@@ -477,6 +478,33 @@ pgprot_t phys_mem_access_prot(struct fil
 	return vma_prot;
 }
 
+#ifdef CONFIG_NONPROMISC_DEVMEM
+/* This check is done in drivers/char/mem.c in case of NONPROMISC_DEVMEM*/
+static inline int range_is_allowed(unsigned long pfn, unsigned long size)
+{
+	return 1;
+}
+#else
+static inline int range_is_allowed(unsigned long pfn, unsigned long size)
+{
+	u64 from = ((u64)pfn) << PAGE_SHIFT;
+	u64 to = from + size;
+	u64 cursor = from;
+
+	while (cursor < to) {
+		if (!devmem_is_allowed(pfn)) {
+			printk(KERN_INFO
+		"Program %s tried to access /dev/mem between %Lx->%Lx.\n",
+				current->comm, from, to);
+			return 0;
+		}
+		cursor += PAGE_SIZE;
+		pfn++;
+	}
+	return 1;
+}
+#endif /* CONFIG_NONPROMISC_DEVMEM */
+
 int phys_mem_access_prot_allowed(struct file *file, unsigned long pfn,
 				unsigned long size, pgprot_t *vma_prot)
 {
@@ -485,6 +513,9 @@ int phys_mem_access_prot_allowed(struct 
 	unsigned long ret_flags;
 	int retval;
 
+	if (!range_is_allowed(pfn, size))
+		return 0;
+
 	if (file->f_flags & O_SYNC) {
 		flags = _PAGE_CACHE_UC;
 	}

--
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/