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: <84144f020905310017o3c2b8c52s7d62187cf794e854@mail.gmail.com>
Date:	Sun, 31 May 2009 10:17:31 +0300
From:	Pekka Enberg <penberg@...helsinki.fi>
To:	"Larry H." <research@...reption.com>
Cc:	Rik van Riel <riel@...hat.com>, Ingo Molnar <mingo@...e.hu>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	linux-kernel@...r.kernel.org, Linus Torvalds <torvalds@...l.org>,
	linux-mm@...ck.org, Ingo Molnar <mingo@...hat.com>,
	pageexec@...email.hu,
	Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [patch 0/5] Support for sanitization flag in low-level page 
	allocator

On Sun, May 31, 2009 at 12:33 AM, Larry H. <research@...reption.com> wrote:
> While we are at it, did any of you (Pekka, Ingo, Peter) bother reading
> the very first paper I referenced in the very first patch?:
>
> http://www.stanford.edu/~blp/papers/shredding.html/#kernel-appendix
>
> Could you _please_ bother your highness with an earthly five minutes
> read of that paper? If you don't have other magnificent obligations to
> attend to. _Please_.
>
> PS: I'm still thanking myself for not implementing the kthread /
> multiple page pool based approach. Lord, what could have happened if I
> did.

Something like that might make sense for fast-path code.

I think we could make GFP_SENSITIVE mean that allocations using it
force the actual slab pages to be cleaned up before they're returned
to the page allocator. As far as I can tell, we could then recycle
those slab pages to GFP_SENSITIVE allocations without any clearing
whatsoever as long as they're managed by slab. This ensures critical
data in kmalloc()'d memory is never leaked to userspace.

This doesn't fix all the cases Alan pointed out (unconditional
memset() in page free is clearly superior from security pov) but
should allow us to use GFP_SENSITIVE in fast-path cases where the
overhead of kzfree() is unacceptable.

                                      Pekka
--
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/