All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jarkko Sakkinen <jarkko@kernel.org>
To: Srish Srinivasan <ssrish@linux.ibm.com>
Cc: linux-integrity@vger.kernel.org, keyrings@vger.kernel.org,
	James.Bottomley@hansenpartnership.com, zohar@linux.ibm.com,
	stefanb@linux.ibm.com, linux-kernel@vger.kernel.org,
	linux-security-module@vger.kernel.org, nayna@linux.ibm.com,
	rnsastry@linux.ibm.com
Subject: Re: [PATCH v9 0/2] Move TPM-specific fields out of trusted_key_options
Date: Fri, 18 Sep 2026 05:12:41 +0300	[thread overview]
Message-ID: <aqyeGbZKvLxaDwju@kernel.org> (raw)
In-Reply-To: <20260912062950.279104-1-ssrish@linux.ibm.com>

On Sat, Sep 12, 2026 at 11:59:48AM +0530, Srish Srinivasan wrote:
> struct trusted_key_options contains fields that are specific to the TPM
> trusted source, resulting in the accumulation backend-specific fields in
> the generic options structure.
> 
> Move the TPM-specific fields into a new struct trusted_key_tpm and store a
> pointer to it in the private member of struct trusted_key_options.
> 
> As a preparatory change, return immediately after a TPM unseal failure to
> prevent pcrlock() from overwriting the unseal error.
> 
> Changelog:
> 
>  v9:
>   - Resent the full patch set with consistent v9 subject prefix
>   - Corrected patch 1/2, which was sent as v3 in v8, which caused b4 to
>     flag the series as incomplete
> 
>  v8:
>   - Rebase onto commit
>     adc6a9f6d997 ("KEYS: trusted: Fix tpm2_load_cmd() boundary check")
>     to resolve the merge conflicts
>   - Include Jarkko's Reviewed-by tag
> 
>  v7:
>   - Fix a memory leak in the preparatory fix
> 
>  v6:
>   - Add a preparatory fix to return immediately after a TPM unseal failure
>   - Replace explicit cleanup with __free(kfree_sensitive) in the TPM seal
>     and unseal paths, as suggested by Jarkko
> 
>  v5:
>   - Rename struct trusted_tpm_options to struct trusted_key_tpm, as
>     suggestedby Jarkko.
> 
>  v4:
>   - Rebased onto mainline after tpm-buf memory-safe allocation changes were
>     merged
>   - Resolved the resulting merge conflicts
> 
>  v3:
>   - Exclude the preparatory clean up patch as the problem has been
>     addressed in commit
>     9ec4175a30eb ("KEYS: trusted: Debugging as a feature")
> 
>  v2:
>   - Exclude the bug-fix patch as it has already been applied to 6.19-rc7
>   - Rename instances of trusted_tpm_options from tpm_opts to private
>   - Use pr_debug and KERN_DEBUG for logging debug messages (preparatory
>     clean up patch)
>   - Address other minor comments from Jarkko
> 
> Srish Srinivasan (2):
>   keys/trusted_keys: return immediately after TPM unseal failure
>   keys/trusted_keys: move TPM-specific fields into struct
>     trusted_key_tpm
> 
>  include/keys/trusted-type.h               |  11 --
>  include/keys/trusted_tpm.h                |  14 +++
>  security/keys/trusted-keys/trusted_tpm1.c | 125 ++++++++++++----------
>  security/keys/trusted-keys/trusted_tpm2.c |  50 +++++----
>  4 files changed, 113 insertions(+), 87 deletions(-)
> 
> -- 
> 2.53.0
> 

I applied v8 already. Please check from my tree whether this needs
reapplying or not.

BR, Jarkko

  parent reply	other threads:[~2026-09-18  2:12 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-12  6:29 [PATCH v9 0/2] Move TPM-specific fields out of trusted_key_options Srish Srinivasan
2026-09-12  6:29 ` [PATCH v9 1/2] keys/trusted_keys: return immediately after TPM unseal failure Srish Srinivasan
2026-09-12  6:29 ` [PATCH v9 2/2] keys/trusted_keys: move TPM-specific fields into struct trusted_key_tpm Srish Srinivasan
2026-09-18  2:12 ` Jarkko Sakkinen [this message]
2026-09-18  4:23   ` [PATCH v9 0/2] Move TPM-specific fields out of trusted_key_options Srish Srinivasan

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=aqyeGbZKvLxaDwju@kernel.org \
    --to=jarkko@kernel.org \
    --cc=James.Bottomley@hansenpartnership.com \
    --cc=keyrings@vger.kernel.org \
    --cc=linux-integrity@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=nayna@linux.ibm.com \
    --cc=rnsastry@linux.ibm.com \
    --cc=ssrish@linux.ibm.com \
    --cc=stefanb@linux.ibm.com \
    --cc=zohar@linux.ibm.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.