All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thorsten Glaser <tg@mirbsd.de>
To: "Theodore Y. Ts'o" <tytso@mit.edu>
Cc: Adrian Bunk <bunk@debian.org>,
	Ben Hutchings <ben@decadent.org.uk>,
	Debian release team <debian-release@lists.debian.org>,
	Debian kernel maintainers <debian-kernel@lists.debian.org>,
	krb5@packages.debian.org, libbsd@packages.debian.org,
	systemd@packages.debian.org,
	Michael Kerrisk <mtk.manpages@gmail.com>,
	linux-kernel@vger.kernel.org
Subject: Re: Fixing Linux getrandom() in stable
Date: Mon, 14 May 2018 00:50:07 +0000 (UTC)	[thread overview]
Message-ID: <Pine.BSM.4.64L.1805140044300.26761@herc.mirbsd.org> (raw)
In-Reply-To: <20180514003034.GI14763@thunk.org>

Theodore Y. Ts'o dixit:

>that problems helps most of our users, and we shouldn't let the
>perfect be the enemy of the good.

Agreed. Start small, then enhance one bootloader at a time.
Or boot protocol, I assume.

>Also note that the bootloader has depend on userspace to refresh the
>seed entropy, both in early boot (in case the syscrashes), and at
>shutdown (so the entropy captured while the system is running can be

Definitely!

>saved as seed entropy).  And this is trickier in Linux because the
>bootloader lives in a different source tree, and is maintained by
>different people from the systemd and/or initscripts people, and for

Yes, unfortunately.

>that matter the bootloader doesn't know which distribution it is

But in this case, the distribution can tell the bootloader the
path to the file to load.

>the *BSD's has its advantages.  And this is where perhaps Debian as a
>distribution can solve this problem by coordinating action across
>multiple Debian packages.)

Of course.

>The *point* is that we can't really make a turn-key solution which
>will work for everyone.  For as much we have the desire for a
>"Universal OS", something that works for all hardware, all users, and
>all workloads, is probably just not attainable here.

As Debian, we can try to come close, but, as you said, don’t let
the perfect be the enemy of the good. Perhaps there are multiple
somethings that, together (or having the local admin choose) can
help more people than one simple solution, even if the latter may
help a majority. (I’m a fan of minorities, in case you couldn’t
tell. I run an x32 system, after all, and helped out m68k a bit…)

>(It never was a complete solution, BTW; even before the patches to
>address CVE-2018-1108, there were already hardware systems where you
>couldn't count on the RNG being initialized in time and getrandom(2)

Another question is what it means that the RNG is initialised.
It all depends on what in the end boils down to guesswork,
although I tip my hat because that RNG code of yours, both the
Linux and the BSD version, are pretty impressive.

But the point here is that, even if the RNG thinks it’s fully
initialised, it may not be “good” yet, depending on circumstances.
(Again, it should not stop us from trying.)

bye,
//mirabilos
-- 
Solange man keine schmutzigen Tricks macht, und ich meine *wirklich*
schmutzige Tricks, wie bei einer doppelt verketteten Liste beide
Pointer XORen und in nur einem Word speichern, funktioniert Boehm ganz
hervorragend.		-- Andreas Bogk über boehm-gc in d.a.s.r

  reply	other threads:[~2018-05-14  0:58 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <75577b3d2efd01aaf563f1a1400a2c655556b258.camel@decadent.org.uk>
2018-05-13 20:48 ` Fixing Linux getrandom() in stable Adrian Bunk
2018-05-13 21:23   ` Thorsten Glaser
2018-05-14  0:30     ` Theodore Y. Ts'o
2018-05-14  0:50       ` Thorsten Glaser [this message]
2018-05-14 13:05     ` Sam Hartman
2018-05-14  2:11   ` Ben Hutchings
2018-05-22 19:47     ` Adrian Bunk

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Pine.BSM.4.64L.1805140044300.26761@herc.mirbsd.org \
    --to=tg@mirbsd.de \
    --cc=ben@decadent.org.uk \
    --cc=bunk@debian.org \
    --cc=debian-kernel@lists.debian.org \
    --cc=debian-release@lists.debian.org \
    --cc=krb5@packages.debian.org \
    --cc=libbsd@packages.debian.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mtk.manpages@gmail.com \
    --cc=systemd@packages.debian.org \
    --cc=tytso@mit.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.