diff mbox series

[9/9] tpm: Make 'tpm init' to call tpm_auto_start()

Message ID 20230510074359.2837818-9-ilias.apalodimas@linaro.org
State New
Headers show
Series [1/9] tpm: Fix spelling for tpmu_ha union | expand

Commit Message

Ilias Apalodimas May 10, 2023, 7:43 a.m. UTC
For a TPM device to be operational we need to initialize it and
perform its startup sequence.  The 'tpm init' command currently calls
tpm_init() which ends up calling the ->open() per-device callback and
performs the initial hardware configuration as well as requesting
locality 0 for the caller.   We recently added tpm_auto_start() though,
which automates the initialization process -- On top of that calling
tpm_init() on selftests is a bit problematic,  since calling it twice
will return -EBUSY the second time although there is no actual problem
with the TPM or the software stack.

So let's wire up the 'tpm init' command and call tpm_auto_start() which
leaves the device in an operational state.

It's worth noting that calling tpm_init() only, doesn't allow a someone
to use the TPM since the startup sequence is mandatory. We keep
repeating the pattern of calling
- tpm_init
- tpm_startup
- tpm_self_test_full or tpm_continue_self_test

So we don't expect any regression or boot delays with the current
change.

While at it fix the identation of test_tpm_autostart() comments as well

Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
---
 cmd/tpm-common.c | 3 ++-
 test/dm/tpm.c    | 9 +++++----
 2 files changed, 7 insertions(+), 5 deletions(-)

Comments

Simon Glass May 10, 2023, 2:31 p.m. UTC | #1
Hi Ilias,

On Wed, 10 May 2023 at 01:44, Ilias Apalodimas
<ilias.apalodimas@linaro.org> wrote:
>
> For a TPM device to be operational we need to initialize it and
> perform its startup sequence.  The 'tpm init' command currently calls
> tpm_init() which ends up calling the ->open() per-device callback and
> performs the initial hardware configuration as well as requesting
> locality 0 for the caller.   We recently added tpm_auto_start() though,
> which automates the initialization process -- On top of that calling
> tpm_init() on selftests is a bit problematic,  since calling it twice
> will return -EBUSY the second time although there is no actual problem
> with the TPM or the software stack.
>
> So let's wire up the 'tpm init' command and call tpm_auto_start() which
> leaves the device in an operational state.
>
> It's worth noting that calling tpm_init() only, doesn't allow a someone
> to use the TPM since the startup sequence is mandatory. We keep
> repeating the pattern of calling
> - tpm_init
> - tpm_startup
> - tpm_self_test_full or tpm_continue_self_test
>
> So we don't expect any regression or boot delays with the current
> change.
>
> While at it fix the identation of test_tpm_autostart() comments as well
>
> Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
> ---
>  cmd/tpm-common.c | 3 ++-
>  test/dm/tpm.c    | 9 +++++----
>  2 files changed, 7 insertions(+), 5 deletions(-)

We've been through this before. I do understand that EFI just does
everything in U-Boot proper, but it is better for previous phases to
set up the TPM, e.g. VPL, as we discussed on irc. In that case we
cannot init the TPM twice.

I think what you want is a new 'tpm autostart' command, or something
like that? You already have the tpm_auto_start() function so you can
call that as needed.

Regards,
Simon
Ilias Apalodimas May 10, 2023, 3:32 p.m. UTC | #2
On Wed, 10 May 2023 at 17:32, Simon Glass <sjg@chromium.org> wrote:
>
> Hi Ilias,
>
> On Wed, 10 May 2023 at 01:44, Ilias Apalodimas
> <ilias.apalodimas@linaro.org> wrote:
> >
> > For a TPM device to be operational we need to initialize it and
> > perform its startup sequence.  The 'tpm init' command currently calls
> > tpm_init() which ends up calling the ->open() per-device callback and
> > performs the initial hardware configuration as well as requesting
> > locality 0 for the caller.   We recently added tpm_auto_start() though,
> > which automates the initialization process -- On top of that calling
> > tpm_init() on selftests is a bit problematic,  since calling it twice
> > will return -EBUSY the second time although there is no actual problem
> > with the TPM or the software stack.
> >
> > So let's wire up the 'tpm init' command and call tpm_auto_start() which
> > leaves the device in an operational state.
> >
> > It's worth noting that calling tpm_init() only, doesn't allow a someone
> > to use the TPM since the startup sequence is mandatory. We keep
> > repeating the pattern of calling
> > - tpm_init
> > - tpm_startup
> > - tpm_self_test_full or tpm_continue_self_test
> >
> > So we don't expect any regression or boot delays with the current
> > change.
> >
> > While at it fix the identation of test_tpm_autostart() comments as well
> >
> > Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
> > ---
> >  cmd/tpm-common.c | 3 ++-
> >  test/dm/tpm.c    | 9 +++++----
> >  2 files changed, 7 insertions(+), 5 deletions(-)
>
> We've been through this before. I do understand that EFI just does
> everything in U-Boot proper, but it is better for previous phases to
> set up the TPM, e.g. VPL, as we discussed on irc. In that case we
> cannot init the TPM twice.

Why can't we? Nothing bad happens to the device and the auto start
function takes that into account and doesn't run tpm2_startup() twice
if it's already initialized.

>
> I think what you want is a new 'tpm autostart' command, or something
> like that? You already have the tpm_auto_start() function so you can
> call that as needed.

