linux-kernel - Re: [PATCH v6] tpm: Add Upgrade/Reduced mode support for TPM2 modules

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20210930163005.yd4mfqybetorx5f5@lnxborysmn.se.axis.com>
Date:   Thu, 30 Sep 2021 18:30:05 +0200
From:   Borys Movchan <borysmn@...s.com>
To:     Jarkko Sakkinen <jarkko@...nel.org>
CC:     Peter Huewe <peterhuewe@....de>, Jason Gunthorpe <jgg@...pe.ca>,
        kernel <kernel@...s.com>,
        "linux-integrity@...r.kernel.org" <linux-integrity@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v6] tpm: Add Upgrade/Reduced mode support for TPM2 modules

Coming back to my change, a quick reminder of the latest questions and some
updated answers:

> > If detected that the TPM is in the Upgrade or Failure mode, the function
> > sets TPM_CHIP_FLAG_LIMITED_MODE flag.
>
> Does this apply for TPM 1.2? Are there differences?

As I mentioned earlier, I am not familiar with TPM 1.2. However, to
generalize the answer, such a state, like a firmware upgrade does make
sense on TPM 1.2. From what I know it is performed using different calls
to TPM but the concept is there.

> Maybe for consistency call it TPM_CHIP_FLAG_UPGRADE_MODE? It makes easier
> to "connect dots" later on (has probably something to do TPM_RC_UPGRADE).

Reconsidered and implemented appropriate change. See the patch.

> > -     if (chip->flags & TPM_CHIP_FLAG_TPM2) {
> > +     if (chip->flags & TPM_CHIP_FLAG_TPM2 && !(chip->flags & TPM_CHIP_FLAG_LIMITED_MODE)) {
>
> You cannot rely on validity of TPM_CHIP_FLAG_TPM2, as tpm_tis driver
> uses a TPM command to probe the TPM version.

I never intended to relay on TPM_CHIP_FLAG_TPM2. In this case the point
to avoid calling cdev_device_add if the chip is not TPM2 or is in
firmware Upgrade/Recovery mode.

> >        rc = tpm2_get_cc_attrs_tbl(chip);
> > +     if (rc) {
>
> Why all rc's apply?

The standard doesn't specify what RC should be returned if TPM is in
Recovery mode. What the standard agrees on is that the underlying call
will fail.

> > +             dev_info(&chip->dev, "TPM is in failure mode, functionality limited\n");
>
> Here is again a different name for the same thing (different than
> TPM_CHIP_FLAG_LIMITED_MODE).

The logic behind this check goes like that: Assume that if we reached
this point TPM is not in Upgrade mode. Although, it can still be in
Recovery mode. If the tpm2_get_cc_attrs_tbl() call fails, then my
assumption is that TPM requires firmware recovery.

This mode is introduced to handle situations when TPM firmware Upgrade
failed. In such a case TPM allows to flash only original firmware to bring
the functionality back. There is a predefined list of calls to which TPM
is going to answer in this mode. Responses to other calls are vendor-dependent.

Another assumption here is that if for some reason there is a communication
error occurred at this point it will be caught here. Any better ideas
on how to handle this are welcome.

--
Kind regards,
Borys