From: Laura Abbott <laura@labbott.name>
To: 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>
Cc: Laura Abbott <laura@labbott.name>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
Kees Cook <keescook@chromium.org>,
kernel-hardening@lists.openwall.com
Subject: [RFC][PATCH 0/7] Sanitization of slabs based on grsecurity/PaX
Date: Mon, 21 Dec 2015 19:40:34 -0800 [thread overview]
Message-ID: <1450755641-7856-1-git-send-email-laura@labbott.name> (raw)
Hi,
This is a partial port of the PAX_MEMORY_SANITIZE feature. The concept is
fairly simple: when memory is freed, existing data should be erased. This
helps to reduce the impact of problems
(e.g. 45a22f4 inotify: Fix reporting of cookies for inotify events
e4514cb RDMA/cxgb3: Fix information leak in send_abort()
your favorite use after free bug)
The biggest change from PAX_MEMORY_SANTIIZE is that this feature sanitizes
the SL[AOU]B allocators only. My plan is to work on the buddy allocator
santization after this series gets picked up. A side effect of this is
that allocations which go directly to the buddy allocator (i.e. large
allocations) aren't sanitized. I'd like feedback about whether it's worth
it to add sanitization on that path directly or just use the page
allocator sanitization when that comes in.
I also expanded the command line options, mostly for SLUB. Since SLUB
has had so much tuning work done for performance, I added an option
to only sanitize on the slow path. Freeing on only fast vs. slow path
was most noticable in the bulk test cases. Overall, I saw impacts of
3% to 20% on various benchmarks when this feature was enabled. The
overall impact of sanitize_slab=off seemed to be pretty negligable.
This feature is similar to the debug feature of SLAB_POISON. I did
consider trying to make that feature not related to debug. Ultimately,
I concluded there was too much extra debug overhead and other features
to make it worth it.
Bike shed whatever you like. The Kconfig will probably end up in
a separate sanitization Kconfig.
All credit for the original work should be given to Brad Spengler and
the PaX Team.
Thanks,
Laura
Laura Abbott (7):
mm/slab_common.c: Add common support for slab saniziation
slub: Add support for sanitization
slab: Add support for sanitization
slob: Add support for sanitization
mm: Mark several cases as SLAB_NO_SANITIZE
mm: Add Kconfig option for slab sanitization
lkdtm: Add READ_AFTER_FREE test
drivers/misc/lkdtm.c | 29 ++++++++++++++++
fs/buffer.c | 2 +-
fs/dcache.c | 2 +-
include/linux/slab.h | 7 ++++
include/linux/slab_def.h | 4 +++
init/Kconfig | 48 ++++++++++++++++++++++++++
kernel/fork.c | 2 +-
mm/rmap.c | 4 +--
mm/slab.c | 35 +++++++++++++++++++
mm/slab.h | 24 ++++++++++++-
mm/slab_common.c | 53 ++++++++++++++++++++++++++++
mm/slob.c | 27 +++++++++++----
mm/slub.c | 90 +++++++++++++++++++++++++++++++++++++++++++++++-
net/core/skbuff.c | 4 +--
14 files changed, 316 insertions(+), 15 deletions(-)
--
2.5.0
--
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>
next reply other threads:[~2015-12-22 3:40 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-22 3:40 Laura Abbott [this message]
2015-12-22 3:40 ` [RFC][PATCH 1/7] mm/slab_common.c: Add common support for slab saniziation Laura Abbott
2015-12-22 20:48 ` Vlastimil Babka
2016-01-06 0:17 ` Kees Cook
2016-01-06 2:06 ` Laura Abbott
2016-01-06 0:19 ` Kees Cook
2015-12-22 3:40 ` [RFC][PATCH 2/7] slub: Add support for sanitization Laura Abbott
2015-12-22 3:40 ` [RFC][PATCH 3/7] slab: " Laura Abbott
2015-12-22 3:40 ` [RFC][PATCH 4/7] slob: " Laura Abbott
2015-12-22 3:40 ` [RFC][PATCH 5/7] mm: Mark several cases as SLAB_NO_SANITIZE Laura Abbott
2016-01-06 0:21 ` Kees Cook
2016-01-06 2:11 ` Laura Abbott
2015-12-22 3:40 ` [RFC][PATCH 6/7] mm: Add Kconfig option for slab sanitization Laura Abbott
2015-12-22 9:33 ` [kernel-hardening] " Mathias Krause
2015-12-22 17:51 ` Laura Abbott
2015-12-22 18:37 ` Mathias Krause
2015-12-22 19:18 ` Laura Abbott
2015-12-22 20:01 ` Christoph Lameter
2015-12-22 20:06 ` Mathias Krause
2015-12-22 14:57 ` Dave Hansen
2015-12-22 16:25 ` Christoph Lameter
2015-12-22 17:22 ` Dave Hansen
2015-12-22 17:24 ` Christoph Lameter
2015-12-22 17:28 ` Dave Hansen
2015-12-22 18:08 ` Christoph Lameter
2015-12-22 18:19 ` Dave Hansen
2015-12-22 19:13 ` Laura Abbott
2015-12-22 19:32 ` Dave Hansen
2016-01-06 0:29 ` Kees Cook
2016-01-06 2:46 ` Laura Abbott
2015-12-22 3:40 ` [RFC][PATCH 7/7] lkdtm: Add READ_AFTER_FREE test Laura Abbott
2016-01-06 0:15 ` Kees Cook
2016-01-06 2:49 ` Laura Abbott
2015-12-22 16:08 ` [RFC][PATCH 0/7] Sanitization of slabs based on grsecurity/PaX Christoph Lameter
2015-12-22 16:15 ` [kernel-hardening] " Dave Hansen
2015-12-22 16:38 ` Daniel Micay
2015-12-22 20:04 ` Laura Abbott
2016-01-06 0:09 ` Kees Cook
2016-01-06 3:17 ` Laura Abbott
2016-01-07 16:26 ` Christoph Lameter
2016-01-08 1:23 ` Laura Abbott
2016-01-08 14:07 ` Christoph Lameter
2016-01-14 3:49 ` Laura Abbott
2016-01-21 3:35 ` Laura Abbott
2016-01-21 15:39 ` Christoph Lameter
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=1450755641-7856-1-git-send-email-laura@labbott.name \
--to=laura@labbott.name \
--cc=akpm@linux-foundation.org \
--cc=cl@linux.com \
--cc=iamjoonsoo.kim@lge.com \
--cc=keescook@chromium.org \
--cc=kernel-hardening@lists.openwall.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=penberg@kernel.org \
--cc=rientjes@google.com \
/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;
as well as URLs for NNTP newsgroup(s).