mirror of https://lore.kernel.org/lkml/
 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 v2] keys/trusted/tpm2: Validate TPM2_Create object sizes separately
Date: Sat, 26 Sep 2026 01:44:46 +0300	[thread overview]
Message-ID: <arb5XnpAHe3SZEfv@kernel.org> (raw)
In-Reply-To: <bec84181-565a-478e-a485-7f63819024cc@linux.ibm.com>

On Fri, Sep 25, 2026 at 08:42:09PM +0530, Srish Srinivasan wrote:
> Hi Jarkko,
> Thanks for taking a look.
> 
> On 9/25/26 4:51 PM, Jarkko Sakkinen wrote:
> > On Fri, Sep 18, 2026 at 12:18:25PM +0530, Srish Srinivasan wrote:
> > > On 9/18/26 7:40 AM, Jarkko Sakkinen wrote:
> > > > On Thu, Sep 10, 2026 at 03:32:22PM +0530, Srish Srinivasan wrote:
> > > > > TPM2_Create returns outPrivate, outPublic, creationData, creationHash and
> > > > > creationTicket in its response parameter area. However, only outPrivate and
> > > > > outPublic are included in the trusted key blob. The size of the blob is
> > > > > therefore not determined by the size of the complete response parameter
> > > > > area.
> > > > > 
> > > > > tpm2_seal_trusted() currently compares the size of the complete response
> > > > > parameter area against MAX_BLOB_SIZE. This can reject a valid response
> > > > > when the remaining response outputs cause the entire response parameter
> > > > > area to exceed MAX_BLOB_SIZE, even though the outPrivate and outPublic
> > > > > TPM2B structures consumed by tpm2_key_encode() remain small enough to be
> > > > > encoded in the key blob.
> > > > > 
> > > > > This is observed when creating larger trusted keys using an swtpm TPM 2.0
> > > > > emulator backed by libtpms.
> > > > > 
> > > > > For example, requesting a 113-byte key succeeds, 114 fails.
> > > > > 
> > > > > ~$ keyctl add trusted trusted_key1 "new 113 keyhandle=0x81000001" @u
> > > > > 520504613
> > > > > ~$ keyctl add trusted trusted_key2 "new 114 keyhandle=0x81000001" @u
> > > > > add_key: Argument list too long
> > > > > ~$
> > > > > 
> > > > > Remove the MAX_BLOB_SIZE check on the complete response parameter area.
> > > > > Instead, use the response length passed to tpm2_key_encode() to validate
> > > > > that the outPrivate and outPublic TPM2B structures are fully contained
> > > > > in the response before accessing them.
> > > > > 
> > > > > Previously, a response parameter area larger than MAX_BLOB_SIZE was
> > > > > rejected with -E2BIG before ASN.1 encoding. With this change, if the
> > > > > resulting encoded blob does not fit in payload->blob, the error returned by
> > > > > asn1_encode_sequence() is propagated instead.
> > > > > 
> > > > > Signed-off-by: Srish Srinivasan <ssrish@linux.ibm.com>
> > > > > ---
> > > > > Changelog:
> > > > > 
> > > > >    v2:
> > > > >     - Exclude a comment pointed out by Jarkko
> > > > > 
> > > > >    security/keys/trusted-keys/trusted_tpm2.c | 35 +++++++++++++++++------
> > > > >    1 file changed, 27 insertions(+), 8 deletions(-)
> > > > > 
> > > > > diff --git a/security/keys/trusted-keys/trusted_tpm2.c b/security/keys/trusted-keys/trusted_tpm2.c
> > > > > index 01f18bb37047..cbec4f591952 100644
> > > > > --- a/security/keys/trusted-keys/trusted_tpm2.c
> > > > > +++ b/security/keys/trusted-keys/trusted_tpm2.c
> > > > > @@ -24,24 +24,42 @@ static int tpm2_key_encode(struct trusted_key_payload *payload,
> > > > >    			   u8 *src, u32 len)
> > > > >    {
> > > > >    	const int SCRATCH_SIZE = PAGE_SIZE;
> > > > > -	u8 *scratch = kmalloc(SCRATCH_SIZE, GFP_KERNEL);
> > > > > -	u8 *work = scratch, *work1;
> > > > > -	u8 *end_work = scratch + SCRATCH_SIZE;
> > > > > +	u8 *scratch;
> > > > > +	u8 *work, *work1;
> > > > > +	u8 *end_work;
> > > > >    	u8 *priv, *pub;
> > > > > -	u16 priv_len, pub_len;
> > > > > +	u32 priv_len, pub_len;
> > > > >    	int ret;
> > > > > -	priv_len = get_unaligned_be16(src) + 2;
> > > > > +	if (len < sizeof(__be16))
> > > > > +		return -EFAULT;
> > > > > +
> > > > > +	priv_len = get_unaligned_be16(src);
> > > > > +	if (priv_len > len - sizeof(__be16))
> > > > > +		return -EFAULT;
> > > > > +
> > > > > +	priv_len += sizeof(__be16);
> > > > >    	priv = src;
> > > > > +	if (len - priv_len < sizeof(__be16))
> > > > > +		return -EFAULT;
> > > > This caused for me some head scrathing tbh.
> > > > 
> > > > See:
> > > > 
> > > > 1. len >= 2
> > > > 2. priv_len <= len - 2
> > > > 3. 2 - priv_len + priv_len <= 2 - priv_len + len - 2
> > > > 4. 2 <= len - priv_len
> > > > 
> > > > Is this check required?
> > > 
> > > Hi Jarkko,
> > > Thanks for taking a look.
> > > 
> > > The preceding check,
> > > 
> > > 
> > >      if (priv_len > len - sizeof(__be16))
> > >          return -EFAULT;
> > > 
> > > 
> > > ensures that the complete TPM2B_PRIVATE, including its size field,
> > > fits within len. After this check, priv_len is incremented by 2 and
> > > therefore represents the complete TPM2B_PRIVATE length.
> > > 
> > > 
> > > The check you pointed out,
> > > 
> > > 
> > >      if (len - priv_len < sizeof(__be16))
> > >          return -EFAULT;
> > > 
> > > 
> > > then ensures that at least 2 bytes remain for reading the following
> > > TPM2B_PUBLIC size field.
> > OK, maybe I got something wrong in my deduction but I'm not
> > still entirely sure whether this is leanest way to do these
> > checks.
> 
> 
> Sure, I will simplify this. Would the following be better?
> 
> 
>     if (len < 4)
>       return -EINVAL;
> 
>     priv_len = get_unaligned_be16(src) + 2;
>     if (priv_len + 2 > len)
>       return -EIO;
> 
>     priv = src;
>     src += priv_len;
> 
>     pub_len = get_unaligned_be16(src) + 2;
>     if (priv_len + pub_len > len)
>       return -EIO;
> 
>     pub = src;
> 
> 
> The first check ensures that len can contain both TPM2B size fields.
> The second verifies that the complete TPM2B_PRIVATE leaves room for the
> TPM2B_PUBLIC size field. The final check ensures that both the complete
> TPM2B_PRIVATE and TPM2B_PUBLIC structures fit within len.
> 
> > 
> > I'll iterate some other remarks so that this can move forward.
> > 
> > I was not either entirely sure why this was done:
> > 
> > -	u16 priv_len, pub_len;
> > +	u32 priv_len, pub_len;
> 
> 
> Yes, so the change from u16 to u32 was because the values stored in priv_len
> and
> pub_len include both the 16-bit value read from the response and the
> two-byte TPM2B
> size field.
> 
> 
> > 
> > Why wrong len causes -EFAULT and not -EINVAL? EFAULT is for
> > memory failures. Probably two that follow should return -EIO.
> 
> 
> Agreed, I will fix this.
> 
> 
> > 
> > One more that came to mind:
> > 
> > -	priv_len = get_unaligned_be16(src) + 2;
> > +	if (len < sizeof(__be16))
> > +		return -EFAULT;
> > +
> > +	priv_len = get_unaligned_be16(src);
> > +	if (priv_len > len - sizeof(__be16))
> > +		return -EFAULT;
> > +
> > +	priv_len += sizeof(__be16);
> > 
> > Removing the line above is not necessary and neither is the last
> > the last statement if you just change your check accordingly.
> 
> 
> Yes, that's right. And I have made this change in the diff
> that I have pasted above.
> 
> Please let me know if this looks better now.
> 
> And, thanks for the feedback.

Yeah, so this is a patch that needs a few iterations I'm not against
the change itself per se :-)

I think it would make sense to declare "u8 *scratch __free(kfree)"
while at it so that rollback does not complicate this function 
further.

> 
> > 
> > 
> > BR, Jarkko
> 
> 
> Thanks,
> Srish.
> 

Br, Jarkko

      reply	other threads:[~2026-09-25 22:44 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-10 10:02 Srish Srinivasan
2026-09-18  2:10 ` Jarkko Sakkinen
2026-09-18  6:48   ` Srish Srinivasan
2026-09-25 11:21     ` Jarkko Sakkinen
2026-09-25 15:12       ` Srish Srinivasan
2026-09-25 22:44         ` Jarkko Sakkinen [this message]

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=arb5XnpAHe3SZEfv@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®