linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: "Larry H." <research@subreption.com>
To: Rik van Riel <riel@redhat.com>
Cc: Ingo Molnar <mingo@elte.hu>,
	linux-kernel@vger.kernel.org, Linus Torvalds <torvalds@osdl.org>,
	linux-mm@kvack.org, Ingo Molnar <mingo@redhat.com>,
	Alan Cox <alan@lxorguk.ukuu.org.uk>,
	pageexec@freemail.hu
Subject: [PATCH] Sanitize memory on kfree() and kmem_cache_free()
Date: Sun, 24 May 2009 18:17:24 -0700	[thread overview]
Message-ID: <20090525011724.GS13971@oblivion.subreption.com> (raw)
In-Reply-To: <4A187BDE.5070601@redhat.com>

(Was Re: [patch 0/5] Support for sanitization flag in low-level page
allocator)

On 18:42 Sat 23 May     , Rik van Riel wrote:
> Ingo Molnar wrote:
>
>> What you are missing is that your patch makes _no technical sense_ if you 
>> allow the same information to leak over the kernel stack. Kernel stacks 
>> can be freed and reused, swapped out and thus 'exposed'.
>
> Kernel stacks may be freed and reused, but Larry's latest
> patch takes care of that by clearing them at page free
> time.

[PATCH] Sanitize memory on kfree() and kmem_cache_free()

This depends on the previous sanitize-mem.patch and implements object
clearing for SLAB and SLUB. Only the SLUB allocator has been tested,
and this patch successfully enforces clearing on kfree() for both
standard caches and private ones (through kmem_cache_free()).

The following test results can be observed when this patch is applied
along sanitize-mem:

   Name 	  Result 	 Object
  ---------------------------------------
   get_free_page 	OK. 	 e4011000
       vmalloc(256) 	OK. 	 e632e000
      vmalloc(2048) 	OK. 	 e6331000
      vmalloc(4096) 	OK. 	 e6334000
      vmalloc(8192) 	OK. 	 e6337000
     vmalloc(32768) 	OK. 	 e633b000
         kmalloc-32 	OK. 	 e5009904
         kmalloc-64 	OK. 	 e404bc04
         kmalloc-96 	OK. 	 e5230b44
        kmalloc-128 	OK. 	 e5221f84
        kmalloc-256 	OK. 	 e4104304
        kmalloc-512 	OK. 	 e40a9804
       kmalloc-1024 	OK. 	 e5137404
       kmalloc-2048 	OK. 	 e5277004
       kmalloc-4096 	OK. 	 e415c004
       kmalloc-8192 	OK. 	 e4092004

Without both:

   Name 	  Result 	 Object
  ---------------------------------------
   get_free_page 	FAILED. 	 e412d000
       vmalloc(256) 	FAILED. 	 e6020000
      vmalloc(2048) 	FAILED. 	 e6023000
      vmalloc(4096) 	FAILED. 	 e6026000
      vmalloc(8192) 	FAILED. 	 e6029000
     vmalloc(32768) 	FAILED. 	 e602d000
         kmalloc-32 	FAILED. 	 e5009924
         kmalloc-64 	FAILED. 	 e5146fc4
         kmalloc-96 	FAILED. 	 e5320d84
        kmalloc-128 	FAILED. 	 e5019484
        kmalloc-256 	FAILED. 	 e4128104
        kmalloc-512 	FAILED. 	 e40df804
       kmalloc-1024 	FAILED. 	 e4a36c04
       kmalloc-2048 	FAILED. 	 e4159004
       kmalloc-4096 	FAILED. 	 e417f004
       kmalloc-8192 	FAILED. 	 e4180004

It takes care of handling empty slabs by ignoring them to avoid
duplication of the clearing operation. In addition, it performs
basic validation of the object and cache pointers, since it is
lacking for kmem_cache_free(). Furthermore, when a cache has
poisoning enabled (SLAB_POISON), the clearing process is skipped,
since poisoning itself will overwrite the object's contents with
a known pattern.

Signed-off-by: Larry Highsmith <research@subreption.com>

---
 mm/slab.c |    9 +++++++++
 mm/slub.c |   32 ++++++++++++++++++++++++++++++++
 2 files changed, 41 insertions(+)

