linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: "PaX Team" <pageexec@freemail.hu>
To: Andi Kleen <andi@firstfloor.org>, Anisse Astier <anisse@astier.eu>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Mel Gorman <mgorman@suse.de>,
	"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>,
	linux-mm@kvack.org,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 2/2] mm/page_alloc.c: add config option to sanitize freed pages
Date: Mon, 27 Apr 2015 11:25:57 +0200	[thread overview]
Message-ID: <553E00A5.370.3E3700BE@pageexec.freemail.hu> (raw)
In-Reply-To: <CALUN=qL6X=RXyTmxezFDzif+3PZCykpB0mT9hkbgAab4vV59sg@mail.gmail.com>

On 27 Apr 2015 at 10:11, Anisse Astier wrote:

> >> +#ifdef CONFIG_SANITIZE_FREED_PAGES
> >> +     zero_pages(page, order);
> >> +#endif
> >
> > And not removing the clear on __GFP_ZERO by remembering that?
> >
> > That means all clears would be done twice.
> >
> > That patch is far too simple. Clearing is commonly the most
> > expensive kernel operation.
> >
> 
> I thought about this, but if you unconditionally remove the clear on
> __GFP_ZERO, you wouldn't be guaranteed to have a zeroed page when
> memory is first used (you would protect the kernel from its own info
> leaks though);

the PaX SANITIZE feature does exactly this in mm/page_alloc.c:prep_new_page:

#ifndef CONFIG_PAX_MEMORY_SANITIZE
	if (gfp_flags & __GFP_ZERO)
		prep_zero_page(page, order, gfp_flags);
#endif

> you'd need to clear memory on boot for example.

it happens automagically because on boot during the transition from the
boot allocator to the buddy one each page gets freed which will then go
through the page clearing path.

however there's a known problem/conflict with HIBERNATION (see
http://marc.info/?l=linux-pm&m=132871433416256&w=2) which i think would
have to be resolved before upstream acceptance.

cheers,
 PaX Team

--
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-04-27  9:27 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-24 21:05 [PATCH 0/2] Sanitizing " Anisse Astier
2015-04-24 21:05 ` [PATCH 1/2] mm/page_alloc.c: cleanup obsolete KM_USER* Anisse Astier
2015-04-24 21:36   ` David Rientjes
2015-04-25 13:43     ` Anisse Astier
2015-04-24 21:05 ` [PATCH 2/2] mm/page_alloc.c: add config option to sanitize freed pages Anisse Astier
2015-04-24 21:38   ` David Rientjes
2015-04-25 13:52     ` Anisse Astier
2015-04-26 20:12   ` Andi Kleen
2015-04-27  8:11     ` Anisse Astier
2015-04-27  9:25       ` PaX Team [this message]
2015-04-27 21:27         ` 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=553E00A5.370.3E3700BE@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=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mgorman@suse.de \
    --cc=peterz@infradead.org \
    --cc=rientjes@google.com \
    --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