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 for Android: free password hash cracker in your pocket

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

Message-ID: <20090530092703.GP29711@oblivion.subreption.com>
Date:	Sat, 30 May 2009 02:27:03 -0700
From:	"Larry H." <research@...reption.com>
To:	Pekka Enberg <penberg@...helsinki.fi>
Cc:	Alan Cox <alan@...rguk.ukuu.org.uk>, Ingo Molnar <mingo@...e.hu>,
	Rik van Riel <riel@...hat.com>, 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 11:35 Sat 30 May     , Pekka Enberg wrote:
> Alan Cox wrote:
>> The problem is that most sensitive data is user space anyway.
>> GFP_SENSITIVE or kzfree mean you have to get it right in the kernel and
>> you don't fix things like stack copies of sensitive data - its a quick
>> hack which doesn't meet goot security programming practice -it defaults
>> to insecure which is the wrong way around. Not saying its not a bad idea
>> to kzfree a few keys and things *but* it's not real security.
>> If you want to do real security you have a sysfs or build flag that turns
>> on clearing every page on free. Yes it costs performance (a lot less
>> nowdays with cache bypassing stores) but for the category of user who
>> wants to be sure nothing escapes it does the job while kzfree would be
>> like trying to plug leaks in a sieve.
>
> Yup, your suggestion would make one simple patch, for sure.

This was the first approach taken after Alan and others objected to the
use of a page flag. A patch using a build time config option was
submitted, which is the same way PaX's feature works currently, and Alan
asked for a runtime option instead.

> I wonder if  anyone is actually prepared to enable the thing at run-time, though, which 
> is why I suggested doing the "critical" kzfree() ones unconditionally.

I don't know how many times I need to repeat that if you think the point
here is doing selective sanitization, or that it does any good, you are
totally missing it. Please take some time off and read the past remarks
I made in this thread, especially the analysis of almost a dozen kernel
vulnerabilities which could have been prevented or minimized in terms of
damage (besides coldboot/iceman attacks and so forth, refer to the
Princeton and Stanford papers):

http://marc.info/?l=linux-mm&m=124301548814293&w=2

The very first patchset did change the crypto api, af_key and other
sources to use clearing on release time. Also, regarding your
hesitations about who is prepared to enable full unconditional
sanitization of memory... maybe not you, because you likely don't care
or require this _for yourself_.

Don't assume your perceived level of security risks matches that of the
rest of the real world. This is clearly not something your average
university sysadmin might use. Like Alan put it out nicely, if you need
this, you know why and are well aware of the ups and downs.

Fallacies like this are the basis of every security failure so far.

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