Index: linux-2.6/mm/slab.c
===================================================================
--- linux-2.6.orig/mm/slab.c
+++ linux-2.6/mm/slab.c
@@ -3520,6 +3520,15 @@ static inline void __cache_free(struct k
 	objp = cache_free_debugcheck(cachep, objp, __builtin_return_address(0));
 
 	/*
+	 * If unconditional memory sanitization is enabled, the object is
+	 * cleared before it's put back into the cache. Using obj_offset and
+	 * obj_size we can coexist with the debugging (redzone, poisoning, etc)
+	 * facilities.
+	 */
+	if (sanitize_all_mem)
+		memset(objp + obj_offset(cachep), 0, obj_size(cachep));
+
+	/*
 	 * Skip calling cache_free_alien() when the platform is not numa.
 	 * This will avoid cache misses that happen while accessing slabp (which
 	 * is per page memory  reference) to get nodeid. Instead use a global
Index: linux-2.6/mm/slub.c
===================================================================
--- linux-2.6.orig/mm/slub.c
+++ linux-2.6/mm/slub.c
@@ -1269,6 +1269,36 @@ static inline int lock_and_freeze_slab(s
 }
 
 /*
+ * Slab object sanitization
+ */
+static void sanitize_slab_obj(struct kmem_cache *s, struct page *page, void *object)
+{
+	if (!sanitize_all_mem)
+		return;
+
+	/* SLAB_POISON makes clearing unnecessary */
+	if (s->offset || unlikely(s->flags & SLAB_POISON))
+		return;
+
+	/*
+	 * The slab is empty, it will be returned to page allocator by
+	 * discard_slab()->__slab_free(). It will be cleared there, thus
+	 * we skip it here.
+	 */
+	if (unlikely(!page->inuse))
+		return;
+
+	/* Validate that pointer indeed belongs to slab page */
+	if (!PageSlab(page) || (page->slab != s))
+		return;
+
+	if (!check_valid_pointer(s, page, object))
+		return;
+
+	memset(object, 0, s->objsize);
+}
+
+/*
  * Try to allocate a partial slab from a specific node.
  */
 static struct page *get_partial_node(struct kmem_cache_node *n)
@@ -1741,6 +1771,7 @@ void kmem_cache_free(struct kmem_cache *
 
 	page = virt_to_head_page(x);
 
+	sanitize_slab_obj(s, page, x);
 	slab_free(s, page, x, _RET_IP_);
 }
 EXPORT_SYMBOL(kmem_cache_free);
@@ -2752,6 +2783,7 @@ void kfree(const void *x)
 		put_page(page);
 		return;
 	}
+	sanitize_slab_obj(page->slab, page, object);
 	slab_free(page->slab, page, object, _RET_IP_);
 }
 EXPORT_SYMBOL(kfree);

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2009-05-25  1:18 UTC|newest]

Thread overview: 114+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-05-20 18:30 [patch 0/5] Support for sanitization flag in low-level page allocator Larry H.
2009-05-20 20:42 ` Peter Zijlstra
2009-05-20 21:24   ` Larry H.
2009-05-21 15:21     ` Robin Holt
2009-05-21 18:43       ` Larry H.
2009-05-29 22:58     ` Andrew Morton
2009-05-30  7:00       ` Larry H.
2009-05-30  7:12       ` Pekka Enberg
2009-05-30  7:35         ` Larry H.
2009-05-30  7:39           ` Pekka Enberg
2009-05-21 19:08   ` Rik van Riel
2009-05-21 19:26     ` Alan Cox
2009-05-21 19:56       ` Larry H.
2009-05-21 20:47         ` Alan Cox
2009-05-21 21:46           ` Larry H.
2009-05-21 22:47             ` Alan Cox
2009-05-22 11:22               ` Larry H.
2009-05-22 13:37                 ` Alan Cox
2009-05-26 19:02       ` Pavel Machek
2009-05-21 19:17 ` Rik van Riel
2009-05-21 19:30   ` Larry H.
2009-05-22  7:34   ` Ingo Molnar
2009-05-22 11:38     ` Larry H.
2009-05-22 13:39       ` Alan Cox
2009-05-22 18:03         ` Larry H.
2009-05-22 18:21           ` Alan Cox
2009-05-22 23:25             ` [PATCH] Support for kernel memory sanitization Larry H.
2009-05-22 23:52               ` Randy Dunlap
2009-05-22 23:40             ` [patch 0/5] Support for sanitization flag in low-level page allocator Larry H.
2009-05-23  8:09               ` Alan Cox
2009-05-23 15:56                 ` Arjan van de Ven
2009-05-23 18:21                   ` [PATCH] Support for unconditional page sanitization Larry H.
2009-05-23 21:05                     ` Arjan van de Ven
2009-05-24 10:19                       ` pageexec
2009-05-24 16:38                         ` Arjan van de Ven
2009-05-28 19:36                   ` [patch 0/5] Support for sanitization flag in low-level page allocator Peter Zijlstra
2009-05-29 14:32                     ` Arjan van de Ven
2009-05-30  5:48                       ` Larry H.
2009-05-30 10:39                         ` Peter Zijlstra
2009-05-30 10:43                           ` Larry H.
2009-05-30 11:42                           ` pageexec
2009-05-30 13:21                             ` Peter Zijlstra
2009-05-30 13:24                               ` Peter Zijlstra
2009-05-30 13:54                               ` pageexec
2009-05-30 14:04                                 ` Larry H.
2009-05-30 14:13                                 ` Rik van Riel
2009-05-30 14:08                               ` Rik van Riel
2009-05-30 14:30                               ` Alan Cox
2009-05-30 14:45                                 ` Peter Zijlstra
2009-05-30 14:48                                   ` Rik van Riel
2009-05-30 17:00                                     ` Larry H.
2009-05-30 17:25                                       ` Larry H.
2009-05-30 18:32                                         ` Ingo Molnar
2009-06-05 13:15                                   ` Pavel Machek
2009-05-31 14:38                           ` Arjan van de Ven
2009-05-31 15:03                             ` Arjan van de Ven
2009-05-22 18:37           ` Nai Xia
2009-05-22 19:18           ` Nai Xia
2009-05-23 12:49       ` Ingo Molnar
2009-05-23 22:28         ` Larry H.
2009-05-23 22:42         ` Rik van Riel
2009-05-25  1:17           ` Larry H. [this message]
2009-05-27 22:34           ` Ingo Molnar
2009-05-28  6:27             ` Alan Cox
2009-05-28  7:00               ` Larry H.
2009-05-28  9:08               ` Ingo Molnar
2009-05-28 11:50                 ` Alan Cox
2009-05-28 19:44                   ` Peter Zijlstra
2009-05-30  7:35                   ` Pekka Enberg
2009-05-30  7:50                     ` Larry H.
2009-05-30  7:53                       ` Pekka Enberg
2009-05-30  8:20                         ` Larry H.
2009-05-30  8:33                           ` Pekka Enberg
2009-05-30 15:05                           ` Ray Lee
2009-05-30 17:34                           ` Ingo Molnar
2009-05-30 18:03                             ` Larry H.
2009-05-30 18:21                               ` Ingo Molnar
2009-05-30 18:45                                 ` Larry H.
2009-05-30 19:08                                   ` Ingo Molnar
2009-05-30 20:39                                     ` Rik van Riel
2009-05-30 20:53                                       ` Pekka Enberg
2009-05-30 21:33                                         ` Larry H.
2009-05-30 23:13                                           ` Alan Cox
2009-05-30 23:18                                             ` Larry H.
2009-05-31  6:30                                               ` Pekka Enberg
2009-05-31 11:49                                                 ` Larry H.
2009-05-31  7:17                                           ` Pekka Enberg
2009-05-31 11:58                                             ` Larry H.
2009-05-31 12:16                                               ` Pekka Enberg
2009-05-31 12:30                                                 ` Larry H.
2009-05-31 12:35                                                   ` Pekka Enberg
2009-05-30 23:10                                         ` Alan Cox
2009-05-31  6:14                                           ` Pekka Enberg
2009-05-31 10:24                                             ` Alan Cox
2009-05-31 10:24                                               ` Pekka Enberg
2009-05-31 12:16                                             ` Larry H.
2009-05-31 12:19                                               ` Pekka Enberg
2009-05-31 16:25                                               ` Alan Cox
2009-05-30 22:10                                       ` Ingo Molnar
2009-05-30 23:15                                         ` Alan Cox
2009-05-30 20:22                               ` Pekka Enberg
2009-05-30 22:14                                 ` Ingo Molnar
2009-05-30 17:39                         ` Ingo Molnar
2009-05-30  7:57                       ` Pekka Enberg
2009-05-30  9:05                         ` Larry H.
2009-05-30 17:46                           ` Ingo Molnar
2009-05-30 18:09                             ` Larry H.
2009-05-30  8:31                     ` Alan Cox
2009-05-30  8:35                       ` Pekka Enberg
2009-05-30  9:27                         ` Larry H.
2009-05-28 18:48                 ` pageexec
2009-05-30 17:50                   ` Ingo Molnar
2009-05-28 12:48 ` Pavel Machek
2009-05-28 12:55   ` Larry H.

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=20090525011724.GS13971@oblivion.subreption.com \
    --to=research@subreption.com \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mingo@elte.hu \
    --cc=mingo@redhat.com \
    --cc=pageexec@freemail.hu \
    --cc=riel@redhat.com \
    --cc=torvalds@osdl.org \
    /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