[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150519143540.70410b94@lxorguk.ukuu.org.uk>
Date: Tue, 19 May 2015 14:35:40 +0100
From: One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>
To: Mel Gorman <mgorman@...e.de>
Cc: Anisse Astier <anisse@...ier.eu>,
Andrew Morton <akpm@...ux-foundation.org>,
"Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>,
David Rientjes <rientjes@...gle.com>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Peter Zijlstra <peterz@...radead.org>,
PaX Team <pageexec@...email.hu>,
Brad Spengler <spender@...ecurity.net>,
Kees Cook <keescook@...omium.org>,
Andi Kleen <andi@...stfloor.org>,
"Rafael J. Wysocki" <rjw@...ysocki.net>,
Pavel Machek <pavel@....cz>, Len Brown <len.brown@...el.com>,
linux-mm@...ck.org, linux-pm@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH v4 0/3] Sanitizing freed pages
> may be some benefits in some cases, I think it's a weak justification for
> always zeroing pages on free.
There are much better reasons for zero on free, including the improved
latency when pages are faulted in. For virtualisation there are two
interfaces that would probably make more sense
1. 'This page is of no further interest, you may fault it back in
as random data'
2. 'This page is discardable, if I touch it *and* you have
discarded it then please serve me an exception, if you've not discarded
it them give it me back"
If I remember my 390 bits the S/390 goes further including the ability to
say "if I think this page is in memory but in fact the hypervisor is
going to page it off disc then throw me an exception so I can do clever
things with the delay time"
> > - finally, it can reduce infoleaks, although this is hard to measure.
> >
> It obscures them.
Actually not. If you are doing debug work you zero on free and check for
mysterious non zeroing before reusing the page. Without that its a win in
the sense it wipes material (but crypto does that anyway), but it
replaces that with the risk of a zeroed page being scibbled upon by the
kernel and leaking kernel scribbles into allocated user pages.
Alan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists