[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5d2f4ff9.1c69fb81.3c314.ab00@mx.google.com>
Date: Wed, 17 Jul 2019 09:42:32 -0700
From: Stephen Boyd <swboyd@...omium.org>
To: Jason Gunthorpe <jgg@...pe.ca>
Cc: Peter Huewe <peterhuewe@....de>,
Jarkko Sakkinen <jarkko.sakkinen@...ux.intel.com>,
linux-kernel@...r.kernel.org, Arnd Bergmann <arnd@...db.de>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
linux-integrity@...r.kernel.org,
Andrey Pronin <apronin@...omium.org>,
Duncan Laurie <dlaurie@...omium.org>,
Guenter Roeck <groeck@...omium.org>,
Herbert Xu <herbert@...dor.apana.org.au>
Subject: Re: [PATCH v2 1/6] hwrng: core: Freeze khwrng thread during suspend
Quoting Jason Gunthorpe (2019-07-17 04:39:56)
> On Tue, Jul 16, 2019 at 03:45:13PM -0700, Stephen Boyd wrote:
> > The hwrng_fill() function can run while devices are suspending and
> > resuming. If the hwrng is behind a bus such as i2c or SPI and that bus
> > is suspended, the hwrng may hang the bus while attempting to add some
> > randomness. It's been observed on ChromeOS devices with suspend-to-idle
> > (s2idle) and an i2c based hwrng that this kthread may run and ask the
> > hwrng device for randomness before the i2c bus has been resumed.
>
> You mean the TPM here right?
In my case yes, but in general it isn't the TPM.
>
> Should we be more careful in the TPM code to check if the TPM is
> suspended before trying to use it, rather than muck up callers?
>
Given that it's not just a TPM issue I don't see how checking in the TPM
is going to fix this problem. It's better to not try to get random bytes
from the hwrng when the device could be suspended.
Powered by blists - more mailing lists