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  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]
Date:	Tue, 22 Jul 2014 14:10:40 -0700
From:	Andy Lutomirski <>
To:	"H. Peter Anvin" <>
Cc:	"Theodore Ts'o" <>, kvm list <>,
	"" <>,
	Kees Cook <>, X86 ML <>,
	Daniel Borkmann <>,
	Srivatsa Vaddagiri <>,
	Raghavendra K T <>,
	Gleb Natapov <>,
	Paolo Bonzini <>,
	Bandan Das <>, Andrew Honig <>
Subject: Re: [PATCH v4 2/5] random: Add and use arch_get_rng_seed

On Tue, Jul 22, 2014 at 2:08 PM, H. Peter Anvin <> wrote:
> On 07/22/2014 02:04 PM, Andy Lutomirski wrote:
>> Just to check: do you mean the RDRAND is very likely to work (i.e.
>> arch_get_random_long will return true) or that RDRAND will actually
>> reseed several times during initialization?
> I mean that RDRAND will actually reseed several times during
> initialization.  The documented architectural limit is actually
> extremely conservative.
> Either way, it isn't really different from seeding from a VM hosts
> /dev/urandom...

Sure it is.  The VM host's /dev/urandom makes no guarantee (or AFAIK
even any particular effort) to reseed such that the output has some
minimum entropy per bit, so there would be no point to reading extra
data from it.

Anyway, I'd be willing to drop the conservative RDRAND logic, but I
*still* think that arch_get_rng_seed is a much better interface than

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists