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: <20190917083516.GA27098@1wt.eu>
Date:   Tue, 17 Sep 2019 10:35:16 +0200
From:   Willy Tarreau <w@....eu>
To:     Martin Steigerwald <martin@...htvoll.de>
Cc:     Matthew Garrett <mjg59@...f.ucam.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        "Ahmed S. Darwish" <darwish.07@...il.com>,
        "Theodore Y. Ts'o" <tytso@....edu>,
        Vito Caputo <vcaputo@...garu.com>,
        Lennart Poettering <mzxreary@...inter.de>,
        Andreas Dilger <adilger.kernel@...ger.ca>,
        Jan Kara <jack@...e.cz>, Ray Strode <rstrode@...hat.com>,
        William Jon McCann <mccann@....edu>,
        "Alexander E. Patrakov" <patrakov@...il.com>,
        zhangjs <zachary@...shancloud.com>, linux-ext4@...r.kernel.org,
        lkml <linux-kernel@...r.kernel.org>
Subject: Re: Linux 5.3-rc8

On Tue, Sep 17, 2019 at 09:33:40AM +0200, Martin Steigerwald wrote:
> However this again would be burdening users with an issue they should 
> not have to care about. Unless userspace developers care enough and 
> manage to take time to fix the issue before updated kernels come to their 
> systems. Cause again it would be users systems that would not be 
> working. Just cause kernel and userspace developers did not agree and 
> chose to fight with each other instead of talking *with* each other.

It has nothing to do with fighting at all, it has to do with offering
what applications *need* without breaking existing assumptions that
make most applications work. And more importantly it involves not
silently breaking applications which need good randomness for long
lived keys because the breakage will not be visible initially and can
hit them hard later. Right now most applications which block in the
early stages are only victim of the current situation and their
developers possibly didn't understand the possible impacts of lack
of entropy (or how real an issue it was). These applications do need
to be able to get low-quality random without blocking forever,
provided these are not accidently used by those who need security. At
some point, just like for any syscall, the doc makes the difference.

> At least with killing gdm Systemd may restart it if configured to do so. 
> But if it doesn't, the user is again stuck with a non working system 
> until restarting gdm themselves.
> 
> It may still make sense to make the API harder to use,

No. What is hard to use is often misused. It must be harder to misuse
it, which means it should be easier to correctly use it. The choice of
flag names and the emission of warnings definitely helps during the
development stage.

> but it does not 
> replace talking with userspace developers and it would need some time to 
> allow for adapting userspace applications and services.

Which is how adding new flags can definitely help even if adoption takes
time. By the way in this discussion I am a userspace developer and have
been hit several times by libraries switching to getrandom() that silently
failed to respond in field. As a userspace developer, I really want to see
a solution to this problem. And I'm fine if the kernel decides to kill
haproxy for using getrandom() with the old settings, at least users will
notice, will complain to me and will update.

Willy