From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: Sumit Garg <sumit.garg@linaro.org>
Cc: linux-integrity@vger.kernel.org,
Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Subject: Re: [PATCH URGENT FIX] security: keys: trusted: fix lost handle flush
Date: Fri, 13 Dec 2019 07:35:55 -0500 [thread overview]
Message-ID: <1576240555.3382.5.camel@HansenPartnership.com> (raw)
In-Reply-To: <CAFA6WYMpVDN9n4aVJQ+UU6gstKJjnPnSmJmkMJ8pS9dsgOcVmw@mail.gmail.com>
On Fri, 2019-12-13 at 11:10 +0530, Sumit Garg wrote:
> On Thu, 12 Dec 2019 at 23:28, James Bottomley
> <James.Bottomley@hansenpartnership.com> wrote:
> >
> > The original code, before it was moved into security/keys/trusted-
> > keys had a flush after the blob unseal. Without that flush, the
> > volatile handles increase in the TPM until it becomes unusable and
> > the system either has to be rebooted or the TPM volatile area
> > manually flushed. Fix by adding back the lost flush, which we now
> > have to export because of the relocation of the trusted key code
> > may cause the consumer to be modular.
> >
> > Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.c
> > om>
> > Fixes: 2e19e10131a0 ("KEYS: trusted: Move TPM2 trusted keys code")
> >
>
> Overall looks good to me with following minor comment.
>
> > ---
> > drivers/char/tpm/tpm.h | 1 -
> > drivers/char/tpm/tpm2-cmd.c | 1 +
> > include/linux/tpm.h | 1 +
> > security/keys/trusted-keys/trusted_tpm2.c | 1 +
> > 4 files changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/char/tpm/tpm.h b/drivers/char/tpm/tpm.h
> > index b9e1547be6b5..5620747da0cf 100644
> > --- a/drivers/char/tpm/tpm.h
> > +++ b/drivers/char/tpm/tpm.h
> > @@ -218,7 +218,6 @@ int tpm2_pcr_read(struct tpm_chip *chip, u32
> > pcr_idx,
> > int tpm2_pcr_extend(struct tpm_chip *chip, u32 pcr_idx,
> > struct tpm_digest *digests);
> > int tpm2_get_random(struct tpm_chip *chip, u8 *dest, size_t max);
> > -void tpm2_flush_context(struct tpm_chip *chip, u32 handle);
> > ssize_t tpm2_get_tpm_pt(struct tpm_chip *chip, u32 property_id,
> > u32 *value, const char *desc);
> >
> > diff --git a/drivers/char/tpm/tpm2-cmd.c b/drivers/char/tpm/tpm2-
> > cmd.c
> > index fdb457704aa7..13696deceae8 100644
> > --- a/drivers/char/tpm/tpm2-cmd.c
> > +++ b/drivers/char/tpm/tpm2-cmd.c
> > @@ -362,6 +362,7 @@ void tpm2_flush_context(struct tpm_chip *chip,
> > u32 handle)
> > tpm_transmit_cmd(chip, &buf, 0, "flushing context");
> > tpm_buf_destroy(&buf);
> > }
> > +EXPORT_SYMBOL_GPL(tpm2_flush_context);
> >
> > struct tpm2_get_cap_out {
> > u8 more_data;
> > diff --git a/include/linux/tpm.h b/include/linux/tpm.h
> > index 0d6e949ba315..03e9b184411b 100644
> > --- a/include/linux/tpm.h
> > +++ b/include/linux/tpm.h
> > @@ -403,6 +403,7 @@ extern int tpm_pcr_extend(struct tpm_chip
> > *chip, u32 pcr_idx,
> > extern int tpm_send(struct tpm_chip *chip, void *cmd, size_t
> > buflen);
> > extern int tpm_get_random(struct tpm_chip *chip, u8 *data, size_t
> > max);
> > extern struct tpm_chip *tpm_default_chip(void);
> > +void tpm2_flush_context(struct tpm_chip *chip, u32 handle);
>
> Shouldn't this be declared as "extern" similar to other APIs?
extern has no meaning for function declarations and our coding guide
does say do not use it but I think it's advisory not mandatory so I've
no objection to changing it if we prefer consistency over the style
guide.
> Also, I think we need "#else" part for this API as well.
No, we shouldn't ... the #else part is only for functions which are
called when the TPM isn't compiled in. That should never happen with
tpm2_flush_context, so if it ever does we want the compile to break.
James
next prev parent reply other threads:[~2019-12-13 20:36 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-12 17:58 [PATCH URGENT FIX] security: keys: trusted: fix lost handle flush James Bottomley
2019-12-12 19:02 ` Jerry Snitselaar
2019-12-13 5:40 ` Sumit Garg
2019-12-13 12:35 ` James Bottomley [this message]
2019-12-13 13:49 ` James Bottomley
2019-12-16 6:17 ` Sumit Garg
2019-12-16 6:58 ` James Bottomley
2019-12-17 2:05 ` Jarkko Sakkinen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1576240555.3382.5.camel@HansenPartnership.com \
--to=james.bottomley@hansenpartnership.com \
--cc=jarkko.sakkinen@linux.intel.com \
--cc=linux-integrity@vger.kernel.org \
--cc=sumit.garg@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox