linux-kernel - Re: [patch 0/5] Support for sanitization flag in low-level page allocator

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20090529155859.2cf20823.akpm@linux-foundation.org>
Date:	Fri, 29 May 2009 15:58:59 -0700
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	"Larry H." <research@...reption.com>
Cc:	peterz@...radead.org, linux-kernel@...r.kernel.org,
	torvalds@...ux-foundation.org, linux-mm@...ck.org,
	mingo@...hat.com, pageexec@...email.hu
Subject: Re: [patch 0/5] Support for sanitization flag in low-level page
 allocator

On Wed, 20 May 2009 14:24:13 -0700
"Larry H." <research@...reption.com> 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
  implement.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/