Messages in this thread | | | Date | Sat, 30 May 2009 19:39:06 +0200 | From | Ingo Molnar <> | Subject | Re: [patch 0/5] Support for sanitization flag in low-level page allocator |
| |
* Pekka Enberg <penberg@cs.helsinki.fi> wrote:
> 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-2.6.git;a=commitdiff;h=00fcf2cb6f6bb421851c3ba062c0a36760ea6e53 > > Can we now get to the part where you explain how it's broken > because I obviously "ignored how SLAB/SLUB works"?
Yeah, kzfree() sounds like the right approach for all places that know it for sure that they dont want information to persist.
Ingo
| |