[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20121011062916.GG8938@1wt.eu>
Date: Thu, 11 Oct 2012 08:29:16 +0200
From: Willy Tarreau <w@....eu>
To: Romain Francoise <romain@...bokech.com>
Cc: linux-kernel@...r.kernel.org, stable@...r.kernel.org, hpa@...or.com
Subject: Re: Linux 2.6.32.60
Hi Romain,
On Wed, Oct 10, 2012 at 04:05:32PM +0200, Romain Francoise wrote:
> Hi Willy,
>
> Willy Tarreau <w@....eu> writes:
>
> > I've just released Linux 2.6.32.60.
>
> > This release contains, among others, a number of fixes for random and NTP,
> > including for the NTP leap second bug. Users should upgrade.
>
> I'm somewhat surprised to see that it also includes a new feature, namely
> support for Intel's new RDRAND instruction to get random bits ("Bull
> Mountain"):
>
> 67c1930 ("x86, random: Verify RDRAND functionality and allow it to be disabled")
> 5e6321d ("x86, random: Architectural inlines to get random integers with RDRAND")
>
> This was apparently backported from 3.2 via Paul's 2.6.34 tree. Did you
> test this release on a CPU with RDRAND? The commits are small, but they
> don't really qualify as bugfix-only...
I agree they're not bugfix only, however they contribute to addressing a
real issue with random number generation that was raised this summer. As
you might be aware, it was found that many hosts on the net use the same
private SSH or SSL keys due to too low entropy when these keys are generated.
This explains why the random patches were backported in order to collect
more entropy from available sources. RDRAND certainly qualifies as a source
of entropy and I judged it was appropriate for a backport for this reason.
Nobody has objected about this during the review, but maybe you have a
different opinion and valid reasons for these patches to be reverted ?
> In v3.0-stable the various changes to mix more randomness in the entropy
> pool were backported without this feature.
Indeed, I didn't notice they weren't in 3.0 since I found them in 2.6.34. I
always try to ensure that users don't experience regressions when upgrading
to the next stable version.
If you think these patches constitute a regression, I can revert them.
However I'd like convincing arguments since they're here to help address
a real issue.
Regards,
Willy
--
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