Messages in this thread | | | Date | Sat, 30 May 2009 00:50:33 -0700 | From | "Larry H." <> | Subject | Re: [patch 0/5] Support for sanitization flag in low-level page allocator |
| |
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.
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.
It's called disregard when you ditch something in favor of something else you have assumed to be better, when it isn't. That's not polite.
Furthermore, selective clearing doesn't solve the roots of the problem. It's just adding bandages to a wound which never stops bleeding. I proposed an initial page flag because we could use it later for unconditional page clearing doing a one line change in a header file.
I see a lot of speculation on what works and what doesn't, but there isn't much on the practical side of things, yet. I provided test results that proved some of the comments wrong, and I've referenced literature which shows the reasoning behind all this. What else can I do to make you understand you are missing the point here?
Larry
| |