linux-kernel - Re: [GIT PULL] random number generator fixes for 5.18-rc2

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <CAHk-=wjrx=xHFfyNt6bU3=xTkdxr3QwuPA-_A0-HKZmoZwWeiw@mail.gmail.com>
Date:   Thu, 7 Apr 2022 06:34:21 -1000
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     "Jason A. Donenfeld" <Jason@...c4.com>
Cc:     Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [GIT PULL] random number generator fixes for 5.18-rc2

On Thu, Apr 7, 2022 at 3:29 AM Jason A. Donenfeld <Jason@...c4.com> wrote:
>
> - In order to be more like other devices (e.g. /dev/zero) and to mitigate the
>   impact of fixing the above bug, which has been around forever (users have
>   never really needed to check the return value of read() for medium-sized
>   reads and so perhaps many didn't), we now move signal checking to the bottom
>   part of the loop, and do so every PAGE_SIZE-bytes.

Ugh. After fixing a bug where the signal pending state isn't checked
enough, you then go to extra effort to not do it too much.

The whole historical "give at least 256 bytes without even checking
for signal_pending" is also cryptographically entirely bogus, since we
only actually have CHACHA_BLOCK_SIZE worth of random state

So if some program doesn't check for short reads, the difference
between one chacha block and 256 bytes (or PAGE_SIZE like you changed
it to) really *really* doesn't matter, the rest is going to be purely
filler anyway. Nice good filler, but still..

Also, if you hit a EFAULT, you should still return the partial result
you got before to be consistent with what we normally do in these
kinds of situations.

So I think we could just drop all these games, and make the code
simple and streamlined?

Attached patch not committed, only for "why not just stop the silly
games" comments..

                Linus

View attachment "patch.diff" of type "text/x-patch" (1193 bytes)