[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aNQnb93PiaJ80jEY@kernel.org>
Date: Wed, 24 Sep 2025 20:16:31 +0300
From: Jarkko Sakkinen <jarkko@...nel.org>
To: Jonathan McDowell <noodles@...th.li>
Cc: linux-integrity@...r.kernel.org,
Jarkko Sakkinen <jarkko.sakkinen@...nsys.com>,
Peter Huewe <peterhuewe@....de>, Jason Gunthorpe <jgg@...pe.ca>,
David Howells <dhowells@...hat.com>,
Paul Moore <paul@...l-moore.com>, James Morris <jmorris@...ei.org>,
"Serge E. Hallyn" <serge@...lyn.com>,
James Bottomley <James.Bottomley@...senpartnership.com>,
Mimi Zohar <zohar@...ux.ibm.com>,
Stefano Garzarella <sgarzare@...hat.com>,
open list <linux-kernel@...r.kernel.org>,
"open list:KEYS/KEYRINGS" <keyrings@...r.kernel.org>,
"open list:SECURITY SUBSYSTEM" <linux-security-module@...r.kernel.org>
Subject: Re: [PATCH 1/4] tpm: Use -EPERM as fallback error code in
tpm_ret_to_err
On Wed, Sep 24, 2025 at 09:32:33AM +0100, Jonathan McDowell wrote:
> On Mon, Sep 22, 2025 at 07:43:14PM +0300, Jarkko Sakkinen wrote:
> > From: Jarkko Sakkinen <jarkko.sakkinen@...nsys.com>
> >
> > Using -EFAULT here was not the best idea for tpm_ret_to_err as the fallback
> > error code as it is no concise with trusted keys.
> >
> > Change the fallback as -EPERM, process TPM_RC_HASH also in tpm_ret_to_err,
> > and by these changes make the helper applicable for trusted keys.
> >
> > Fixes: 539fbab37881 ("tpm: Mask TPM RC in tpm2_start_auth_session()")
> > Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@...nsys.com>
> > ---
> > include/linux/tpm.h | 9 +++++---
> > security/keys/trusted-keys/trusted_tpm2.c | 26 ++++++-----------------
> > 2 files changed, 13 insertions(+), 22 deletions(-)
> >
> > diff --git a/include/linux/tpm.h b/include/linux/tpm.h
> > index dc0338a783f3..667d290789ca 100644
> > --- a/include/linux/tpm.h
> > +++ b/include/linux/tpm.h
> > @@ -449,13 +449,16 @@ static inline ssize_t tpm_ret_to_err(ssize_t ret)
> > if (ret < 0)
> > return ret;
> >
> > - switch (tpm2_rc_value(ret)) {
> > - case TPM2_RC_SUCCESS:
> > + if (!ret)
> > return 0;
>
> Fold this into the check above to get:
>
> if (ret <= 0)
>
> ?
This is really a glitch in this patch, and I think following what
Stefano suggested is the right call:
https://lore.kernel.org/linux-integrity/tnxfamnvxoanaihka3em7ktmzkervoea43zn2l3mqxvnuivb6n@p5nn34vns3zf/
I.e., a random change to something that was not broken in the first
place :-) Never a good idea (not even in microscale), except something
super cosmetic like maybe grouping constants and stylistic stuff like
that.
BR, Jarkko
Powered by blists - more mailing lists