From: Willy Tarreau <w@1wt.eu>
To: "H. Peter Anvin" <hpa@zytor.com>, Greg KH <greg@kroah.com>
Cc: Romain Francoise <romain@orebokech.com>,
linux-kernel@vger.kernel.org, stable@vger.kernel.org
Subject: Re: Linux 2.6.32.60
Date: Fri, 12 Oct 2012 08:38:48 +0200 [thread overview]
Message-ID: <20121012063848.GD12041@1wt.eu> (raw)
In-Reply-To: <50775210.4060007@zytor.com>
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
next prev parent reply other threads:[~2012-10-12 6:38 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
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 [this message]
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=20121012063848.GD12041@1wt.eu \
--to=w@1wt.eu \
--cc=greg@kroah.com \
--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