Re: Linux 2.6.32.60
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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.32.60
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 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.32.60
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 >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. Thanks, I'll dig them out for the next 3.0 release after this one. greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.32.60
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 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. Thanks, I'll dig them out for the next 3.0 release after this one. greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.32.60
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. -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.32.60
On Thu, Oct 11, 2012 at 08:09:00PM +0200, Romain Francoise wrote: > Hi Willy, > > Willy Tarreau writes: > > > 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 ? > > [...] > > 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. > > I have no evidence of any problems caused by including these patches. It's > just that they don't match what I expect to find in a longterm release, > and *if* there are issues they will only show up on a limited set of > machines (Ivy Bridge or newer), so they will be more difficult to track > down. I agree but the situation with random right now is not much better. > But if you think that including the feature is worth the risk I'm totally > fine with it, it's your call to make anyway. :) To be clear, I don't think we need "features" but we need to address risks. Risks of having your servers generate a private key that someone else on the net also uses is high right now as it has been proven (my reverse proxy's public key at home was found on 83 other hosts on the net before I changed it). The work done by several maintainers to provide entropy was quick and efficient. However there are still areas where we know that entropy is limited (eg: similarly equiped servers or appliances connected to nothing and automatically installed by booting off a CD would only differ by a MAC address and maybe a few other bytes). So I think it makes sense to be able to use what the hardware provides when it is available. My opinion indeed was that these patches seem to come with a very low risk, and their authors were very quick to react to the random issues so I'm sure we could count on them if we even encounter any issue. So in the end, my overall opinion is that the risk of having them merged is much lower than the risk of not having them. But I could be wrong. My concern at the moment is more that the patches are in 2.6.32 and not in 3.0, which is something we need to sort out quickly. *that* would be a valid reason for reverting them. > Thanks for maintaining the 2.6.32 series! You're welcome, and thanks to you for double-checking :-) Willy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.32.60
Hi Willy, Willy Tarreau writes: > 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 ? > [...] > 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. I have no evidence of any problems caused by including these patches. It's just that they don't match what I expect to find in a longterm release, and *if* there are issues they will only show up on a limited set of machines (Ivy Bridge or newer), so they will be more difficult to track down. But if you think that including the feature is worth the risk I'm totally fine with it, it's your call to make anyway. :) Thanks for maintaining the 2.6.32 series! -r -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.32.60
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. Regards, Willy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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 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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.32.60
Hi Romain,
On Wed, Oct 10, 2012 at 04:05:32PM +0200, Romain Francoise wrote:
> Hi Willy,
>
> Willy Tarreau 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.32.60
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 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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...@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. 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.32.60
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. Regards, Willy -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.32.60
Hi Willy, Willy Tarreau w...@1wt.eu writes: 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 ? [...] 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. I have no evidence of any problems caused by including these patches. It's just that they don't match what I expect to find in a longterm release, and *if* there are issues they will only show up on a limited set of machines (Ivy Bridge or newer), so they will be more difficult to track down. But if you think that including the feature is worth the risk I'm totally fine with it, it's your call to make anyway. :) Thanks for maintaining the 2.6.32 series! -r -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.32.60
On Thu, Oct 11, 2012 at 08:09:00PM +0200, Romain Francoise wrote: Hi Willy, Willy Tarreau w...@1wt.eu writes: 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 ? [...] 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. I have no evidence of any problems caused by including these patches. It's just that they don't match what I expect to find in a longterm release, and *if* there are issues they will only show up on a limited set of machines (Ivy Bridge or newer), so they will be more difficult to track down. I agree but the situation with random right now is not much better. But if you think that including the feature is worth the risk I'm totally fine with it, it's your call to make anyway. :) To be clear, I don't think we need features but we need to address risks. Risks of having your servers generate a private key that someone else on the net also uses is high right now as it has been proven (my reverse proxy's public key at home was found on 83 other hosts on the net before I changed it). The work done by several maintainers to provide entropy was quick and efficient. However there are still areas where we know that entropy is limited (eg: similarly equiped servers or appliances connected to nothing and automatically installed by booting off a CD would only differ by a MAC address and maybe a few other bytes). So I think it makes sense to be able to use what the hardware provides when it is available. My opinion indeed was that these patches seem to come with a very low risk, and their authors were very quick to react to the random issues so I'm sure we could count on them if we even encounter any issue. So in the end, my overall opinion is that the risk of having them merged is much lower than the risk of not having them. But I could be wrong. My concern at the moment is more that the patches are in 2.6.32 and not in 3.0, which is something we need to sort out quickly. *that* would be a valid reason for reverting them. Thanks for maintaining the 2.6.32 series! You're welcome, and thanks to you for double-checking :-) Willy -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.32.60
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. -hpa -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.32.60
Hi Willy,
Willy Tarreau 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...
In v3.0-stable the various changes to mix more randomness in the entropy
pool were backported without this feature.
Thanks,
-r
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.32.60
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... In v3.0-stable the various changes to mix more randomness in the entropy pool were backported without this feature. Thanks, -r -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
