Unbalanced TPM2 HMAC session calls

Unbalanced TPM2 HMAC session calls

[Jonathan McDowell]

We're seeing a lot of:

tpm tpm0: auth session is active

messages in our logs. This is emitted (once per boot) by 
tpm2_start_auth_session() if the auth sessions is already active when it 
is called.

Investigating I think this is because tpm2_pcr_extend() calls 
tpm_buf_append_hmac_session() which sets TPM2_SA_CONTINUE_SESSION so 
tpm_buf_check_hmac_response() does not cleanup the auth session, but 
then doesn't call tpm2_end_auth_session().

Looking at tpm2_get_random() it uses TPM2_SA_CONTINUE_SESSION but *also* 
cleans up with tpm2_end_auth_session().

I'd be sending a patch proposing the addition of tpm2_end_auth_session() 
to the end of tpm2_pcr_extend() but I recall a bunch of discussion 
about trying to cache the HMAC session to improve IMA performance, so I 
don't know if perhaps we should be dropping the warning instead?

(As an aside, I'm not clear dropping the warning is enough, as I can't 
see where the session otherwise gets cleaned up other than by accident 
when the RNG tries to get more randomness.)

J.

-- 
I've got a trigger inside.

Re: Unbalanced TPM2 HMAC session calls

[Mimi Zohar]

On Thu, 2025-03-06 at 15:15 +0000, Jonathan McDowell wrote:
> We're seeing a lot of:
> 
> tpm tpm0: auth session is active
> 
> messages in our logs. This is emitted (once per boot) by 
> tpm2_start_auth_session() if the auth sessions is already active when it 
> is called.
> 
> Investigating I think this is because tpm2_pcr_extend() calls 
> tpm_buf_append_hmac_session() which sets TPM2_SA_CONTINUE_SESSION so 
> tpm_buf_check_hmac_response() does not cleanup the auth session, but 
> then doesn't call tpm2_end_auth_session().
> 
> Looking at tpm2_get_random() it uses TPM2_SA_CONTINUE_SESSION but *also* 
> cleans up with tpm2_end_auth_session().
> 
> I'd be sending a patch proposing the addition of tpm2_end_auth_session() 
> to the end of tpm2_pcr_extend() but I recall a bunch of discussion 
> about trying to cache the HMAC session to improve IMA performance, so I 
> don't know if perhaps we should be dropping the warning instead?

Hi Jonathan,

That suggestion was nixed.  Instead the boot command line option
"tpm.disable_pcr_integrity" was upstreamed to disable the HMAC for TPM extends.
Refer to commit 27184f8905ba ("tpm: Opt-in in disable PCR integrity
protection').

Mimi

> 
> (As an aside, I'm not clear dropping the warning is enough, as I can't 
> see where the session otherwise gets cleaned up other than by accident 
> when the RNG tries to get more randomness.)
> 

Re: Unbalanced TPM2 HMAC session calls

[James Bottomley]

On Thu, 2025-03-06 at 13:59 -0500, Mimi Zohar wrote:
> On Thu, 2025-03-06 at 15:15 +0000, Jonathan McDowell wrote:
> > We're seeing a lot of:
> > 
> > tpm tpm0: auth session is active
> > 
> > messages in our logs. This is emitted (once per boot) by 
> > tpm2_start_auth_session() if the auth sessions is already active
> > when it is called.
> > 
> > Investigating I think this is because tpm2_pcr_extend() calls 
> > tpm_buf_append_hmac_session() which sets TPM2_SA_CONTINUE_SESSION
> > so tpm_buf_check_hmac_response() does not cleanup the auth session,
> > but then doesn't call tpm2_end_auth_session().
> > 
> > Looking at tpm2_get_random() it uses TPM2_SA_CONTINUE_SESSION but
> > *also* cleans up with tpm2_end_auth_session().
> > 
> > I'd be sending a patch proposing the addition of
> > tpm2_end_auth_session() to the end of tpm2_pcr_extend() but I
> > recall a bunch of discussion about trying to cache the HMAC session
> > to improve IMA performance, so I don't know if perhaps we should be
> > dropping the warning instead?
> 
> Hi Jonathan,
> 
> That suggestion was nixed. 

Well it's also upstream as

https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=df745e25098dcb2f706399c0d06dd8d1bab6b6ec

even though it didn't work out for large numbers of extends.  However,
that commit introduced this message on a warn once behaviour, so it
seems to be expected that this gets printed once for some reason.  From
a code flow point of view, the lazy session handling seems to be
working correctly, so I think just dropping the warn is correct.

Regards,

James

Re: Unbalanced TPM2 HMAC session calls

[Mimi Zohar]

On Thu, 2025-03-06 at 11:30 -0800, James Bottomley wrote:
> On Thu, 2025-03-06 at 13:59 -0500, Mimi Zohar wrote:
> > On Thu, 2025-03-06 at 15:15 +0000, Jonathan McDowell wrote:
> > > We're seeing a lot of:
> > > 
> > > tpm tpm0: auth session is active
> > > 
> > > messages in our logs. This is emitted (once per boot) by 
> > > tpm2_start_auth_session() if the auth sessions is already active
> > > when it is called.
> > > 
> > > Investigating I think this is because tpm2_pcr_extend() calls 
> > > tpm_buf_append_hmac_session() which sets TPM2_SA_CONTINUE_SESSION
> > > so tpm_buf_check_hmac_response() does not cleanup the auth session,
> > > but then doesn't call tpm2_end_auth_session().
> > > 
> > > Looking at tpm2_get_random() it uses TPM2_SA_CONTINUE_SESSION but
> > > *also* cleans up with tpm2_end_auth_session().
> > > 
> > > I'd be sending a patch proposing the addition of
> > > tpm2_end_auth_session() to the end of tpm2_pcr_extend() but I
> > > recall a bunch of discussion about trying to cache the HMAC session
> > > to improve IMA performance, so I don't know if perhaps we should be
> > > dropping the warning instead?
> > 
> > Hi Jonathan,
> > 
> > That suggestion was nixed. 
> 
> Well it's also upstream as
> 
> https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=df745e25098dcb2f706399c0d06dd8d1bab6b6ec
> 
> even though it didn't work out for large numbers of extends.

Oh, right!  That patch definitely helped with performance, just not enough. 
Without that patch, some of my test systems wouldn't boot.

Mimi

> However,
> that commit introduced this message on a warn once behaviour, so it
> seems to be expected that this gets printed once for some reason.  From
> a code flow point of view, the lazy session handling seems to be
> working correctly, so I think just dropping the warn is correct.
> 
> Regards,
> 
> James
> 

Re: Unbalanced TPM2 HMAC session calls

[Jarkko Sakkinen]

On Thu, Mar 06, 2025 at 03:15:39PM +0000, Jonathan McDowell wrote:
> We're seeing a lot of:
> 
> tpm tpm0: auth session is active
> 
> messages in our logs. This is emitted (once per boot) by 
> tpm2_start_auth_session() if the auth sessions is already active when it 
> is called.

It's by design actually:

https://web.git.kernel.org/pub/scm/linux/kernel/git/jarkko/linux-tpmdd.git/commit/?id=df745e25098dc

> Investigating I think this is because tpm2_pcr_extend() calls 
> tpm_buf_append_hmac_session() which sets TPM2_SA_CONTINUE_SESSION so 
> tpm_buf_check_hmac_response() does not cleanup the auth session, but 
> then doesn't call tpm2_end_auth_session().
> 
> Looking at tpm2_get_random() it uses TPM2_SA_CONTINUE_SESSION but *also* 
> cleans up with tpm2_end_auth_session().
> 
> I'd be sending a patch proposing the addition of tpm2_end_auth_session() 
> to the end of tpm2_pcr_extend() but I recall a bunch of discussion 
> about trying to cache the HMAC session to improve IMA performance, so I 
> don't know if perhaps we should be dropping the warning instead?
> 
> (As an aside, I'm not clear dropping the warning is enough, as I can't 
> see where the session otherwise gets cleaned up other than by accident 
> when the RNG tries to get more randomness.)

It would be appropriate action, or relaxing it into pr_debug().

> 
> J.
> 
> -- 
> I've got a trigger inside.

BR, Jarkko

Re: Unbalanced TPM2 HMAC session calls

[Jarkko Sakkinen]

On Thu, Mar 06, 2025 at 11:30:01AM -0800, James Bottomley wrote:
> On Thu, 2025-03-06 at 13:59 -0500, Mimi Zohar wrote:
> > On Thu, 2025-03-06 at 15:15 +0000, Jonathan McDowell wrote:
> > > We're seeing a lot of:
> > > 
> > > tpm tpm0: auth session is active
> > > 
> > > messages in our logs. This is emitted (once per boot) by 
> > > tpm2_start_auth_session() if the auth sessions is already active
> > > when it is called.
> > > 
> > > Investigating I think this is because tpm2_pcr_extend() calls 
> > > tpm_buf_append_hmac_session() which sets TPM2_SA_CONTINUE_SESSION
> > > so tpm_buf_check_hmac_response() does not cleanup the auth session,
> > > but then doesn't call tpm2_end_auth_session().
> > > 
> > > Looking at tpm2_get_random() it uses TPM2_SA_CONTINUE_SESSION but
> > > *also* cleans up with tpm2_end_auth_session().
> > > 
> > > I'd be sending a patch proposing the addition of
> > > tpm2_end_auth_session() to the end of tpm2_pcr_extend() but I
> > > recall a bunch of discussion about trying to cache the HMAC session
> > > to improve IMA performance, so I don't know if perhaps we should be
> > > dropping the warning instead?
> > 
> > Hi Jonathan,
> > 
> > That suggestion was nixed. 
> 
> Well it's also upstream as
> 
> https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=df745e25098dcb2f706399c0d06dd8d1bab6b6ec
> 
> even though it didn't work out for large numbers of extends.  However,
> that commit introduced this message on a warn once behaviour, so it
> seems to be expected that this gets printed once for some reason.  From
> a code flow point of view, the lazy session handling seems to be
> working correctly, so I think just dropping the warn is correct.

+1

> 
> Regards,
> 
> James

BR, Jarkko

[PATCH] tpm: Drop warning when an auth session is active

[Jonathan McDowell]

Auth sessions are lazily flushed since commit df745e25098dc ("tpm:
Lazily flush the auth session"), so it's expected that we might try to
start a new session when one is still active.

Signed-off-by: Jonathan McDowell <noodles@meta.com>
---
 drivers/char/tpm/tpm2-sessions.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/char/tpm/tpm2-sessions.c b/drivers/char/tpm/tpm2-sessions.c
index b70165b588ec..2d2c192ebb14 100644
--- a/drivers/char/tpm/tpm2-sessions.c
+++ b/drivers/char/tpm/tpm2-sessions.c
@@ -982,7 +982,6 @@ int tpm2_start_auth_session(struct tpm_chip *chip)
 	int rc;
 
 	if (chip->auth) {
-		dev_warn_once(&chip->dev, "auth session is active\n");
 		return 0;
 	}
 
-- 
2.48.1

[PATCH] tpm: Lazily flush auth session when getting random data

[Jonathan McDowell]

From: Jonathan McDowell <noodles@meta.com>

Lazy flushing of TPM auth sessions was introduced to speed up IMA
measurments into the TPM. Make use of it in tpm2_get_random as well,
which has the added benefit of not needlessly cleaning up the session
that IMA is using when there are no userspace accesses taking place.

Command trace before for every call:

hwrng (0x00000161): 14 (52965242 ns)
hwrng (0x00000176): 48 (161612432 ns)
hwrng (0x00000165): 10 (2410494 ns)
hwrng (0x0000017B): 117 (70699883 ns)
hwrng (0x0000017B): 117 (70959666 ns)
hwrng (0x00000165): 10 (2756827 ns)

After, with repeated calls showing no setup:

hwrng (0x00000161): 14 (53044582 ns)
hwrng (0x00000176): 48 (160491333 ns)
hwrng (0x00000165): 10 (2408220 ns)
hwrng (0x0000017B): 117 (70695037 ns)
hwrng (0x0000017B): 117 (70994984 ns)
hwrng (0x0000017B): 117 (70195388 ns)
hwrng (0x0000017B): 117 (70973835 ns)

Signed-off-by: Jonathan McDowell <noodles@meta.com>
---
 drivers/char/tpm/tpm2-cmd.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/char/tpm/tpm2-cmd.c b/drivers/char/tpm/tpm2-cmd.c
index dfdcbd009720..524d802ede26 100644
--- a/drivers/char/tpm/tpm2-cmd.c
+++ b/drivers/char/tpm/tpm2-cmd.c
@@ -359,7 +359,6 @@ int tpm2_get_random(struct tpm_chip *chip, u8 *dest, size_t max)
 	} while (retries-- && total < max);
 
 	tpm_buf_destroy(&buf);
-	tpm2_end_auth_session(chip);
 
 	return total ? total : -EIO;
 out:
-- 
2.48.1

Re: [PATCH] tpm: Lazily flush auth session when getting random data

[Jarkko Sakkinen]

On Fri, Mar 07, 2025 at 10:58:13AM +0000, Jonathan McDowell wrote:
> From: Jonathan McDowell <noodles@meta.com>
> 
> Lazy flushing of TPM auth sessions was introduced to speed up IMA
> measurments into the TPM. Make use of it in tpm2_get_random as well,
> which has the added benefit of not needlessly cleaning up the session
> that IMA is using when there are no userspace accesses taking place.
> 
> Command trace before for every call:
> 
> hwrng (0x00000161): 14 (52965242 ns)
> hwrng (0x00000176): 48 (161612432 ns)
> hwrng (0x00000165): 10 (2410494 ns)
> hwrng (0x0000017B): 117 (70699883 ns)
> hwrng (0x0000017B): 117 (70959666 ns)
> hwrng (0x00000165): 10 (2756827 ns)
> 
> After, with repeated calls showing no setup:
> 
> hwrng (0x00000161): 14 (53044582 ns)
> hwrng (0x00000176): 48 (160491333 ns)
> hwrng (0x00000165): 10 (2408220 ns)
> hwrng (0x0000017B): 117 (70695037 ns)
> hwrng (0x0000017B): 117 (70994984 ns)
> hwrng (0x0000017B): 117 (70195388 ns)
> hwrng (0x0000017B): 117 (70973835 ns)
> 
> Signed-off-by: Jonathan McDowell <noodles@meta.com>
> ---
>  drivers/char/tpm/tpm2-cmd.c | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/drivers/char/tpm/tpm2-cmd.c b/drivers/char/tpm/tpm2-cmd.c
> index dfdcbd009720..524d802ede26 100644
> --- a/drivers/char/tpm/tpm2-cmd.c
> +++ b/drivers/char/tpm/tpm2-cmd.c
> @@ -359,7 +359,6 @@ int tpm2_get_random(struct tpm_chip *chip, u8 *dest, size_t max)
>  	} while (retries-- && total < max);
>  
>  	tpm_buf_destroy(&buf);
> -	tpm2_end_auth_session(chip);
>  
>  	return total ? total : -EIO;
>  out:
> -- 
> 2.48.1
> 

