linux-kernel - Re: + binfmt_elfc-use-get_random_int-to-fix-entropy-depleting.patch added to -mm tree

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] [day] [month] [year] [list]

Message-ID: <509B4F78.4060007@oracle.com>
Date:	Thu, 08 Nov 2012 14:21:44 +0800
From:	Jeff Liu <jeff.liu@...cle.com>
To:	Kees Cook <keescook@...omium.org>
CC:	"Theodore Ts'o" <tytso@....edu>, akpm@...ux-foundation.org,
	aedilger@...il.com, alan@...ux.intel.com,
	gregkh@...uxfoundation.org, jakub@...hat.com,
	james.l.morris@...cle.com, john.sobecki@...cle.com,
	viro@...iv.linux.org.uk, LKML <linux-kernel@...r.kernel.org>
Subject: Re: + binfmt_elfc-use-get_random_int-to-fix-entropy-depleting.patch
 added to -mm tree

On 11/07/2012 11:10 PM, Kees Cook wrote:
> On Wed, Nov 7, 2012 at 1:32 AM, Theodore Ts'o <tytso@....edu> wrote:
>> On Tue, Nov 06, 2012 at 05:11:17PM -0800, Kees Cook wrote:
>>> Hrm, I don't like this. get_random_int() specifically says: "Get a
>>> random word for internal kernel use only." The intent of AT_RANDOM is
>>> for userspace pRNG seeding (though glibc currently uses it directly
>>> for stack protector and pointer mangling), which is not "internal
>>> kernel use only". :) Though I suppose this is already being used for
>>> the randomize_stack_top(), but I think it'd still be better to use
>>> higher quality bits.
>>
>> Well, in practice, right now, get_random_int() is only being used for
>> different cases of ASLR of one variety or another (either by the
>> kernel in exec or mmap, or in userspace).  So I'm not sure it really
>> is a major issue.
> 
> Hrm, yes. I see that the network code uses random32, not
> get_random_int(). How are these different? Is one demonstrably better?
I also have the same question in this point.
Both generators are NOT considered safe for cryptographic use, but the
comments of get_random_int() indicates that it could be used for several
uses the cost of depleting entropy is too high, that's why I chose it.
> 
>> If we also change get_random_int() to use a more secure cryptographic
>> random generator (i.e., maybe AES instead of MD5), would that be
>> sufficient to address your concerns?  We're not using get_random_int()
>> for anything that's timing sensitive, so that shouldn't be a problem.
> 
> I wonder if using AES would have a measurable impact on fork speeds?
> 
>> Or maybe we should just add an explicit CRNG set of routines (like the
>> similar discussions to make an explicitly named PRNG set of routines),
>> so callers can use whatever random number generator is appropriate for
>> their performance and security needs.
> 
> If we do use get_random_int() here, I'd at least like to see its
> comment changed to reflect its actual purpose (since it's not
> "internal use only") as well as its expected unpredictability. (This
> would help document the utility of get_random_bytes() vs
> get_random_int() vs random32().)
> 
> -Kees
Thanks,
-Jeff


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