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]

Message-ID: <20121012063848.GD12041@1wt.eu>
Date:	Fri, 12 Oct 2012 08:38:48 +0200
From:	Willy Tarreau <w@....eu>
To:	"H. Peter Anvin" <hpa@...or.com>, Greg KH <greg@...ah.com>
Cc:	Romain Francoise <romain@...bokech.com>,
	linux-kernel@...r.kernel.org, stable@...r.kernel.org
Subject: Re: Linux 2.6.32.60

On Fri, Oct 12, 2012 at 07:11:12AM +0800, H. Peter Anvin wrote:
> On 10/11/2012 07:31 PM, Willy Tarreau wrote:
> > On Thu, Oct 11, 2012 at 07:58:04PM +0900, Greg KH wrote:
> >> On Thu, Oct 11, 2012 at 08:29:16AM +0200, Willy Tarreau wrote:
> >>> 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.
> > 
> > At least I think they should not be in 2.6.32 without being in 3.0.
> > Probably that Peter's opinion will help us decide whether they should
> > go into 3.0 or 2.6.32 should revert them.
> > 
> 
> I would strongly argue for at least one of the RDRAND-enabling versions
> being in all supported kernels; the second (with Ted Ts'o's changes) is
> better, but touches a *lot* of subsystems; the plain one is
> self-contained but only helps RDRAND-enabled hardware.
> 
> Without these patches the random subsystem has a critical security flaw,
> which puts it into the scope for stable.

That's clearly what I understood, thanks Peter for confirming ! So I won't
revert the patches unless a regression is reported in which case we'll
prefer to fix it.

Greg, I think it would be better to get them into 3.0 too. The ones I used
were (prefixed with 'X' if they are already in 3.0) :
   24da9c26 x86, cpu: Add CPU flags for F16C and RDRND
   7ccafc5f x86, cpufeature: Update CPU feature RDRND to RDRAND
 X 63d77173 random: Add support for architectural random hooks
 X bd29e568 fix typo/thinko in get_random_bytes()
   628c6246 x86, random: Architectural inlines to get random integers with RDRAND
   49d859d7 x86, random: Verify RDRAND functionality and allow it to be disabled
 X cf833d0b random: Use arch_get_random_int instead of cycle counter if avail
 X 3e88bdff random: Use arch-specific RNG to initialize the entropy store
 X 2dac8e54 random: Adjust the number of loops when initializing

So in the end it seems you only need to add 24da9c26, 7ccafc5f, 628c6246, and
49d859d7 to get them all.

There should be no problem to backport them since initially I could pick most
of them directly from 3.2, though it was easier to pick all of them from .34
in the end.

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/