linux-kernel - Re: [PATCH] random: only use gathered bytes from arch_get_random

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]

Date:	Sat, 7 Jul 2012 16:20:40 -0700
From:	Kees Cook <keescook@...omium.org>
To:	"Theodore Ts'o" <tytso@....edu>, Kees Cook <keescook@...omium.org>,
	Linux Kernel Developers List <linux-kernel@...r.kernel.org>,
	ewust@...ch.edu, zakir@...ch.edu, nadiah@...ucsd.edu,
	jhalderm@...ch.edu, stable@...r.kernel.org
Subject: Re: [PATCH] random: only use gathered bytes from arch_get_random_long

On Sat, Jul 07, 2012 at 02:23:16PM -0400, Theodore Ts'o wrote:
> On Sat, Jul 07, 2012 at 10:11:22AM -0700, Kees Cook wrote:
> > While very unlikely, it is possible for arch_get_random_long() to fail
> > in the middle of the loop in xfer_secondary_pool(), which would mean
> > that the loop could stop with only part of u.hwrand populated, leading
> > to mix_pool_bytes() injecting uninitialized or already injected bytes
> > instead of fresh bytes. This changes the mix_pool_bytes() call to only
> > inject the successfully gathered bytes.
> 
> I don't believe there is a major problem with injecting uninitialized
> or even known bytes into the pool; worst case we're wastiing a tiny
> amount of CPU in this unlikely case (versus the CPU costs of doing the
> multiplication each time).  Not that I think really matters one way or
> the other... 
> 
> Is there a reason why you're particularly concerned about what might
> happen in the case where arch_get_random_long() fails mid-loop (which
> can happen if RDRAND returns an error for whatever reason, granted)?

Not really, but it seems like poor form to try to mix in data that wasn't
actually what you were expecting. I don't exactly see a problem with what
you've already got, but it seems like it's better to not have the bug at
all.

-Kees

-- 
Kees Cook
Chrome OS Security
--
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/