Re: [PATCH RFC v4 1/1] random: WARN on large getrandom() waits and introduce getrandom2()

["Alexander E. Patrakov" <patrakov@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 4336 bytes --]

20.09.2019 02:47, Linus Torvalds пишет:
> On Thu, Sep 19, 2019 at 1:45 PM Alexander E. Patrakov
> <patrakov@gmail.com> wrote:
>>
>> This already resembles in-kernel haveged (except that it doesn't credit
>> entropy), and Willy Tarreau said "collect the small entropy where it is,
>> period" today. So, too many people touched upon the topic in one day,
>> and therefore I'll bite.
> 
> I'm one of the people who aren't entirely convinced by the jitter
> entropy - I definitely believe it exists, I just am not necessarily
> convinced about the actual entropy calculations.
> 
> So while I do think we should take things like the cycle counter into
> account just because I think it's a a useful way to force some noise,
> I am *not* a huge fan of the jitter entropy driver either, because of
> the whole "I'm not convinced about the amount of entropy".
> 
> The whole "third order time difference" thing would make sense if the
> time difference was some kind of smooth function - which it is at a
> macro level.
> 
> But at a micro level, I could easily see the time difference having
> some very simple pattern - say that your cycle counter isn't really
> cycle-granular, and the load takes 5.33 "cycles" and you see a time
> difference pattern of (5, 5, 6, 5, 5, 6, ...). No real entropy at all
> there, it is 100% reliable.
> 
> At a macro level, that's a very smooth curve, and you'd say "ok, time
> difference is 5.3333 (repeating)". But that's not what the jitter
> entropy code does. It just does differences of differences.
> 
> And that completely non-random pattern has a first-order difference of
> 0, 1, 1, 0, 1, 1.. and a second order of 1, 0, 1, 1, 0,  and so on
> forever. So the "jitter entropy" logic will assign that completely
> repeatable thing entropy, because the delta difference doesn't ever go
> away.
> 
> Maybe I misread it.

You didn't. Let me generalize and rephrase the part of the concern that 
I agree with, in my own words:

The same code is used in cryptoapi rng, and also a userspace version 
exists. These two have been tested by the author via the "dieharder" 
tool (see the message for commit d9d67c87), so we know that on his 
machine it actually produces good-quality random bits. However, the 
in-kernel self-test is much, much weaker, and would not catch the 
situation when someone's machine is deterministic in a way that you 
describe, or something similar.

OTOH, I thought that at least part of the real entropy, if it exists, 
comes from the interference of the CPU's memory accesses with the 
refresh cycles that are clocked from an independent oscillator. That's 
why (in order to catch more of them before declaring the crng 
initialized) I have set the quality to the minimum possible that is 
guaranteed to be distinct from zero according to the fixed-point math in 
hwrng_fillfn() in drivers/char/hw_random/core.c.

> 
> We used to (we still do, but we used to too) do that same third-order
> delta difference ourselves for the interrupt timing entropy estimation
> in add_timer_randomness(). But I think it's more valid with something
> that likely has more noise (interrupt timing really _should_ be
> noisy). It's not clear that the jitterentropy load really has all that
> much noise.
> 
> That said, I'm _also_ not a fan of the user mode models - they happen
> too late anyway for some users, and as you say, it leaves us open to
> random (heh) user mode distribution choices that may be more or less
> broken.
> 
> I would perhaps be willing to just put my foot down, and say "ok,
> we'll solve the 'getrandom(0)' issue by just saying that if that
> blocks too  much, we'll do the jitter entropy thing".
> 
> Making absolutely nobody happy, but working in practice. And maybe
> encouraging the people who don't like jitter entropy to use
> GRND_SECURE instead.

I think this approach makes sense. For those who don't believe in jitter 
entropy, it changes really nothing (except a one-time delay) to Ahmed's 
first patch that makes getrandom(0) equivalent to /dev/urandom, and 
nobody so far proposed anything better that doesn't break existing 
systems. And for those who do believe in jitter entropy, this makes the 
situation as good as in OpenBSD.

-- 
Alexander E. Patrakov


[-- Attachment #2: Криптографическая подпись S/MIME --]
[-- Type: application/pkcs7-signature, Size: 4052 bytes --]