linux-kernel - Re: Linux 2.6.32.60

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:	Thu, 11 Oct 2012 19:58:04 +0900
From:	Greg KH <greg@...ah.com>
To:	Willy Tarreau <w@....eu>
Cc:	Romain Francoise <romain@...bokech.com>,
	linux-kernel@...r.kernel.org, stable@...r.kernel.org, hpa@...or.com
Subject: Re: Linux 2.6.32.60

On Thu, Oct 11, 2012 at 08:29:16AM +0200, Willy Tarreau wrote:
> 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.

If I missed these when doing the random number generation backport for
3.0, and I should add them there as well, please let me know.

thanks,

greg k-h
--
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/