lkml.org 
[lkml]   [2009]   [May]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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


\
 
 \ /
  Last update: 2009-05-21 17:25    [W:0.274 / U:0.164 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site