On 07/27/2012 07:39 PM, Theodore Ts'o wrote:
Ok, I'll add this patch to the random tree. I've modified the commit
message a bit since the speed advertisement of RDRAND is rather
pointless --- processes aren't generating session keys or long term
keys at a high rate, and programs can't count on /
Ok, I'll add this patch to the random tree. I've modified the commit
message a bit since the speed advertisement of RDRAND is rather
pointless --- processes aren't generating session keys or long term
keys at a high rate, and programs can't count on /dev/random being
super fast and having unlimite
On 07/25/2012 04:50 PM, Ben Hutchings wrote:
> On Wed, 2012-07-25 at 10:37 -0700, H. Peter Anvin wrote:
>> From: "H. Peter Anvin"
>>
>> RDRAND is so much faster than the Linux pool system that we can
>> always just mix in architectural randomness.
> [...]
>> Signed-off-by: H. Peter Anvin
>> Acked
On Wed, 2012-07-25 at 10:37 -0700, H. Peter Anvin wrote:
> From: "H. Peter Anvin"
>
> RDRAND is so much faster than the Linux pool system that we can
> always just mix in architectural randomness.
[...]
> Signed-off-by: H. Peter Anvin
> Acked-by: Ingo Molnar
> Cc: DJ Johnston
[...]
This is no
From: "H. Peter Anvin"
RDRAND is so much faster than the Linux pool system that we can
always just mix in architectural randomness.
Doing this in extract_buf() lets us do this in one convenient
place, unfortunately the output size (10 bytes) is maximally
awkward. That, plus the fact that every
5 matches
Mail list logo