Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <20220823222526.1524851-1-evgreen@chromium.org>
 <20220823152108.v2.5.I6cdb522cb5ea28fcd1e35b4cd92cbd067f99269a@changeid> <202209201605.505F96D@keescook>
In-Reply-To: <202209201605.505F96D@keescook>
From:   Evan Green <evgreen@chromium.org>
Date:   Fri, 23 Sep 2022 15:23:17 -0700
Message-ID: <CAE=gft6wO0Hv+dgQG_xcPdQTCQxtBeJNo94hqivdO8rxvXjbbg@mail.gmail.com>
Subject: Re: [PATCH v2 05/10] security: keys: trusted: Verify creation data
To:     Kees Cook <keescook@chromium.org>
Cc:     LKML <linux-kernel@vger.kernel.org>,
        Gwendal Grignou <gwendal@chromium.org>,
        Eric Biggers <ebiggers@kernel.org>,
        Matthew Garrett <mgarrett@aurora.tech>,
        Jarkko Sakkinen <jarkko@kernel.org>,
        Mimi Zohar <zohar@linux.ibm.com>,
        linux-integrity@vger.kernel.org, Pavel Machek <pavel@ucw.cz>,
        apronin@chromium.org, Daniil Lunev <dlunev@google.com>,
        "Rafael J. Wysocki" <rjw@rjwysocki.net>,
        Linux PM <linux-pm@vger.kernel.org>,
        Jonathan Corbet <corbet@lwn.net>,
        "James E.J. Bottomley" <jejb@linux.ibm.com>,
        David Howells <dhowells@redhat.com>,
        Hao Wu <hao.wu@rubrik.com>, James Morris <jmorris@namei.org>,
        Matthew Garrett <matthewgarrett@google.com>,
        Paul Moore <paul@paul-moore.com>,
        "Serge E. Hallyn" <serge@hallyn.com>, axelj <axelj@axis.com>,
        keyrings@vger.kernel.org, linux-security-module@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Tue, Sep 20, 2022 at 4:07 PM Kees Cook <keescook@chromium.org> wrote:
