Bug 215481

Summary: Deliberate reduction in the quality of entropy!
Product: Other Reporter: Pavel Vasilyev (dixlor)
Component: OtherAssignee: other_other
Severity: blocking CC: gregkh, tytso
Priority: P1    
Hardware: All   
OS: Linux   
Kernel Version: Subsystem:
Regression: No Bisected commit-id:

Description Pavel Vasilyev 2022-01-11 12:01:39 UTC
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!


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.


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!
Comment 1 gregkh 2022-01-11 12:13:31 UTC
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.
Comment 2 Theodore Tso 2022-01-11 16:27:50 UTC
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))
		*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?