Thanks for this. It is a good catch! I'll apply this over the weekend
when I apply Arm FF-A driver patches.

Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org>

BR, Jarkko

Re: [PATCH] tpm: Drop warning when an auth session is active

[Jarkko Sakkinen]

On Fri, Mar 07, 2025 at 10:56:44AM +0000, Jonathan McDowell wrote:
> Auth sessions are lazily flushed since commit df745e25098dc ("tpm:
> Lazily flush the auth session"), so it's expected that we might try to
> start a new session when one is still active.
> 
> Signed-off-by: Jonathan McDowell <noodles@meta.com>
> ---
>  drivers/char/tpm/tpm2-sessions.c | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/drivers/char/tpm/tpm2-sessions.c b/drivers/char/tpm/tpm2-sessions.c
> index b70165b588ec..2d2c192ebb14 100644
> --- a/drivers/char/tpm/tpm2-sessions.c
> +++ b/drivers/char/tpm/tpm2-sessions.c
> @@ -982,7 +982,6 @@ int tpm2_start_auth_session(struct tpm_chip *chip)
>  	int rc;
>  
>  	if (chip->auth) {
> -		dev_warn_once(&chip->dev, "auth session is active\n");
>  		return 0;
>  	}

OK so curly faces should be also removed but I can adjust this
(if you don't mind), so we save all of us from trouble of
going through additional review round?

>  
> -- 
> 2.48.1
> 

BR, Jarkko

Re: [PATCH] tpm: Drop warning when an auth session is active

[Jonathan McDowell]

On Fri, Mar 07, 2025 at 06:36:02PM +0200, Jarkko Sakkinen wrote:
> On Fri, Mar 07, 2025 at 10:56:44AM +0000, Jonathan McDowell wrote:
> > Auth sessions are lazily flushed since commit df745e25098dc ("tpm:
> > Lazily flush the auth session"), so it's expected that we might try to
> > start a new session when one is still active.
> > 
> > Signed-off-by: Jonathan McDowell <noodles@meta.com>
> > ---
> >  drivers/char/tpm/tpm2-sessions.c | 1 -
> >  1 file changed, 1 deletion(-)
> > 
> > diff --git a/drivers/char/tpm/tpm2-sessions.c b/drivers/char/tpm/tpm2-sessions.c
> > index b70165b588ec..2d2c192ebb14 100644
> > --- a/drivers/char/tpm/tpm2-sessions.c
> > +++ b/drivers/char/tpm/tpm2-sessions.c
> > @@ -982,7 +982,6 @@ int tpm2_start_auth_session(struct tpm_chip *chip)
> >  	int rc;
> >  
> >  	if (chip->auth) {
> > -		dev_warn_once(&chip->dev, "auth session is active\n");
> >  		return 0;
> >  	}
> 
> OK so curly faces should be also removed but I can adjust this
> (if you don't mind), so we save all of us from trouble of
> going through additional review round?

Doh! Shoulda caught that. Feel free to do the fix up.

J.

-- 
   "Why? - because it's f***ing    |  .''`.  Debian GNU/Linux Developer
     there!" -- Edmund Hilary      | : :' :  Happy to accept PGP signed
                                   | `. `'   or encrypted mail - RSA
                                   |   `-    key on the keyservers.

Re: [PATCH] tpm: Drop warning when an auth session is active

[Jarkko Sakkinen]

On Fri, Mar 07, 2025 at 05:25:36PM +0000, Jonathan McDowell wrote:
> On Fri, Mar 07, 2025 at 06:36:02PM +0200, Jarkko Sakkinen wrote:
> > On Fri, Mar 07, 2025 at 10:56:44AM +0000, Jonathan McDowell wrote:
> > > Auth sessions are lazily flushed since commit df745e25098dc ("tpm:
> > > Lazily flush the auth session"), so it's expected that we might try to
> > > start a new session when one is still active.
> > > 
> > > Signed-off-by: Jonathan McDowell <noodles@meta.com>
> > > ---
> > >  drivers/char/tpm/tpm2-sessions.c | 1 -
> > >  1 file changed, 1 deletion(-)
> > > 
> > > diff --git a/drivers/char/tpm/tpm2-sessions.c b/drivers/char/tpm/tpm2-sessions.c
> > > index b70165b588ec..2d2c192ebb14 100644
> > > --- a/drivers/char/tpm/tpm2-sessions.c
> > > +++ b/drivers/char/tpm/tpm2-sessions.c
> > > @@ -982,7 +982,6 @@ int tpm2_start_auth_session(struct tpm_chip *chip)
> > >  	int rc;
> > >  
> > >  	if (chip->auth) {
> > > -		dev_warn_once(&chip->dev, "auth session is active\n");
> > >  		return 0;
> > >  	}
> > 
> > OK so curly faces should be also removed but I can adjust this
> > (if you don't mind), so we save all of us from trouble of
> > going through additional review round?
> 
> Doh! Shoulda caught that. Feel free to do the fix up.

Sure np!

> J.

BR, Jarkko