Re: [PATCH] tpm: Salt tpm_get_random() result with get_random_bytes()

From: Janne Karhunen <janne.karhunen@gmail.com>
To: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Cc: linux-integrity@vger.kernel.org,
	David Safford <david.safford@ge.com>,
	Pascal Van Leeuwen <pvanleeuwen@verimatrix.com>,
	James Bottomley <James.Bottomley@hansenpartnership.com>,
	Peter Huewe <peterhuewe@gmx.de>, Jason Gunthorpe <jgg@ziepe.ca>,
	Arnd Bergmann <arnd@arndb.de>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	open list <linux-kernel@vger.kernel.org>,
	Mimi Zohar <zohar@linux.ibm.com>
Subject: Re: [PATCH] tpm: Salt tpm_get_random() result with get_random_bytes()
Date: Wed, 16 Oct 2019 10:02:01 +0300	[thread overview]
Message-ID: <CAE=NcraH_6nDe4Ax9axsbsrMf+EggCQFibY3dpNNgGm7NYTtJQ@mail.gmail.com> (raw)
In-Reply-To: <20191015124702.633-1-jarkko.sakkinen@linux.intel.com>

On Tue, Oct 15, 2019 at 3:50 PM Jarkko Sakkinen
<jarkko.sakkinen@linux.intel.com> wrote:
>
> Salt the result that comes from the TPM RNG with random bytes from the
> kernel RNG. This will allow to use tpm_get_random() as a substitute for
> get_random_bytes().  TPM could have a bug (making results predicatable),
> backdoor or even an inteposer in the bus. Salting gives protections
> against these concerns.

The current issue in the randomness from my point of view is that
encrypted filesystems, ima etc in common deployments require high
quality entropy just few seconds after the system has powered on for
the first time. It is likely that people want to keep their keys
device specific, so the keys need to be generated on the first boot
before any of the filesystems mount.

Issue is wider than the tpm alone. Tpm is not generally present in the
mobile (or even embedded-) systems, but the kernel entropy pool is.
Kernel entropy pool on the other hand normally takes ages to
initialize, and it is initialized from a source (interrupt timestamps)
that does not classify as high-quality entropy. Thus, in the default
configurations the first boot cannot proceed as there is no entropy to
generate keys from and the boot cannot be paused or the entropy
collection ends. I have a hunch that to get past this deadlock many
people end up using very, very low quality entropy present at the krng
at that time. Solving this properly should be in everyone's interests.
This is a bad trap.

I'm personally working around this by using multiple entropy sources
to feed the kernel entropy pool directly from the hwrng driver
initialization function(s) before we enter the userspace. Maybe we
could create a KConfig option that forces people to consciously choose
from the trust sources present in the system which ones are to be used
to feed the krng before we enter the userspace. It would be mandatory
to choose one or more sources rather than us silently running them
into a trap. During the boot some sort of message should be displayed
telling the user how the krng actually got initialized. There is lot
of junk happening on the console early on, but this absolutely vital
piece of information is completely hidden - that you have to read from
the source.

--
Janne