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]

Date:   Tue, 17 Sep 2019 09:33:40 +0200
From:   Martin Steigerwald <martin@...htvoll.de>
To:     Willy Tarreau <w@....eu>
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

Willy Tarreau - 17.09.19, 07:24:38 CEST:
> On Mon, Sep 16, 2019 at 06:46:07PM -0700, Matthew Garrett wrote:
> > >Well, the patch actually made getrandom() return en error too, but
> > >you seem more interested in the hypotheticals than in arguing
> > >actualities.> 
> > If you want to be safe, terminate the process.
> 
> This is an interesting approach. At least it will cause bug reports in
> application using getrandom() in an unreliable way and they will
> check for other options. Because one of the issues with systems that
> do not finish to boot is that usually the user doesn't know what
> process is hanging.

A userspace process could just poll on the kernel by forking a process 
to use getrandom() and waiting until it does not get terminated anymore. 
And then it would still hang.

So yes, that would it make it harder to abuse the API, but not 
impossible. Which may still be good, I don't know.

Either the kernel does not reveal at all whether it has seeded CRNG and 
leaves GnuPG, OpenSSH and others in the dark, or it does and risk that 
userspace does stupid things whether it prints a big fat warning or not.

Of course the warning could be worded like:

process blocking on entropy too early on boot without giving the kernel 
much chance to gather entropy. this is not a kernel issue, report to 
userspace developers

And probably then kill the process, so at least users will know.

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.

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, but it does not 
replace talking with userspace developers and it would need some time to 
allow for adapting userspace applications and services.

-- 
Martin