From: Willy Tarreau <w@1wt.eu>
To: Romain Francoise <romain@orebokech.com>
Cc: linux-kernel@vger.kernel.org, stable@vger.kernel.org, hpa@zytor.com
Subject: Re: Linux 2.6.32.60
Date: Thu, 11 Oct 2012 08:29:16 +0200 [thread overview]
Message-ID: <20121011062916.GG8938@1wt.eu> (raw)
In-Reply-To: <87y5jeqv6b.fsf@silenus.orebokech.com>
Hi Romain,
On Wed, Oct 10, 2012 at 04:05:32PM +0200, Romain Francoise wrote:
> Hi Willy,
>
> Willy Tarreau <w@1wt.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
next prev parent reply other threads:[~2012-10-11 6:29 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-09 9:44 Linux 2.6.32.60 Willy Tarreau
2012-10-10 14:05 ` Romain Francoise
2012-10-11 6:29 ` Willy Tarreau [this message]
2012-10-11 10:58 ` Greg KH
2012-10-11 11:31 ` Willy Tarreau
2012-10-11 23:11 ` H. Peter Anvin
2012-10-12 6:38 ` Willy Tarreau
2012-10-12 6:42 ` Greg KH
2012-10-17 21:46 ` Greg KH
2012-10-11 18:09 ` Romain Francoise
2012-10-11 18:29 ` Willy Tarreau
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20121011062916.GG8938@1wt.eu \
--to=w@1wt.eu \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=romain@orebokech.com \
--cc=stable@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox