All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rik van Riel <riel@redhat.com>
To: Kees Cook <keescook@chromium.org>
Cc: kernel-hardening@lists.openwall.com,
	Brad Spengler <spender@grsecurity.net>,
	PaX Team <pageexec@freemail.hu>,
	Casey Schaufler <casey.schaufler@intel.com>,
	Christoph Lameter <cl@linux.com>,
	Pekka Enberg <penberg@kernel.org>,
	David Rientjes <rientjes@google.com>,
	Joonsoo Kim <iamjoonsoo.kim@lge.com>,
	Andrew Morton <akpm@linux-foundation.org>
Subject: [kernel-hardening] [RFC][PATCH 6/4] mm: disallow user copy to/from separately allocated pages
Date: Thu, 9 Jun 2016 19:39:27 -0400	[thread overview]
Message-ID: <20160609193927.2f03f128@annuminas.surriel.com> (raw)
In-Reply-To: <1465420302-23754-1-git-send-email-keescook@chromium.org>

This patch is some new functionality for the usercopy hardening
method. I hope it will be useful both to the mainline community
and the grsecurity community.

I have not figured out what to do about CMA yet, but that can
probably be done in a follow-up patch.

---8<---

Subject: mm: disallow user copy to/from separately allocated pages

A single copy_from_user or copy_to_user should go to or from a single
kernel object. Inside the slab, or on the stack, we can track the
individual objects.

For the general kernel heap, we do not know exactly where each object
is, but we can tell whether the whole range from ptr to ptr + n is
inside the same page, or inside the same compound page.

If the start and end of the "object" are in pages that were not allocated
together, we are likely dealing with an overflow from one object into
the next page, and should disallow this copy.

The kernel will have some objects that cross page boundaries in
sections like .rodata, .bss, etc.  Copying from those needs to be
allowed; they can be identified with PageReserved.

TODO: figure out what to do with CMA memory

Signed-off-by: Rik van Riel <riel@redhat.com>
---
 mm/usercopy.c | 23 +++++++++++++++++++----
 2 files changed, 20 insertions(+), 5 deletions(-)

diff --git a/mm/usercopy.c b/mm/usercopy.c
index e09c33070759..be75d97c5d75 100644
--- a/mm/usercopy.c
+++ b/mm/usercopy.c
@@ -109,7 +109,7 @@ static inline bool check_kernel_text_object(const void *ptr, unsigned long n)
 
 static inline const char *check_heap_object(const void *ptr, unsigned long n)
 {
-	struct page *page;
+	struct page *page, *endpage;
 
 	if (ZERO_OR_NULL_PTR(ptr))
 		return "<null>";
@@ -118,11 +118,26 @@ static inline const char *check_heap_object(const void *ptr, unsigned long n)
 		return NULL;
 
 	page = virt_to_head_page(ptr);
-	if (!PageSlab(page))
+	if (PageSlab(page))
+		/* Check allocator for flags and size. */
+		return __check_heap_object(ptr, n, page);
+
+	/* Is the object wholly within one base page? Great. */
+	if (likely(((unsigned long)ptr & (unsigned long)PAGE_MASK) ==
+		   ((unsigned long)(ptr + n - 1) & (unsigned long)PAGE_MASK)))
+		return NULL;
+
+	/* Are the start and end inside the same compound page? Great. */
+	endpage = virt_to_head_page(ptr + n - 1);
+	if (likely(endpage == page))
+		return NULL;
+
+	/* Is this a special area, eg. .rodata, .bss, or device memory? */
+	if (PageReserved(page) && PageReserved(endpage))
 		return NULL;
 
-	/* Check allocator for flags and size. */
-	return __check_heap_object(ptr, n, page);
+	/* Uh oh. The "object" spans several independently allocated pages. */
+	return "<spans multiple pages>";
 }
 
 /*

  parent reply	other threads:[~2016-06-09 23:39 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-08 21:11 [kernel-hardening] [RFC][PATCH v2 0/4] mm: Hardened usercopy Kees Cook
2016-06-08 21:11 ` [kernel-hardening] [PATCH v2 1/4] " Kees Cook
2016-06-09  0:47   ` [kernel-hardening] " Brad Spengler
2016-06-09  1:39     ` Rik van Riel
2016-06-09  2:58     ` Kees Cook
2016-07-12 23:04   ` Kees Cook
2016-06-08 21:11 ` [kernel-hardening] [PATCH v2 2/4] usercopy: avoid direct copying to userspace Kees Cook
2016-06-09 23:37   ` [kernel-hardening] " Rik van Riel
2016-06-10 21:09   ` Kees Cook
2016-06-11  1:08     ` Rik van Riel
2016-06-08 21:11 ` [kernel-hardening] [PATCH v2 3/4] usercopy: whitelist user-copyable caches Kees Cook
2016-06-08 21:11 ` [kernel-hardening] [PATCH v2 4/4] usercopy: provide split of user-controlled slabs Kees Cook
2016-06-09  3:02 ` [kernel-hardening] [RFC][PATCH v2 5/4] arm: fixes for usercopy Kees Cook
2016-06-09 15:35 ` [kernel-hardening] RE: [RFC][PATCH v2 0/4] mm: Hardened usercopy Schaufler, Casey
2016-06-09 17:48   ` [kernel-hardening] " Kees Cook
2016-06-09 23:39 ` Rik van Riel [this message]
2016-06-10 19:44   ` [kernel-hardening] [RFC][PATCH v2 6/4] mm: disallow user copy to/from separately allocated pages Rik van Riel
2016-06-10 20:46     ` [kernel-hardening] " Kees Cook
2016-06-24 20:53     ` Kees Cook
2016-06-24 20:57       ` Rik van Riel
2016-06-24 20:59         ` Kees Cook
2016-06-16  1:30 ` [kernel-hardening] [RFC][PATCH v2 0/4] mm: Hardened usercopy Valdis.Kletnieks
2016-06-16  1:38   ` Kees Cook
2016-06-16 23:36     ` Valdis.Kletnieks
2016-06-17  1:38       ` Valdis.Kletnieks
2016-06-18 19:30         ` Kees Cook

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=20160609193927.2f03f128@annuminas.surriel.com \
    --to=riel@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=casey.schaufler@intel.com \
    --cc=cl@linux.com \
    --cc=iamjoonsoo.kim@lge.com \
    --cc=keescook@chromium.org \
    --cc=kernel-hardening@lists.openwall.com \
    --cc=pageexec@freemail.hu \
    --cc=penberg@kernel.org \
    --cc=rientjes@google.com \
    --cc=spender@grsecurity.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 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.