Bug 215481

Summary:	Deliberate reduction in the quality of entropy!
Product:	Other	Reporter:	Pavel Vasilyev (dixlor)
Component:	Other	Assignee:	other_other
Status:	CLOSED INVALID
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!


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!

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))
			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?