[lkml]   [2009]   [May]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [patch 0/5] Support for sanitization flag in low-level page allocator
On Wed, 20 May 2009 14:24:13 -0700
"Larry H." <> wrote:

> 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.

And your proposed approach requires that developers remember to use
GFP_SENSITIVE at allocation time. In well-implemented code, there is a
single memory-freeing site, so there's really no difference here.

Other problems I see with the patch are:

- Adds a test-n-branch to all page-freeing operations. Ouch. The
current approach avoids that cost.

- Fails to handle kmalloc()'ed memory. Fixing this will probably
require adding a test-n-branch to kmem_cache_alloc(). Ouch * N.

- Once kmalloc() is fixed, the page-allocator changes and
GFP_SENSITIVE itself can perhaps go away - I expect that little
security-sensitive memory is allocated direct from the page
allocator. Most callsites are probably using
kmalloc()/kmem_cache_alloc() (might be wrong).

If not wrong then we end up with a single requirement: zap the
memory in kmem_cache_free().

But how to do that? Particular callsites don't get to alter
kfree()'s behaviour. So they'd need to use a new kfree_sensitive().
Which is just syntactic sugar around the code whihc we presently

 \ /
  Last update: 2009-05-30 01:03    [W:0.146 / U:1.412 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site