|From:||Pekka Enberg <penberg-AT-cs.helsinki.fi>|
|To:||"Larry H." <research-AT-subreption.com>|
|Subject:||Re: [patch 0/5] Support for sanitization flag in low-level page allocator|
|Date:||Sat, 30 May 2009 10:53:37 +0300|
|Cc:||Alan Cox <alan-AT-lxorguk.ukuu.org.uk>, Ingo Molnar <mingo-AT-elte.hu>, Rik van Riel <riel-AT-redhat.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>|
Hi Larry, On 10:35 Sat 30 May, Pekka Enberg wrote: >> The GFP_SENSITIVE flag looks like a big hammer that we don't really >> need IMHO. It seems to me that most of the actual call-sites (crypto >> code, wireless keys, etc.) should probably just use kzfree() >> unconditionally to make sure we don't leak sensitive data. I did not >> look too closely but I don't think any of the sensitive kfree() calls >> are in fastpaths so the performance impact is negligible. Larry H. wrote: > That's hopeless, and kzfree is broken. Like I said in my earlier reply, > please test that yourself to see the results. Whoever wrote that ignored > how SLAB/SLUB work and if kzfree had been used somewhere in the kernel > before, it should have been noticed long time ago. An open-coded version of kzfree was being used in the kernel: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-... Can we now get to the part where you explain how it's broken because I obviously "ignored how SLAB/SLUB works"? Thanks! Pekka -- 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