linux-kernel - [PATCH 0/3 v3] tpm: add update_durations class op to allow override of chip supplied values

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-next>] [day] [month] [year] [list]

Message-Id: <20190829204947.2591-1-jsnitsel@redhat.com>
Date:   Thu, 29 Aug 2019 13:49:44 -0700
From:   Jerry Snitselaar <jsnitsel@...hat.com>
To:     linux-integrity@...r.kernel.org
Cc:     linux-kernel@...r.kernel.org, Alexey Klimov <aklimov@...hat.com>,
        Jarkko Sakkinen <jarkko.sakkinen@...ux.intel.com>,
        Peter Huewe <peterhuewe@....de>, Jason Gunthorpe <jgg@...pe.ca>
Subject: [PATCH 0/3 v3] tpm: add update_durations class op to allow override of chip supplied values

We've run into a case where a customer has an STM TPM 1.2 chip
(version 1.2.8.28), that is getting into an inconsistent state and
they end up getting tpm transmit errors.  In really old tpm code this
wasn't seen because the code that grabbed the duration values from the
chip could fail silently, and would proceed to just use default values
and move forward. More recent code though successfully gets the
duration values from the chip, and using those values this particular
chip version gets into the state seen by the customer.

The idea with this patchset is to provide a facility like the
update_timeouts operation to allow the override of chip supplied
values.

v3: Rework update_durations to make use of new version structs
    and pull tpm1_getcap calls out of loop.
v2: Update Alexey's v1 submission with suggestions made by Jarkko