linux-kernel - 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:   Sat, 14 Sep 2019 21:00:37 -0400
From:   "Theodore Y. Ts'o" <tytso@....edu>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     "Ahmed S. Darwish" <darwish.07@...il.com>,
        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,
        Lennart Poettering <lennart@...ttering.net>,
        lkml <linux-kernel@...r.kernel.org>
Subject: Re: Linux 5.3-rc8

On Sat, Sep 14, 2019 at 03:32:46PM -0700, Linus Torvalds wrote:
> > Worse, it won't even accomplish something against an obstinant
> > programmers.  Someone who is going to change their program to sleep
> > loop waiting for getrandom(2) to not return with an error can just as
> > easily check for a buffer which is zero-filled, or an unchanged
> > buffer, and then sleep loop on that.
> 
> Again,  no they can't. They'll get random data in the buffer. And
> there is no way they can tell how much entropy that random data has.

That makes me even more worried.  It's probably going to be OK for
modern x86 systems, since "best we can do" will include RDRAND
(whether or not it's trusted).  But on systems without something like
RDRAND --- e.g., ARM --- the "best we can do" could potentially be
Really Bad.  Again, look back at the Mining Your P's and Q's paper
from factorable.net.

If we don't block, and we just return "the best we can do", and some
insane userspace tries to generate a long-term private key (for SSH or
TLS) in super-early boot, I think we owe them something beyond a big
fat WARN_ON_ONCE.  We could return 0 for success, and yet "the best we
can do" could be really terrible.

> > For 5.3, can we please consider my proposal in [1]?
> >
> > [1] https://lore.kernel.org/linux-ext4/20190914162719.GA19710@mit.edu/
> 
> Honestly, to me that looks *much* worse than just saying that we need
> to stop allowing insane user mode boot programs make insane choices
> that have no basis in reality.
> 
> It may be the safest thing to do, but at that point we might as well
> just revert the ext4 change entirely. I'd rather do that, than have
> random filesystems start making random decisions based on crazy user
> space behavior.

All we're doing is omitting the plug; I disagree that it's really all
that random.  Honestly, I'd much rather just let distributions hang,
and force them to fix it that way.  That's *much* better than silently
give them "the best we can do", which might be "not really random at
all".

The reality is that there will be some platforms where we will block
for a very long time, given certain kernel configs and certain really
stupid userspace decisions --- OR, we can open up a really massive
security hole given stupid userspace decisions.  Ext4 just got unlocky
that a performance improvement patch happened to toggle one or two
configurations from "working" to "not working".   

But just saying, "oh well" and returning something which might not
really be random with a success code is SUCH A TERRIBLE IDEA, that if
you really prefer that, I'll accept the ext4 revert, even though I
don't think we should be penalizing all ext4 performance just because
of a few distros being stupid.

If the choice is between that and making some unsuspecting
distributions being potentially completely insecure, it's no contest.
I won't have that on my conscience.

						- Ted