linux-ext4 - Re: Linux 5.3-rc8

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: <214fed0e-6659-def9-b5f8-a9d7a8cb72af@gmail.com>
Date:   Sat, 14 Sep 2019 21:35:12 +0500
From:   "Alexander E. Patrakov" <patrakov@...il.com>
To:     Linus Torvalds <torvalds@...ux-foundation.org>,
        "Ahmed S. Darwish" <darwish.07@...il.com>
Cc:     "Theodore Y. Ts'o" <tytso@....edu>,
        Andreas Dilger <adilger.kernel@...ger.ca>,
        Jan Kara <jack@...e.cz>, Ray Strode <rstrode@...hat.com>,
        William Jon McCann <mccann@....edu>,
        zhangjs <zachary@...shancloud.com>, linux-ext4@...r.kernel.org,
        Lennart Poettering <lennart@...ttering.net>,
        lkml <linux-kernel@...r.kernel.org>
Subject: Re: Linux 5.3-rc8

14.09.2019 21:30, Linus Torvalds пишет:
> On Sat, Sep 14, 2019 at 8:02 AM Ahmed S. Darwish <darwish.07@...il.com> wrote:
>>
>> On Thu, Sep 12, 2019 at 12:34:45PM +0100, Linus Torvalds wrote:
>>>
>>> An alternative might be to make getrandom() just return an error
>>> instead of waiting. Sure, fill the buffer with "as random as we can"
>>> stuff, but then return -EINVAL because you called us too early.
>>
>> ACK, that's probably _the_ most sensible approach. Only caveat is
>> the slight change in user-space API semantics though...
>>
>> For example, this breaks the just released systemd-random-seed(8)
>> as it _explicitly_ requests blocking behvior from getrandom() here:
>>
> 
> Actually, I would argue that the "don't ever block, instead fill
> buffer and return error instead" fixes this broken case.
> 
>>      => src/random-seed/random-seed.c:
>>      /*
>>       * Let's make this whole job asynchronous, i.e. let's make
>>       * ourselves a barrier for proper initialization of the
>>       * random pool.
>>       */
>>       k = getrandom(buf, buf_size, GRND_NONBLOCK);
>>       if (k < 0 && errno == EAGAIN && synchronous) {
>>           log_notice("Kernel entropy pool is not initialized yet, "
>>                      "waiting until it is.");
>>
>>           k = getrandom(buf, buf_size, 0); /* retry synchronously */
>>       }
> 
> Yeah, the above is yet another example of completely broken garbage.
> 
> You can't just wait and block at boot. That is simply 100%
> unacceptable, and always has been, exactly because that may
> potentially mean waiting forever since you didn't do anything that
> actually is likely to add any entropy.
> 
>>       if (k < 0) {
>>           log_debug_errno(errno, "Failed to read random data with "
>>                           "getrandom(), falling back to "
>>                           "/dev/urandom: %m");
> 
> At least it gets a log message.
> 
> So I think the right thing to do is to just make getrandom() return
> -EINVAL, and refuse to block.

Let me repeat: not -EINVAL, please. Please find some other error code, 
so that the application could sensibly distinguish between this case 
(low quality entropy is in the buffer) and the "kernel is too dumb" case 
(and no entropy is in the buffer).


-- 
Alexander E. Patrakov


Download attachment "smime.p7s" of type "application/pkcs7-signature" (4052 bytes)