linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH] tpm: Salt tpm_get_random() result with get_random_bytes()
@ 2019-10-15 12:47 Jarkko Sakkinen
  2019-10-15 17:04 ` Jason Gunthorpe
  2019-10-16  7:02 ` Janne Karhunen
  0 siblings, 2 replies; 10+ messages in thread
From: Jarkko Sakkinen @ 2019-10-15 12:47 UTC (permalink / raw)
  To: linux-integrity
  Cc: Jarkko Sakkinen, David Safford, Pascal Van Leeuwen,
	James Bottomley, Peter Huewe, Jason Gunthorpe, Arnd Bergmann,
	Greg Kroah-Hartman, open list

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.

Cc: David Safford <david.safford@ge.com>
Cc: Pascal Van Leeuwen <pvanleeuwen@verimatrix.com>
Cc: James Bottomley <James.Bottomley@HansenPartnership.com>
Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
---
 drivers/char/tpm/tpm-interface.c | 21 +++++++++++++++++++--
 1 file changed, 19 insertions(+), 2 deletions(-)

diff --git a/drivers/char/tpm/tpm-interface.c b/drivers/char/tpm/tpm-interface.c
index 7f105490604c..a135b1cd5a17 100644
--- a/drivers/char/tpm/tpm-interface.c
+++ b/drivers/char/tpm/tpm-interface.c
@@ -22,6 +22,7 @@
 #include <linux/poll.h>
 #include <linux/slab.h>
 #include <linux/mutex.h>
+#include <linux/random.h>
 #include <linux/spinlock.h>
 #include <linux/suspend.h>
 #include <linux/freezer.h>
@@ -431,16 +432,24 @@ int tpm_pm_resume(struct device *dev)
 EXPORT_SYMBOL_GPL(tpm_pm_resume);
 
 /**
- * tpm_get_random() - get random bytes from the TPM's RNG
+ * tpm_get_random() - Get random bytes from the TPM's RNG
  * @chip:	a &struct tpm_chip instance, %NULL for the default chip
  * @out:	destination buffer for the random bytes
  * @max:	the max number of bytes to write to @out
  *
- * Return: number of random bytes read or a negative error value.
+ * Get random bytes from the TPM's RNG and salt the result with the same amount
+ * of bytes from the kernel RNG. Salting allows to call this function as a
+ * substitute for get_random_bytes() where appropriate.
+ *
+ * Return:
+ *   number of random bytes on success,
+ *   -errno on error
  */
 int tpm_get_random(struct tpm_chip *chip, u8 *out, size_t max)
 {
+	u8 salt[TPM_MAX_RNG_DATA];
 	int rc;
+	int i;
 
 	if (!out || max > TPM_MAX_RNG_DATA)
 		return -EINVAL;
@@ -455,6 +464,14 @@ int tpm_get_random(struct tpm_chip *chip, u8 *out, size_t max)
 		rc = tpm1_get_random(chip, out, max);
 
 	tpm_put_ops(chip);
+
+	if (rc > 0) {
+		get_random_bytes(salt, rc);
+
+		for (i = 0; i < rc; i++)
+			out[i] ^= salt[i];
+	}
+
 	return rc;
 }
 EXPORT_SYMBOL_GPL(tpm_get_random);
-- 
2.20.1


^ permalink raw reply related	[flat|nested] 10+ messages in thread

* Re: [PATCH] tpm: Salt tpm_get_random() result with get_random_bytes()
  2019-10-15 12:47 [PATCH] tpm: Salt tpm_get_random() result with get_random_bytes() Jarkko Sakkinen
@ 2019-10-15 17:04 ` Jason Gunthorpe
  2019-10-16 10:38   ` Jarkko Sakkinen
  2019-10-16  7:02 ` Janne Karhunen
  1 sibling, 1 reply; 10+ messages in thread
From: Jason Gunthorpe @ 2019-10-15 17:04 UTC (permalink / raw)
  To: Jarkko Sakkinen
  Cc: linux-integrity, David Safford, Pascal Van Leeuwen,
	James Bottomley, Peter Huewe, Arnd Bergmann, Greg Kroah-Hartman,
	open list

On Tue, Oct 15, 2019 at 03:47:02PM +0300, Jarkko Sakkinen 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.

Seems like a dangerous use case, why would any kernel user that cared
about quality of randomness ever call a tpm_* API to get quality
random data?

Jason

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH] tpm: Salt tpm_get_random() result with get_random_bytes()
  2019-10-15 12:47 [PATCH] tpm: Salt tpm_get_random() result with get_random_bytes() Jarkko Sakkinen
  2019-10-15 17:04 ` Jason Gunthorpe
@ 2019-10-16  7:02 ` Janne Karhunen
  2019-10-16 10:41   ` Jarkko Sakkinen
  1 sibling, 1 reply; 10+ messages in thread
From: Janne Karhunen @ 2019-10-16  7:02 UTC (permalink / raw)
  To: Jarkko Sakkinen
  Cc: linux-integrity, David Safford, Pascal Van Leeuwen,
	James Bottomley, Peter Huewe, Jason Gunthorpe, Arnd Bergmann,
	Greg Kroah-Hartman, open list, Mimi Zohar

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

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH] tpm: Salt tpm_get_random() result with get_random_bytes()
  2019-10-15 17:04 ` Jason Gunthorpe
@ 2019-10-16 10:38   ` Jarkko Sakkinen
  2019-10-16 10:43     ` Jarkko Sakkinen
  0 siblings, 1 reply; 10+ messages in thread
From: Jarkko Sakkinen @ 2019-10-16 10:38 UTC (permalink / raw)
  To: Jason Gunthorpe
  Cc: linux-integrity, David Safford, Pascal Van Leeuwen,
	James Bottomley, Peter Huewe, Arnd Bergmann, Greg Kroah-Hartman,
	open list

On Tue, Oct 15, 2019 at 02:04:50PM -0300, Jason Gunthorpe wrote:
> On Tue, Oct 15, 2019 at 03:47:02PM +0300, Jarkko Sakkinen 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.
> 
> Seems like a dangerous use case, why would any kernel user that cared
> about quality of randomness ever call a tpm_* API to get quality
> random data?

This is related to this discussion:

https://lore.kernel.org/linux-integrity/CAE=NcrY3BTvD-L2XP6bsO=9oAJLtSD0wYpUymVkAGAnYObsPzQ@mail.gmail.com/T/#t

I could also move this to the call site.

/Jarkko

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH] tpm: Salt tpm_get_random() result with get_random_bytes()
  2019-10-16  7:02 ` Janne Karhunen
@ 2019-10-16 10:41   ` Jarkko Sakkinen
  2019-10-16 11:16     ` Janne Karhunen
  0 siblings, 1 reply; 10+ messages in thread
From: Jarkko Sakkinen @ 2019-10-16 10:41 UTC (permalink / raw)
  To: Janne Karhunen
  Cc: linux-integrity, David Safford, Pascal Van Leeuwen,
	James Bottomley, Peter Huewe, Jason Gunthorpe, Arnd Bergmann,
	Greg Kroah-Hartman, open list, Mimi Zohar

On Wed, Oct 16, 2019 at 10:02:01AM +0300, Janne Karhunen wrote:
> 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.

This patch does not have the described issue.

Which call sites are you talking about?

/Jarkko

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH] tpm: Salt tpm_get_random() result with get_random_bytes()
  2019-10-16 10:38   ` Jarkko Sakkinen
@ 2019-10-16 10:43     ` Jarkko Sakkinen
  2019-10-16 16:09       ` Jason Gunthorpe
  0 siblings, 1 reply; 10+ messages in thread
From: Jarkko Sakkinen @ 2019-10-16 10:43 UTC (permalink / raw)
  To: Jason Gunthorpe
  Cc: linux-integrity, David Safford, Pascal Van Leeuwen,
	James Bottomley, Peter Huewe, Arnd Bergmann, Greg Kroah-Hartman,
	open list

On Wed, Oct 16, 2019 at 01:38:05PM +0300, Jarkko Sakkinen wrote:
> On Tue, Oct 15, 2019 at 02:04:50PM -0300, Jason Gunthorpe wrote:
> > On Tue, Oct 15, 2019 at 03:47:02PM +0300, Jarkko Sakkinen 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.
> > 
> > Seems like a dangerous use case, why would any kernel user that cared
> > about quality of randomness ever call a tpm_* API to get quality
> > random data?
> 
> This is related to this discussion:
> 
> https://lore.kernel.org/linux-integrity/CAE=NcrY3BTvD-L2XP6bsO=9oAJLtSD0wYpUymVkAGAnYObsPzQ@mail.gmail.com/T/#t
> 
> I could also move this to the call site.

But I hear you anyway.

I think for trusted keys the best strategy would be to do
exactly this:

1. Generate one random value with get_random_bytes_arch()
2. Generate another with backend specific technology (we
   have now two TPM and TEE) if an RNG available.
3. Xor the values together.

/Jarkko

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH] tpm: Salt tpm_get_random() result with get_random_bytes()
  2019-10-16 10:41   ` Jarkko Sakkinen
