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: <20121011182905.GB12041@1wt.eu>
Date:	Thu, 11 Oct 2012 20:29:05 +0200
From:	Willy Tarreau <w@....eu>
To:	Romain Francoise <romain@...bokech.com>
Cc:	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:09:00PM +0200, Romain Francoise wrote:
> Hi Willy,
> 
> Willy Tarreau <w@....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 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/