>
> On Tue, Aug 23, 2022 at 03:25:21PM -0700, Evan Green wrote:
> > If a loaded key contains creation data, ask the TPM to verify that
> > creation data. This allows users like encrypted hibernate to know that
> > the loaded and parsed creation data has not been tampered with.
> >
> > Partially-sourced-from: Matthew Garrett <mjg59@google.com>
> > Signed-off-by: Evan Green <evgreen@chromium.org>
> >
> > ---
> > Source material for this change is at:
> > https://patchwork.kernel.org/project/linux-pm/patch/20210220013255.1083=
202-9-matthewgarrett@google.com/
> >
> > Changes in v2:
> >  - Adjust hash len by 2 due to new ASN.1 storage, and add underflow
> >    check.
> >
> >  include/linux/tpm.h                       |  1 +
> >  security/keys/trusted-keys/trusted_tpm2.c | 77 ++++++++++++++++++++++-
> >  2 files changed, 77 insertions(+), 1 deletion(-)
> >
> > diff --git a/include/linux/tpm.h b/include/linux/tpm.h
> > index 8320cbac6f4009..438f8bc0a50582 100644
> > --- a/include/linux/tpm.h
> > +++ b/include/linux/tpm.h
> > @@ -224,6 +224,7 @@ enum tpm2_command_codes {
> >       TPM2_CC_SELF_TEST               =3D 0x0143,
> >       TPM2_CC_STARTUP                 =3D 0x0144,
> >       TPM2_CC_SHUTDOWN                =3D 0x0145,
> > +     TPM2_CC_CERTIFYCREATION         =3D 0x014A,
> >       TPM2_CC_NV_READ                 =3D 0x014E,
> >       TPM2_CC_CREATE                  =3D 0x0153,
> >       TPM2_CC_LOAD                    =3D 0x0157,
> > diff --git a/security/keys/trusted-keys/trusted_tpm2.c b/security/keys/=
trusted-keys/trusted_tpm2.c
> > index 1d1470b880ca01..f81c6578c7f783 100644
> > --- a/security/keys/trusted-keys/trusted_tpm2.c
> > +++ b/security/keys/trusted-keys/trusted_tpm2.c
> > @@ -691,6 +691,74 @@ static int tpm2_unseal_cmd(struct tpm_chip *chip,
> >       return rc;
> >  }
> >
> > +/**
> > + * tpm2_certify_creation() - execute a TPM2_CertifyCreation command
> > + *
> > + * @chip: TPM chip to use
> > + * @payload: the key data in clear and encrypted form
> > + * @blob_handle: the loaded TPM handle of the key
> > + *
> > + * Return: 0 on success
> > + *         -EINVAL on tpm error status
> > + *         < 0 error from tpm_send or tpm_buf_init
> > + */
> > +static int tpm2_certify_creation(struct tpm_chip *chip,
> > +                              struct trusted_key_payload *payload,
> > +                              u32 blob_handle)
> > +{
> > +     struct tpm_header *head;
> > +     struct tpm_buf buf;
> > +     int rc;
> > +
> > +     rc =3D tpm_buf_init(&buf, TPM2_ST_SESSIONS, TPM2_CC_CERTIFYCREATI=
ON);
> > +     if (rc)
> > +             return rc;
> > +
> > +     /* Use TPM_RH_NULL for signHandle */
> > +     tpm_buf_append_u32(&buf, 0x40000007);
> > +
> > +     /* Object handle */
> > +     tpm_buf_append_u32(&buf, blob_handle);
> > +
> > +     /* Auth */
> > +     tpm_buf_append_u32(&buf, 9);
> > +     tpm_buf_append_u32(&buf, TPM2_RS_PW);
> > +     tpm_buf_append_u16(&buf, 0);
> > +     tpm_buf_append_u8(&buf, 0);
> > +     tpm_buf_append_u16(&buf, 0);
> > +
> > +     /* Qualifying data */
> > +     tpm_buf_append_u16(&buf, 0);
> > +
> > +     /* Creation data hash */
> > +     if (payload->creation_hash_len < 2) {
> > +             rc =3D -EINVAL;
> > +             goto out;
> > +     }
> > +
> > +     tpm_buf_append_u16(&buf, payload->creation_hash_len - 2);
> > +     tpm_buf_append(&buf, payload->creation_hash + 2,
> > +                    payload->creation_hash_len - 2);
> > +
> > +     /* signature scheme */
> > +     tpm_buf_append_u16(&buf, TPM_ALG_NULL);
> > +
> > +     /* creation ticket */
> > +     tpm_buf_append(&buf, payload->tk, payload->tk_len);
> > +
> > +     rc =3D tpm_transmit_cmd(chip, &buf, 6, "certifying creation data"=
);
> > +     if (rc)
> > +             goto out;
> > +
> > +     head =3D (struct tpm_header *)buf.data;
> > +
> > +     if (head->return_code !=3D 0)
> > +             rc =3D -EINVAL;
>
> Do you have a reference to this TPM command spec? I have a dim memory of
> some of these commands having success/failure listed separately from
> other things in the reply. Is that true here? (i.e. is the return_code
> only about "yes I replied" and there is a missing "but the answer is no"
> check?)

Here's the link to the volumes:
https://trustedcomputinggroup.org/resource/tpm-library-specification/

The description for TPM2_CertifyCreation in part 3 says this:
```
This command is used to prove the association between an object and
its creation data. The TPM will
validate that the ticket was produced by the TPM and that the ticket
validates the association between a
loaded public area and the provided hash of the creation data (creationHash=
).
NOTE 1 See 18.1 for description of how the signing scheme is selected.
The TPM will create a test ticket using the Name associated with
objectHandle and creationHash as:
HMAC(proof, (TPM_ST_CREATION || objectHandle=E2=86=92Name || creationHash))=
 (4)
This ticket is then compared to creation ticket. If the tickets are
not the same, the TPM shall return
TPM_RC_TICKET.
If the ticket is valid, then the TPM will create a TPMS_ATTEST
structure and place creationHash of the
command in the creationHash field of the structure. The Name
associated with objectHandle will be
included in the attestation data that is then signed using the key
associated with signHandle.
```

So my aim there was to check responseCode in the response, and as long
as it's success and not RC_TICKET I should be ok. Though I see now
from other examples I should have used
(be32_to_cpu(header->return_code) !=3D TPM2_RC_SUCCESS). I will change
that.


>
> > +out:
> > +     tpm_buf_destroy(&buf);
> > +     return rc;
> > +}
> > +
> >  /**
> >   * tpm2_unseal_trusted() - unseal the payload of a trusted key
> >   *
> > @@ -716,8 +784,15 @@ int tpm2_unseal_trusted(struct tpm_chip *chip,
> >               goto out;
> >
> >       rc =3D tpm2_unseal_cmd(chip, payload, options, blob_handle);
> > -     tpm2_flush_context(chip, blob_handle);
> > +     if (rc)
> > +             goto flush;
> > +
> > +     if (payload->creation_len)
> > +             rc =3D tpm2_certify_creation(chip, payload, blob_handle);
> >
> > +
> > +flush:
> > +     tpm2_flush_context(chip, blob_handle);
> >  out:
> >       tpm_put_ops(chip);
> >
> > --
> > 2.31.0
> >
>
> Otherwise looks good to me. :)
>
> --
> Kees Cook