Messages in this thread | | | Date | Sun, 31 May 2009 10:17:31 +0300 | Subject | Re: [patch 0/5] Support for sanitization flag in low-level page allocator | From | Pekka Enberg <> |
| |
On Sun, May 31, 2009 at 12:33 AM, Larry H. <research@subreption.com> wrote: > While we are at it, did any of you (Pekka, Ingo, Peter) bother reading > the very first paper I referenced in the very first patch?: > > http://www.stanford.edu/~blp/papers/shredding.html/#kernel-appendix > > Could you _please_ bother your highness with an earthly five minutes > read of that paper? If you don't have other magnificent obligations to > attend to. _Please_. > > PS: I'm still thanking myself for not implementing the kthread / > multiple page pool based approach. Lord, what could have happened if I > did.
Something like that might make sense for fast-path code.
I think we could make GFP_SENSITIVE mean that allocations using it force the actual slab pages to be cleaned up before they're returned to the page allocator. As far as I can tell, we could then recycle those slab pages to GFP_SENSITIVE allocations without any clearing whatsoever as long as they're managed by slab. This ensures critical data in kmalloc()'d memory is never leaked to userspace.
This doesn't fix all the cases Alan pointed out (unconditional memset() in page free is clearly superior from security pov) but should allow us to use GFP_SENSITIVE in fast-path cases where the overhead of kzfree() is unacceptable.
Pekka
| |