@ 2019-10-16 11:16     ` Janne Karhunen
  2019-10-16 16:23       ` Jarkko Sakkinen
  0 siblings, 1 reply; 10+ messages in thread
From: Janne Karhunen @ 2019-10-16 11:16 UTC (permalink / raw)
  To: Jarkko Sakkinen
  Cc: linux-integrity, David Safford, Pascal Van Leeuwen,
	James Bottomley, Peter Huewe, Jason Gunthorpe, Arnd Bergmann,
	Greg Kroah-Hartman, open list, Mimi Zohar

On Wed, Oct 16, 2019 at 1:41 PM Jarkko Sakkinen
<jarkko.sakkinen@linux.intel.com> wrote:

> > > 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.
>
> This patch does not have the described issue.

My understanding was that you wanted to make the tpm_get_random() an
alternative to get_random_bytes(), and one reason why one might want
to do this is to work around the issues in get_random_bytes() in early
init as it may not be properly seeded. But sure, if you this wasn't
among the problems being solved then forget it.


--
Janne

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH] tpm: Salt tpm_get_random() result with get_random_bytes()
  2019-10-16 10:43     ` Jarkko Sakkinen
@ 2019-10-16 16:09       ` Jason Gunthorpe
  2019-10-17 16:21         ` Jarkko Sakkinen
  0 siblings, 1 reply; 10+ messages in thread
From: Jason Gunthorpe @ 2019-10-16 16:09 UTC (permalink / raw)
  To: Jarkko Sakkinen
  Cc: linux-integrity, David Safford, Pascal Van Leeuwen,
	James Bottomley, Peter Huewe, Arnd Bergmann, Greg Kroah-Hartman,
	open list

On Wed, Oct 16, 2019 at 01:43:22PM +0300, Jarkko Sakkinen wrote:
> On Wed, Oct 16, 2019 at 01:38:05PM +0300, Jarkko Sakkinen wrote:
> > On Tue, Oct 15, 2019 at 02:04:50PM -0300, Jason Gunthorpe wrote:
> > > On Tue, Oct 15, 2019 at 03:47:02PM +0300, Jarkko Sakkinen 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.
> > > 
> > > Seems like a dangerous use case, why would any kernel user that cared
> > > about quality of randomness ever call a tpm_* API to get quality
> > > random data?
> > 
> > This is related to this discussion:
> > 
> > https://lore.kernel.org/linux-integrity/CAE=NcrY3BTvD-L2XP6bsO=9oAJLtSD0wYpUymVkAGAnYObsPzQ@mail.gmail.com/T/#t
> > 
> > I could also move this to the call site.
> 
> But I hear you anyway.
> 
> I think for trusted keys the best strategy would be to do
> exactly this:
> 
> 1. Generate one random value with get_random_bytes_arch()
> 2. Generate another with backend specific technology (we
>    have now two TPM and TEE) if an RNG available.
> 3. Xor the values together.

Feels like something the random core should handle - maybe some way to
say 'my trust model requires trust in this RNG' and then the random
core can more heavily weight data from that RNG

Jason

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH] tpm: Salt tpm_get_random() result with get_random_bytes()
  2019-10-16 11:16     ` Janne Karhunen
