linux-kernel - Re: repeatable boot randomness inside KVM guest

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] [day] [month] [year] [list]

Message-ID: <20180417214059.GA23194@thunk.org>
Date:   Tue, 17 Apr 2018 17:40:59 -0400
From:   "Theodore Y. Ts'o" <tytso@....edu>
To:     James Bottomley <James.Bottomley@...senPartnership.com>
Cc:     Matthew Wilcox <willy@...radead.org>,
        Alexey Dobriyan <adobriyan@...il.com>,
        linux-kernel@...r.kernel.org, linux-mm@...ck.org
Subject: Re: repeatable boot randomness inside KVM guest

On Tue, Apr 17, 2018 at 04:42:39PM +0100, James Bottomley wrote:
> Depends how the parameter is passed.  If it can be influenced from the
> command line then a large class of "trusted boot" systems actually
> don't verify the command line, so you can boot a trusted system and
> still inject bogus command line parameters.  This is definitely true of
> PC class secure boot.  Not saying it will always be so, just
> illustrating why you don't necessarily want to expand the attack
> surface.

Sure, this is why I don't really like the scheme of relying on the
command line.  For one thing, the command-line is public, so if the
attacker can read /proc/cmdline, they'll have access to the entropy.

What I would prefer is an extension to the boot protocol so that some
number of bytes would be passed to the kernel as a separate bag of
bytes alongside the kernel command line and the initrd.

The kernel would mix that into the random driver (which is written so
the basic input pool and primary_crng can accept input in super-early
boot).  This woud be done *before* we relocate the kernel, so that
kernel ASLR code can relocate the kernel test to a properly
unpredictable number --- so this really is quite super-early boot.

> OK, in the UEFI ideal world where every component is a perfectly
> written OS, perhaps you're right.  In the more real world, do you trust
> the people who wrote the bootloader to understand and correctly
> implement the cryptographically secure process of obtaining a random
> input?

In the default setup, I would expect the bootloader (such as grub)
would read the random initialization data from disk.  So it would work
much like systemd reading from /var/lib/systemd/random-seed.  And I
would trust the bootloader implementors to be able to do this about as
well as I would trust the systemd implementors.  :-)  It's not that
hard, after all....

						- Ted