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: <CAHmME9qvdKy6zCHQEUp1zp-dL0Sco1Ujtn7jXK=EFde_yDx8wA@mail.gmail.com>
Date:   Mon, 27 May 2019 17:43:03 +0200
From:   "Jason A. Donenfeld" <Jason@...c4.com>
To:     "Theodore Ts'o" <tytso@....edu>,
        Naveen Nathan <naveen@...tninja.net>,
        Arnd Bergmann <arnd@...db.de>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        "Jason A. Donenfeld" <Jason@...c4.com>,
        Kevin Easton <kevin@...rana.org>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] random: urandom reads block when CRNG is not initialized.

On Mon, May 27, 2019 at 4:07 PM Theodore Ts'o <tytso@....edu> wrote:
>
> This is guaranteed to cause the system to fail for systems using
> systemd.  (Unless you are running an x86 with random.trust_cpu=1 ---
> in which case, this patch/config is pointless.)  And many embedded
> systems *do* use systemd.  I know lots of people like to wish that
> systemd doesn't exist, but we need to face reality.
>
> *Seriously,* if this is something the system builder should be using,
> they should be fixing userspace.  And if they care enough that they
> would want to enable this patch, they could just scan dmesg looking
> for the warnings from the kernel.

Really, it's a chicken & egg thing. If people who make userspaces
never have an option to design around the correct behavior, they'll
continue to rely on the broken behavior. But if we give them a way to
compile their kernels with the correct behavior, eventually some
userspaces will run fine with it. "But they should just use
getrandom()!" you shout. Yes, and maybe the code most userspace
builders provide does do this. But people like to plug-in plenty of
third party things into their userspaces, and I think there's some
value in a userspace being able to say, "we've dealt with the
/dev/urandom situation, and we now do the right thing, so we can
enable this option, and now the code you run on our userspace will
give good randomness."

More concretely, distros might ship an init system that allows
enabling this option without creating issues. Systemd might improve.
OpenRC and runit-based distros appear to exist. Some folks do very
custom stuff. If they manage to make it work with the correct urandom
behavior, then that's a good situation for everything else to build
on, and for providing better guarantees for third party software that
runs on that distro. But none of this is possible without the ability
to compile the kernel with the correct behavior.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