From: "PaX Team" <pageexec@freemail.hu>
To: Anisse Astier <anisse@astier.eu>, Mel Gorman <mgorman@suse.de>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
	David Rientjes <rientjes@google.com>,
	Alan Cox <gnomes@lxorguk.ukuu.org.uk>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Peter Zijlstra <peterz@infradead.org>,
	Brad Spengler <spender@grsecurity.net>,
	Kees Cook <keescook@chromium.org>,
	Andi Kleen <andi@firstfloor.org>,
	"Rafael J. Wysocki" <rjw@rjwysocki.net>,
	Pavel Machek <pavel@ucw.cz>, Len Brown <len.brown@intel.com>,
	linux-mm@kvack.org, linux-pm@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v4 0/3] Sanitizing freed pages
Date: Tue, 19 May 2015 22:59:16 +0200	[thread overview]
Message-ID: <555BA424.2410.2365DFC8@pageexec.freemail.hu> (raw)
In-Reply-To: <20150519124644.GD2462@suse.de>
On 19 May 2015 at 13:46, Mel Gorman wrote:
> On Thu, May 14, 2015 at 04:19:45PM +0200, Anisse Astier wrote:
> > Hi,
> > 
> > I'm trying revive an old debate here[1], though with a simpler approach than
> > was previously tried. This patch series implements a new option to sanitize
> > freed pages, a (very) small subset of what is done in PaX/grsecurity[3],
> > inspired by a previous submission [4].
> > 
> > There are a few different uses that this can cover:
> >  - some cases of use-after-free could be detected (crashes), although this not
> >    as efficient as KAsan/kmemcheck
> 
> They're not detected, they're hidden.
this is a qualitative argument that cuts both ways. namely, you could say
that uninitialized memory does *not* trigger any bad behaviour exactly
because the previous content acts as valid data (say, a valid pointer)
whereas a null dereference would pretty much always crash (both in userland
and the kernel). not to mention that a kernel null deref is no longer an
exploitable bug in many/most situations which can't be said of arbitrary
uninitialized (read: potentially attacker controlled) values.
that said, i always considered this aspect of page sanitization as a
(potentially useful) side effect, not the design goal.
> >  - finally, it can reduce infoleaks, although this is hard to measure.
> > 
> 
> It obscures them.
i don't understand, what is being obscured exactly? maybe the term 'infoleaks'
is ambiguous, in case of page sanitization it refers to the reduction of data
lifetime (mostly userland anonymous memory, as per the original design). if
you were thinking of kernel->userland kind of leaks then i'd say that page
sanitization has little effect there because all the bugs i can think of were
not leaking from freed memory (where sanitization would have prevented the
leak).
--
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 prev parent reply	other threads:[~2015-05-19 21:01 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-14 14:19 [PATCH v4 0/3] Sanitizing freed pages Anisse Astier
2015-05-14 14:19 ` [PATCH v4 1/3] PM / Hibernate: prepare for SANITIZE_FREED_PAGES Anisse Astier
2015-05-16  0:28   ` Rafael J. Wysocki
2015-05-18 10:23     ` Anisse Astier
2015-05-19 23:46       ` Rafael J. Wysocki
2015-05-20 11:45         ` PaX Team
2015-05-20 12:07           ` Anisse Astier
2015-05-21  1:11             ` Rafael J. Wysocki
2015-05-20 11:57         ` Anisse Astier
2015-05-14 14:19 ` [PATCH v4 2/3] mm/page_alloc.c: add config option to sanitize freed pages Anisse Astier
2015-05-18 11:21   ` Pavel Machek
2015-05-18 12:41     ` Anisse Astier
2015-05-18 13:02       ` Pavel Machek
2015-05-18 13:04         ` Anisse Astier
2015-05-19  1:58           ` yalin wang
2015-05-20 12:27             ` Anisse Astier
2015-05-14 14:19 ` [PATCH v4 3/3] mm: Add debug code for SANITIZE_FREED_PAGES Anisse Astier
2015-05-19 12:46 ` [PATCH v4 0/3] Sanitizing freed pages Mel Gorman
2015-05-19 13:35   ` One Thousand Gnomes
2015-05-19 13:56     ` Mel Gorman
2015-05-19 20:59   ` PaX Team [this message]
2015-05-20 12:24   ` Anisse Astier
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=555BA424.2410.2365DFC8@pageexec.freemail.hu \
    --to=pageexec@freemail.hu \
    --cc=akpm@linux-foundation.org \
    --cc=andi@firstfloor.org \
    --cc=anisse@astier.eu \
    --cc=gnomes@lxorguk.ukuu.org.uk \
    --cc=keescook@chromium.org \
    --cc=kirill.shutemov@linux.intel.com \
    --cc=len.brown@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=mgorman@suse.de \
    --cc=pavel@ucw.cz \
    --cc=peterz@infradead.org \
    --cc=rientjes@google.com \
    --cc=rjw@rjwysocki.net \
    --cc=spender@grsecurity.net \
    --cc=torvalds@linux-foundation.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;
as well as URLs for NNTP newsgroup(s).