@ 2019-10-16 16:23       ` Jarkko Sakkinen
  0 siblings, 0 replies; 10+ messages in thread
From: Jarkko Sakkinen @ 2019-10-16 16:23 UTC (permalink / raw)
  To: Janne Karhunen
  Cc: linux-integrity, David Safford, Pascal Van Leeuwen,
	James Bottomley, Peter Huewe, Jason Gunthorpe, Arnd Bergmann,
	Greg Kroah-Hartman, open list, Mimi Zohar

On Wed, Oct 16, 2019 at 02:16:20PM +0300, Janne Karhunen wrote:
> On Wed, Oct 16, 2019 at 1:41 PM Jarkko Sakkinen
> <jarkko.sakkinen@linux.intel.com> wrote:
> 
> > > > 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.
> >
> > This patch does not have the described issue.
> 
> My understanding was that you wanted to make the tpm_get_random() an
> alternative to get_random_bytes(), and one reason why one might want
> to do this is to work around the issues in get_random_bytes() in early
> init as it may not be properly seeded. But sure, if you this wasn't
> among the problems being solved then forget it.

I'm trying to get a framework on how rng's should be used in the
kernel. There doesn't seem to be one.

/Jarkko

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH] tpm: Salt tpm_get_random() result with get_random_bytes()
  2019-10-16 16:09       ` Jason Gunthorpe
@ 2019-10-17 16:21         ` Jarkko Sakkinen
  0 siblings, 0 replies; 10+ messages in thread
From: Jarkko Sakkinen @ 2019-10-17 16:21 UTC (permalink / raw)
  To: Jason Gunthorpe
  Cc: linux-integrity, David Safford, Pascal Van Leeuwen,
	James Bottomley, Peter Huewe, Arnd Bergmann, Greg Kroah-Hartman,
	open list

On Wed, Oct 16, 2019 at 01:09:08PM -0300, Jason Gunthorpe wrote:
> On Wed, Oct 16, 2019 at 01:43:22PM +0300, Jarkko Sakkinen wrote:
> > On Wed, Oct 16, 2019 at 01:38:05PM +0300, Jarkko Sakkinen wrote:
> > > On Tue, Oct 15, 2019 at 02:04:50PM -0300, Jason Gunthorpe wrote:
> > > > On Tue, Oct 15, 2019 at 03:47:02PM +0300, Jarkko Sakkinen 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.
> > > > 
> > > > Seems like a dangerous use case, why would any kernel user that cared
> > > > about quality of randomness ever call a tpm_* API to get quality
> > > > random data?
> > > 
> > > This is related to this discussion:
> > > 
> > > https://lore.kernel.org/linux-integrity/CAE=NcrY3BTvD-L2XP6bsO=9oAJLtSD0wYpUymVkAGAnYObsPzQ@mail.gmail.com/T/#t
> > > 
> > > I could also move this to the call site.
> > 
> > But I hear you anyway.
> > 
> > I think for trusted keys the best strategy would be to do
> > exactly this:
> > 
> > 1. Generate one random value with get_random_bytes_arch()
> > 2. Generate another with backend specific technology (we
> >    have now two TPM and TEE) if an RNG available.
> > 3. Xor the values together.
> 
> Feels like something the random core should handle - maybe some way to
> say 'my trust model requires trust in this RNG' and then the random
> core can more heavily weight data from that RNG

Yeah, I think. I'll study these emails threads and RNG implementation
a bit when I have more time. Now I think I lack some knowledge to say
anything educated so better to take a step back and go back to the
drawing board.

Thank you for the suggestion.

/Jarkko

^ permalink raw reply	[flat|nested] 10+ messages in thread

end of thread, other threads:[~2019-10-17 16:21 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-10-15 12:47 [PATCH] tpm: Salt tpm_get_random() result with get_random_bytes() Jarkko Sakkinen
2019-10-15 17:04 ` Jason Gunthorpe
2019-10-16 10:38   ` Jarkko Sakkinen
2019-10-16 10:43     ` Jarkko Sakkinen
2019-10-16 16:09       ` Jason Gunthorpe
2019-10-17 16:21         ` Jarkko Sakkinen
2019-10-16  7:02 ` Janne Karhunen
2019-10-16 10:41   ` Jarkko Sakkinen
2019-10-16 11:16     ` Janne Karhunen
2019-10-16 16:23       ` Jarkko Sakkinen

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).