Currently it is not possible to set the tpm chips reset state from within
the driver. This is problematic if the chip is still in reset after the
system comes up. This may e.g. happen if the reset line is pulled into
reset state by a pin configuration in the device tree.
To handle this case extend tpm_tis_phy_ops by the two functions "set_reset"
and "unset_reset" which may optionally be defined by a tpm driver.
If defined call "unset_reset" at chip startup before the first tpm command
is issued. Also if defined call "set_reset" at chip shutdown after the tpm2
shutdown command has been sent.
Signed-off-by: Lino Sanfilippo <[email protected]>
---
drivers/char/tpm/tpm-chip.c | 5 +++++
drivers/char/tpm/tpm_tis_core.c | 3 +++
drivers/char/tpm/tpm_tis_core.h | 2 ++
3 files changed, 10 insertions(+)
diff --git a/drivers/char/tpm/tpm-chip.c b/drivers/char/tpm/tpm-chip.c
index 783d65fc71f0..c1b79ba9159d 100644
--- a/drivers/char/tpm/tpm-chip.c
+++ b/drivers/char/tpm/tpm-chip.c
@@ -24,6 +24,7 @@
#include <linux/tpm_eventlog.h>
#include <linux/hw_random.h>
#include "tpm.h"
+#include "tpm_tis_core.h"
DEFINE_IDR(dev_nums_idr);
static DEFINE_MUTEX(idr_lock);
@@ -286,6 +287,7 @@ static void tpm_dev_release(struct device *dev)
static int tpm_class_shutdown(struct device *dev)
{
struct tpm_chip *chip = container_of(dev, struct tpm_chip, dev);
+ struct tpm_tis_data *priv = dev_get_drvdata(&chip->dev);
down_write(&chip->ops_sem);
if (chip->flags & TPM_CHIP_FLAG_TPM2) {
@@ -297,6 +299,9 @@ static int tpm_class_shutdown(struct device *dev)
chip->ops = NULL;
up_write(&chip->ops_sem);
+ if (priv->phy_ops->set_reset)
+ priv->phy_ops->set_reset(priv);
+
return 0;
}
diff --git a/drivers/char/tpm/tpm_tis_core.c b/drivers/char/tpm/tpm_tis_core.c
index dc56b976d816..11e5e045f3a7 100644
--- a/drivers/char/tpm/tpm_tis_core.c
+++ b/drivers/char/tpm/tpm_tis_core.c
@@ -952,6 +952,9 @@ int tpm_tis_core_init(struct device *dev, struct tpm_tis_data *priv, int irq,
dev_set_drvdata(&chip->dev, priv);
+ if (priv->phy_ops->unset_reset)
+ priv->phy_ops->unset_reset(priv);
+
rc = tpm_tis_read32(priv, TPM_DID_VID(0), &vendor);
if (rc < 0)
return rc;
diff --git a/drivers/char/tpm/tpm_tis_core.h b/drivers/char/tpm/tpm_tis_core.h
index 3be24f221e32..f1a67445a5c5 100644
--- a/drivers/char/tpm/tpm_tis_core.h
+++ b/drivers/char/tpm/tpm_tis_core.h
@@ -105,6 +105,8 @@ struct tpm_tis_data {
};
struct tpm_tis_phy_ops {
+ int (*set_reset)(struct tpm_tis_data *data);
+ int (*unset_reset)(struct tpm_tis_data *data);
int (*read_bytes)(struct tpm_tis_data *data, u32 addr, u16 len,
u8 *result);
int (*write_bytes)(struct tpm_tis_data *data, u32 addr, u16 len,
--
2.35.1
On Thu, Apr 07, 2022 at 01:18:45PM +0200, Lino Sanfilippo wrote:
> Currently it is not possible to set the tpm chips reset state from within
> the driver. This is problematic if the chip is still in reset after the
> system comes up. This may e.g. happen if the reset line is pulled into
> reset state by a pin configuration in the device tree.
This kind of system is badly misdesigned.
TPM PCRs fundementally cannot work if the TPM reset line is under
software control.
Jason
Hi,
On 07.04.22 at 16:25, Jason Gunthorpe wrote:
> On Thu, Apr 07, 2022 at 01:18:45PM +0200, Lino Sanfilippo wrote:
>> Currently it is not possible to set the tpm chips reset state from within
>> the driver. This is problematic if the chip is still in reset after the
>> system comes up. This may e.g. happen if the reset line is pulled into
>> reset state by a pin configuration in the device tree.
>
> This kind of system is badly misdesigned.
>
> TPM PCRs fundementally cannot work if the TPM reset line is under
> software control.
>
> Jason
>
you may be right about the misdesign, but as a matter of fact
there are systems which have the TPMs reset line connected to a GPIO and not
the system reset. For those systems we should provide a way to let at least the
driver put the TPM out of reset (note that on those systems the TPM reset can
be triggered by software anyway by asserting/deasserting the GPIO line).
Regards,
Lino
On Thu, Apr 07, 2022 at 11:25:26AM -0300, Jason Gunthorpe wrote:
> On Thu, Apr 07, 2022 at 01:18:45PM +0200, Lino Sanfilippo wrote:
> > Currently it is not possible to set the tpm chips reset state from within
> > the driver. This is problematic if the chip is still in reset after the
> > system comes up. This may e.g. happen if the reset line is pulled into
> > reset state by a pin configuration in the device tree.
>
> This kind of system is badly misdesigned.
>
> TPM PCRs fundementally cannot work if the TPM reset line is under
> software control.
Not every system which incorporates a TPM wants to use or is even capable
of measuring software state of any kind or perform secure boot.
Those systems may merely want to use the TPM to store key material.
Thanks,
Lukas
On Sun, Apr 10, 2022 at 07:11:23PM +0200, Lukas Wunner wrote:
> On Thu, Apr 07, 2022 at 11:25:26AM -0300, Jason Gunthorpe wrote:
> > On Thu, Apr 07, 2022 at 01:18:45PM +0200, Lino Sanfilippo wrote:
> > > Currently it is not possible to set the tpm chips reset state from within
> > > the driver. This is problematic if the chip is still in reset after the
> > > system comes up. This may e.g. happen if the reset line is pulled into
> > > reset state by a pin configuration in the device tree.
> >
> > This kind of system is badly misdesigned.
> >
> > TPM PCRs fundementally cannot work if the TPM reset line is under
> > software control.
>
> Not every system which incorporates a TPM wants to use or is even capable
> of measuring software state of any kind or perform secure boot.
>
> Those systems may merely want to use the TPM to store key material.
Then maybe the TPM driver should make it clear somehow that the PCRs
don't work in these systems.
It is really dangerous to add capabilities like this that should
never, ever be used in sanely designed systems.
Jason
On Mon, Apr 11, 2022 at 08:47:41AM -0300, Jason Gunthorpe wrote:
> On Sun, Apr 10, 2022 at 07:11:23PM +0200, Lukas Wunner wrote:
> > On Thu, Apr 07, 2022 at 11:25:26AM -0300, Jason Gunthorpe wrote:
> > > On Thu, Apr 07, 2022 at 01:18:45PM +0200, Lino Sanfilippo wrote:
> > > > Currently it is not possible to set the tpm chips reset state from within
> > > > the driver. This is problematic if the chip is still in reset after the
> > > > system comes up. This may e.g. happen if the reset line is pulled into
> > > > reset state by a pin configuration in the device tree.
> > >
> > > This kind of system is badly misdesigned.
> > >
> > > TPM PCRs fundementally cannot work if the TPM reset line is under
> > > software control.
> >
> > Not every system which incorporates a TPM wants to use or is even capable
> > of measuring software state of any kind or perform secure boot.
> >
> > Those systems may merely want to use the TPM to store key material.
>
> Then maybe the TPM driver should make it clear somehow that the PCRs
> don't work in these systems.
>
> It is really dangerous to add capabilities like this that should
> never, ever be used in sanely designed systems.
>
> Jason
I agree. That niche should do the bad things with oot patches.
BR, Jarkko