linux-kernel - Re: [GIT PULL] random number generator fixes for 5.17-rc1

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAHmME9oRZ+JNENWJBDCLrgdtLWWoCh9eRRN9g9AGZGY8P5C1LQ@mail.gmail.com>
Date:   Wed, 19 Jan 2022 15:15:36 +0100
From:   "Jason A. Donenfeld" <Jason@...c4.com>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [GIT PULL] random number generator fixes for 5.17-rc1

Hey Linus,

On Wed, Jan 19, 2022 at 9:49 AM Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
>
> On Tue, Jan 18, 2022 at 6:49 PM Jason A. Donenfeld <Jason@...c4.com> wrote:
> >
> > 1) Some Kconfig changes resulted in BIG_KEYS being unselectable, which Justin
> >    sent a patch to fix.
>
> Ugh. I think the old "don't ask" model was the correct one, and
> BIG_KEYS is probably broken (ie it should just select whatever crypto
> it wants, not depend on people having selected it).

Yea, I agree entirely there. Fixing that was my first inclination,
until I was told to just fix what I broke directly and leave future
changes to Herbert's tree. In general, the lib/crypto stuff is
terribly broken, an unholy mix of cross dependencies between the
cryptoapi and the library code, with little clean separation between
things. My zinc "rewrite" project aimed to fix this all, but alas. So
with everything still held together with bubblegum and scotch tape,
we're still seeing the fallout from the cruft in various ways, this
being one of them. This morning it looks like another thing has been
unearthed, regarding an interaction between a subtle Clang CFI bug and
weak symbols, so unless the compiler people tell me, "oh, let us just
fix that in our experimental CFI implementation", which they may well
might, I may be sending you another patch at some point. Hopefully for
5.18, we can make some headway for actually fixing some of this stuff
up the proper way.

> On a tangential note - looking at the resulting config file, I do note
> that 'CRYPTO_LIB_POLY1305_RSIZE' should probably depend on
> CRYPTO_LIB_POLY1305, because right now that sily thing gets set
> whether POLY1305 is enabled or not.
>
> That was true before too, of course - not related to this pull except
> in the "this caused me to look at the end result" sense.

Noted, thanks.

Jason