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: <8c2a47cc-a519-ad94-5d9a-18bb03ba2fd7@gmail.com>
Date:   Sat, 14 Sep 2019 22:09:23 +0500
From:   "Alexander E. Patrakov" <patrakov@...il.com>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     "Ahmed S. Darwish" <darwish.07@...il.com>,
        "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:52, Linus Torvalds пишет:
> On Sat, Sep 14, 2019 at 9:35 AM Alexander E. Patrakov
> <patrakov@...il.com> wrote:
>>
>> 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).
> 
> I'm not convinced we want applications to see that difference.
> 
> The fact is, every time an application thinks it cares, it has caused
> problems. I can just see systemd saying "ok, the kernel didn't block,
> so I'll just do
> 
>     while (getrandom(x) == -ENOENTROPY)
>         sleep(1);
> 
> instead. Which is still completely buggy garbage.

OK, I understand this viewpoint. But then still, -EINVAL is not the 
answer, because a hypothetical evil version of systemd will use -EINVAL 
as -ENOENTROPY (with flags == 0 and a reasonable buffer size, there is 
simply no other reason for the kernel to return -EINVAL). Yes I 
understand that this is a complete reverse of my previous argument.

> The fact is, we can't guarantee entropy in general. It's probably
> there is practice, particularly with user space saving randomness from
> last boot etc, but that kind of data may be real entropy, but the
> kernel cannot *guarantee* that it is.
> 
> And people don't like us guaranteeing that rdrand/rdseed is "real
> entropy" either, since they don't trust the CPU hw either.
> 
> Which means that we're all kinds of screwed. The whole "we guarantee
> entropy" model is broken.

I agree here. Given that you suggested "to just fill the buffer and 
return 0" in the previous mail (well, I think you really meant "return 
buflen", otherwise ENOENTROPY == 0 and your previous objection applies), 
let's do just that. As a bonus, it saves applications from the complex 
dance with retrying via /dev/urandom and finally brings a reliable API 
(modulo old and broken kernels) to get random numbers (well, as random 
as possible right now) without needing a file descriptor.

-- 
Alexander E. Patrakov


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