|From:||Alan Cox <alan-AT-lxorguk.ukuu.org.uk>|
|To:||Ingo Molnar <mingo-AT-elte.hu>|
|Subject:||Re: [patch 0/5] Support for sanitization flag in low-level page allocator|
|Date:||Thu, 28 May 2009 12:50:42 +0100|
|Cc:||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>|
> > 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>
Copyright © 2009, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds