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: <20090530093147.02d5ed76@lxorguk.ukuu.org.uk>
Date:	Sat, 30 May 2009 09:31:47 +0100
From:	Alan Cox <alan@...rguk.ukuu.org.uk>
To:	Pekka Enberg <penberg@...helsinki.fi>
Cc:	Ingo Molnar <mingo@...e.hu>, Rik van Riel <riel@...hat.com>,
	"Larry H." <research@...reption.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

> The GFP_SENSITIVE flag looks like a big hammer that we don't really
> need IMHO. It seems to me that most of the actual call-sites (crypto

Actually the flag is a small hammer

> code, wireless keys, etc.) should probably just use kzfree()
> unconditionally to make sure we don't leak sensitive data. I did not
> look too closely but I don't think any of the sensitive kfree() calls
> are in fastpaths so the performance impact is negligible.

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.

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