[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <D1ITOT1F26RK.S2V3FRMXPAPD@kernel.org>
Date: Sat, 25 May 2024 18:15:43 +0300
From: "Jarkko Sakkinen" <jarkko@...nel.org>
To: "James Bottomley" <James.Bottomley@...senPartnership.com>,
<linux-integrity@...r.kernel.org>
Cc: <keyrings@...r.kernel.org>, <stable@...r.kernel.org>, "Mimi Zohar"
<zohar@...ux.ibm.com>, "David Howells" <dhowells@...hat.com>, "Paul Moore"
<paul@...l-moore.com>, "James Morris" <jmorris@...ei.org>, "Serge E.
Hallyn" <serge@...lyn.com>, <linux-security-module@...r.kernel.org>,
<linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] KEYS: trusted_tpm2: Only check options->keyhandle for
ASN.1
On Sat May 25, 2024 at 4:42 PM EEST, James Bottomley wrote:
> On Sat, 2024-05-25 at 15:36 +0300, Jarkko Sakkinen wrote:
> > tpm2_load_cmd incorrectly checks options->keyhandle also for the
> > legacy format, as also implied by the inline comment. Check
> > options->keyhandle when ASN.1 is loaded.
>
> No that's not right. keyhandle must be specified for the old format,
> because it's just the two private/public blobs and doesn't know it's
> parent. Since tpm2_key_decode() always places the ASN.1 parent into
> options->keyhandle, the proposed new code is fully redundant (options-
> >keyhandle must be non zero if the ASN.1 parsed correctly) but it loses
> the check that the loader must specify it for the old format.
>
> What the comment above the code you removed means is that the keyhandle
> must be non zero here, either extracted from the ASN.1 for the new
> format or specified on the command line for the old.
My code change was plain direct to the word interpreation of the
comment.
So I just take the last paragraph of yours and instead fix the
misleading comment:
/*
* Keyhandle must be non zero here, either extracted from the ASN.1 for
* the new format or specified on the command line for the old.
*/
BR, Jarkko
Powered by blists - more mailing lists