Messages in this thread | | | Date | Sat, 23 May 2009 15:28:13 -0700 | From | "Larry H." <> | Subject | Re: [patch 0/5] Support for sanitization flag in low-level page allocator |
| |
On 14:49 Sat 23 May , Ingo Molnar wrote: > You need to address my specific concerns instead of referring back > to an earlier discussion. The patches touch code i maintain and i > find them (and your latest resend) unacceptable.
Meaning the latest boot option-based unconditional sanitization which doesn't touch anything else and doesn't duplicate clearing (it only performs such during release)?
> Naming _is_ a technical issue. Especially here.
True, that's no more of an issue since the page flag approach has been left out of the patch (albeit it mutilates our possibilities to do fine-grained clearing and track status across the different higher level interfaces through the gfp flag). Do you still have a problem with something related to naming?
If any of the variable names still don't catch your fancy, please let me know.
> What you are missing is that your patch makes _no technical sense_ > if you allow the same information to leak over the kernel stack. > Kernel stacks can be freed and reused, swapped out and thus > 'exposed'.
Do you have technical evidence to back up that claim? Perhaps an analysis and testcase that demonstrates true resilience of the kernel stack information? Something that can convince me I'm mistaken by showing that it isn't extremely volatile? That it doesn't get overwritten to smithereens?
I have a simple testcase for vmalloc/kmalloc/page allocator sanitization. The current patch covers both vmalloc and page allocators well, since the former is basically dependent on the latter. kmalloc still won't get sanitized until the slab is returned to the page allocator (during cache shrink/reaping or when it becomes empty).
Also, a political question, are you the only current maintainer of the affected code, or there are more people who might not necessarily share your opinion on this?
Larry
| |