Messages in this thread | | | From | "Jason A. Donenfeld" <> | Date | Wed, 19 Jan 2022 15:15:36 +0100 | 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@linux-foundation.org> wrote: > > On Tue, Jan 18, 2022 at 6:49 PM Jason A. Donenfeld <Jason@zx2c4.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
| |