Transition in the extract_buf (), drivers/char/random.c, function to use the BLAKE2 hash The patches for the transition in the extract_buf(), drivers/char/random.c, function to use the BLAKE2 hash lead to a decrease in the quality of the entropy. It can be seen that an unnecessary variable was deliberately used to hide the warnings from the compiler! https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/char/random.c#n1407 The 'salt' variable is not used anywhere. At the same time, data from the hardware sensor is assigned to it, that go into a vacuum. https://www.xda-developers.com/us-senator-pushes-government-use-wireguard-vpn/ The US Senate loves the new maintainer, I think he also works for the CIA or the NSA. I propose to exclude him from minteners and study his work VERY carefully!
On Tue, Jan 11, 2022 at 12:02:37PM +0000, bugzilla-daemon@bugzilla.kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=215481 > > Pavel Vasilyev (dixlor@gmail.com) changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > CC| |gregkh@linuxfoundation.org Please submit this through email to the proper developers and mailing list, bugzilla is not used for this kernel component, sorry.
This is also not a bug, since the variable in question (which is a *pointer*) was in fact very clearly used: /* * If we have an architectural hardware random number * generator, use it for BLAKE2's salt & personal fields. */ for (salt = (unsigned long *)&state.h[4]; salt < (unsigned long *)&state.h[8]; ++salt) { unsigned long v; if (!arch_get_random_long(&v)) break; *salt ^= v; <=== salt is used here! } The goal of this hunk of code is to use RDRAND (or an equivalent CPU-provided RNG, if available) to mix into the 4 bytes located at state.h[4..7] using the XOR operation. So before making claims about the new /dev/random co-maintainer, maybe you could "study very carefully" how the C programming language works first?