linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Dave Hansen <dave.hansen@intel.com>
To: kernel-hardening@lists.openwall.com, Laura Abbott <laura@labbott.name>
Cc: Pekka Enberg <penberg@kernel.org>,
	David Rientjes <rientjes@google.com>,
	Joonsoo Kim <iamjoonsoo.kim@lge.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	Kees Cook <keescook@chromium.org>
Subject: Re: [kernel-hardening] Re: [RFC][PATCH 0/7] Sanitization of slabs based on grsecurity/PaX
Date: Tue, 22 Dec 2015 08:15:55 -0800	[thread overview]
Message-ID: <5679773B.6040903@intel.com> (raw)
In-Reply-To: <alpine.DEB.2.20.1512220952350.2114@east.gentwo.org>

On 12/22/2015 08:08 AM, Christoph Lameter wrote:
> 2. Add a mechanism that ensures that GFP_ZERO is set for each allocation.
>    That way every object you retrieve is zeroed and thus you have implied
>    sanitization. This also can be done in a rather simple way by changing
>    the  GFP_KERNEL etc constants to include __GFP_ZERO depending on a
>    Kconfig option. Or add some runtime setting of the gfp flags somewhere.

That's a more comprehensive barrier to leaking information than what we
have now, and it would _also_ cover a big chunk of normal
alloc_page()-style allocations which would be nice.

But, doing this on the allocation side is less comprehensive than doing
at free() time.  We (ideally) want to make sure that unallocated memory
at rest does not contain sensitive contents.

Also, the free path _tends_ to be a bit less performance-critical than
the allocation side.  For instance, I think we generally care about
fork() performance a lot more than exit(). :)

--
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:[~2015-12-22 16:15 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-22  3:40 [RFC][PATCH 0/7] Sanitization of slabs based on grsecurity/PaX Laura Abbott
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   ` Dave Hansen [this message]
2015-12-22 16:38   ` [kernel-hardening] " 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=5679773B.6040903@intel.com \
    --to=dave.hansen@intel.com \
    --cc=akpm@linux-foundation.org \
    --cc=iamjoonsoo.kim@lge.com \
    --cc=keescook@chromium.org \
    --cc=kernel-hardening@lists.openwall.com \
    --cc=laura@labbott.name \
    --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).