I don't like having many confusing ways of starting the TPM.  To me
'init' means, initialize the device so I can use it.  Our code right
now needs 4 extra commands to happen which is confusing at best.  Do
you have any measurements that running auto start twice adds
substantial overhead?  Not to mention that tpm_init() returns 2
different error codes even if no errors are there.  Half oof our code
just ignores the return code of tpm_init due to that.  So my plan is
to get rid of it eventually and only have one sane way of starting the
device

Thanks
/Ilias
>
> Regards,
> Simon
Ilias Apalodimas May 10, 2023, 3:49 p.m. UTC | #3
On Wed, 10 May 2023 at 18:32, Ilias Apalodimas
<ilias.apalodimas@linaro.org> wrote:
>
> On Wed, 10 May 2023 at 17:32, Simon Glass <sjg@chromium.org> wrote:
> >
> > Hi Ilias,
> >
> > On Wed, 10 May 2023 at 01:44, Ilias Apalodimas
> > <ilias.apalodimas@linaro.org> wrote:
> > >
> > > For a TPM device to be operational we need to initialize it and
> > > perform its startup sequence.  The 'tpm init' command currently calls
> > > tpm_init() which ends up calling the ->open() per-device callback and
> > > performs the initial hardware configuration as well as requesting
> > > locality 0 for the caller.   We recently added tpm_auto_start() though,
> > > which automates the initialization process -- On top of that calling
> > > tpm_init() on selftests is a bit problematic,  since calling it twice
> > > will return -EBUSY the second time although there is no actual problem
> > > with the TPM or the software stack.
> > >
> > > So let's wire up the 'tpm init' command and call tpm_auto_start() which
> > > leaves the device in an operational state.
> > >
> > > It's worth noting that calling tpm_init() only, doesn't allow a someone
> > > to use the TPM since the startup sequence is mandatory. We keep
> > > repeating the pattern of calling
> > > - tpm_init
> > > - tpm_startup
> > > - tpm_self_test_full or tpm_continue_self_test
> > >
> > > So we don't expect any regression or boot delays with the current
> > > change.
> > >
> > > While at it fix the identation of test_tpm_autostart() comments as well
> > >
> > > Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
> > > ---
> > >  cmd/tpm-common.c | 3 ++-
> > >  test/dm/tpm.c    | 9 +++++----
> > >  2 files changed, 7 insertions(+), 5 deletions(-)
> >
> > We've been through this before. I do understand that EFI just does
> > everything in U-Boot proper, but it is better for previous phases to
> > set up the TPM, e.g. VPL, as we discussed on irc. In that case we
> > cannot init the TPM twice.

I also forgot to answer this.  EFI does *not* need anything in u-boot
proper.  In fact you rejected a patch which was initializing the TPM
earlier in the past with the 'it's slow' argument.  You also argued we
should just init it in the efi subsystem when we need it (which we
do).  So if you ever want to initialize the device early,  you *must*
use the tpm_auto_start anyway and I can remove the ad-hoc init in the
EFI subsystem.  But even if we leave it there, it will make no
difference.

Thanks
/Ilias
>
> Why can't we? Nothing bad happens to the device and the auto start
> function takes that into account and doesn't run tpm2_startup() twice
> if it's already initialized.
>
> >
> > I think what you want is a new 'tpm autostart' command, or something
> > like that? You already have the tpm_auto_start() function so you can
> > call that as needed.
>
> I don't like having many confusing ways of starting the TPM.  To me
> 'init' means, initialize the device so I can use it.  Our code right
> now needs 4 extra commands to happen which is confusing at best.  Do
> you have any measurements that running auto start twice adds
> substantial overhead?  Not to mention that tpm_init() returns 2
> different error codes even if no errors are there.  Half oof our code
> just ignores the return code of tpm_init due to that.  So my plan is
> to get rid of it eventually and only have one sane way of starting the
> device
>
> Thanks
> /Ilias
> >
> > Regards,
> > Simon
diff mbox series

Patch

diff --git a/cmd/tpm-common.c b/cmd/tpm-common.c
index d0c63cadf413..9b1ad0b371df 100644
--- a/cmd/tpm-common.c
+++ b/cmd/tpm-common.c
@@ -11,6 +11,7 @@ 
 #include <asm/unaligned.h>
 #include <linux/string.h>
 #include <tpm-common.h>
+#include <tpm_api.h>
 #include "tpm-user-utils.h"
 
 static struct udevice *tpm_dev;
@@ -364,7 +365,7 @@  int do_tpm_init(struct cmd_tbl *cmdtp, int flag, int argc, char *const argv[])
 	if (rc)
 		return rc;
 
-	return report_return_code(tpm_init(dev));
+	return report_return_code(tpm_auto_start(dev));
 }
 
 int do_tpm(struct cmd_tbl *cmdtp, int flag, int argc, char *const argv[])
diff --git a/test/dm/tpm.c b/test/dm/tpm.c
index 3defb3c3da1f..cde933ab2848 100644
--- a/test/dm/tpm.c
+++ b/test/dm/tpm.c
@@ -98,10 +98,11 @@  static int test_tpm_autostart(struct unit_test_state *uts,
 
 	if (reinit)
 		ut_assertok(tpm_init(dev));
-	 /*
-	  * tpm_auto_start will rerun tpm_init() if reinit, but handles the
-	  * -EBUSY return code internally.
-	  */
+
+	/*
+	 * tpm_auto_start will rerun tpm_init() if reinit, but handles the
+	 * -EBUSY return code internally.
+	 */
 	ut_assertok(tpm_auto_start(dev));
 
 	return 0;