From: Greg KH <greg@kroah.com>
To: Willy Tarreau <w@1wt.eu>
Cc: "H. Peter Anvin" <hpa@zytor.com>,
Romain Francoise <romain@orebokech.com>,
linux-kernel@vger.kernel.org, stable@vger.kernel.org
Subject: Re: Linux 2.6.32.60
Date: Wed, 17 Oct 2012 14:46:06 -0700 [thread overview]
Message-ID: <20121017214606.GD7083@kroah.com> (raw)
In-Reply-To: <20121012063848.GD12041@1wt.eu>
On Fri, Oct 12, 2012 at 08:38:48AM +0200, Willy Tarreau wrote:
> 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
This showed up in 2.6.36
> 7ccafc5f x86, cpufeature: Update CPU feature RDRND to RDRAND
This showed up in 3.0
> 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
I've now queued up these two as they were relevant here.
thanks,
greg k-h
next prev parent reply other threads:[~2012-10-17 21:46 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
2012-10-12 6:42 ` Greg KH
2012-10-17 21:46 ` Greg KH [this message]
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=20121017214606.GD7083@kroah.com \
--to=greg@kroah.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=romain@orebokech.com \
--cc=stable@vger.kernel.org \
--cc=w@1wt.eu \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.