Messages in this thread | | | Date | Thu, 21 May 2009 10:21:40 -0500 | From | Robin Holt <> | Subject | Re: [patch 0/5] Support for sanitization flag in low-level page allocator |
| |
> > Seems like a particularly wasteful use of a pageflag. Why not simply > > erase the buffer before freeing in those few places where we know its > > important (ie. exactly those places you now put the pageflag in)? ... > The idea of the patch is not merely "protecting" those few places, but > providing a clean, effective generalized method for this purpose. Your > approach means forcing all developers to remember where they have to > place this explicit clearing, and introducing unnecessary code > duplication and an ever growing list of places adding these calls.
I agree with the earlier. If you know enough to set the flag, then you know enough to call a function which does a clear before free. Does seem like a waste of a page flag.
> Also, this let's third-party code (and other kernel interfaces) > use this feature effortlessly. Moreover, this flag allows easy > integration with MAC/security frameworks (for instance, SELinux) to mark > a process as requiring sensitive mappings, in higher level APIs. There are > plans to work on such a patch, which could be independently proposed > to the SELinux maintainers.
That sounds like either a thread group flag or a VMA flag, not a page flag. If you make it a page flag, you would still need to track it on the vma or process to handle the event where the page gets migrated or swapped out. Really doesn't feel like a page flag is right, but I reserve the right to be wrong.
Robin
| |