Re: [PATCH] Support for kernel memory sanitization

Randy Dunlap
2009-05-22T23:49:05Z

Larry H. wrote:
> [PATCH] Support for kernel memory sanitization
>
> This patch adds support for the CONFIDENTIAL flag to the SLAB and SLUB
> allocators. An additional GFP flag is added for use with higher level
> allocators (GFP_CONFIDENTIAL, which implies GFP_ZERO).
>
> A boot command line option (sanitize_mem) is added for the page
> allocator to perform sanitization of all pages upon release and
> allocation.
>
> The code is largely based off the memory sanitization feature in the
> PaX project (licensed under the GPL v2 terms) and the original
> PG_sensitive patch which allowed fine-grained marking of pages using
> a page flag. The lack of a page flag makes the gfp flag mostly useless,
> since we can't track pages with the sensitive/confidential bit, and
> properly sanitize them on release. The only way to overcome this
> limitation is to enable the sanitize_mem boot option and perform
> unconditional page sanitization.
>
> This avoids leaking sensitive information when memory is released to
> the system after use, for example in cryptographic subsystems. More
> specifically, the following threats are addressed:
>
> 1. Information leaks in use-after-free or uninitialized
> variable usage scenarios, such as CVE-2005-0400,
> CVE-2009-0787 and CVE-2007-6417.
>
> 2. Data remanence based attacks, such as Iceman/Coldboot,
> which combine cold rebooting and memory image scanning
> to extract cryptographic secrets (ex. detecting AES key
> expansion blocks, RSA key patterns, etc) or other
> confidential information.
>
> 3. Re-allocation based information leaks, especially in the
> SLAB/SLUB allocators which use LIFO caches and might expose
> sensitive data out of context (when a caller allocates an
> object and receives a pointer to a location which was used
> previously by another user).
>
> The "Shredding Your Garbage: Reducing Data Lifetime Through Secure
> Deallocation" paper by Jim Chow et. al from the Stanford University
> Department of Computer Science, explains the security implications of
> insecure deallocation, and provides extensive information with figures
> and applications thoroughly analyzed for this behavior [1]. More recently
> this issue came to widespread attention when the "Lest We Remember:
> Cold Boot Attacks on Encryption Keys" (by Halderman et. al) paper was
> published [2].
>
> This patch has been tested on x86 and amd64, with and without HIGHMEM.
>
> [1] http://www.stanford.edu/~blp/papers/shredding.html
> [2] http://citp.princeton.edu/memory/
> [3] http://marc.info/?l=linux-mm&m=124284428226461&w=2
> [4] http://marc.info/?t=124284431000002&r=1&w=2
>
> Signed-off-by: Larry H. <research@subreption.com>

BTW, are you familiar with Documentation/SubmittingPatches,
section 12: Sign your work ? in particular, this part:

"then you just add a line saying

Signed-off-by: Random J Developer <random@developer.example.org>

using your real name (sorry, no pseudonyms or anonymous contributions.)"

--
~Randy
LPC 2009, Sept. 23-25, Portland, Oregon