|| ||Alan Cox <alan-AT-lxorguk.ukuu.org.uk> |
|| ||Ingo Molnar <mingo-AT-elte.hu> |
|| ||Re: [patch 0/5] Support for sanitization flag in low-level page
|| ||Thu, 28 May 2009 12:50:42 +0100|
|| ||Rik van Riel <riel-AT-redhat.com>, "Larry H." <research-AT-subreption.com>,
linux-kernel-AT-vger.kernel.org, Linus Torvalds <torvalds-AT-osdl.org>,
linux-mm-AT-kvack.org, Ingo Molnar <mingo-AT-redhat.com>,
pageexec-AT-freemail.hu, Linus Torvalds <torvalds-AT-linux-foundation.org>|
|| ||Article, Thread
> > In most respects the benchmarks are pretty irrelevant - wiping
> > stuff has a performance cost, but its the sort of thing you only
> > want to do when you have a security requirement that needs it. At
> > that point the performance is secondary.
> Bechmarks, of course, are not irrelevant _at all_.
> So i'm asking for this "clear kernel stacks on freeing" aspect to be
> benchmarked thoroughly, as i expect it to have a negative impact -
> otherwise i'm NAK-ing this.
Ingo you are completely missing the point
The performance cost of such a security action are NIL when the feature
is disabled. So the performance cost in the general case is irrelevant.
If you need this kind of data wiping then the performance hit
is basically irrelevant, the security comes first. You can NAK it all you
like but it simply means that such users either have to apply patches or
run something else.
If it harmed general user performance you'd have a point - but its like
SELinux you don't have to use it if you don't need the feature. Which it
must be said is a lot better than much of the scheduler crud that has
appeared over time which you can't make go away.
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to email@example.com. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"firstname.lastname@example.org"> email@example.com </a>
to post comments)