Received: by 2002:a25:c593:0:0:0:0:0 with SMTP id v141csp671879ybe; Mon, 2 Sep 2019 07:29:35 -0700 (PDT) X-Google-Smtp-Source: APXvYqxG6J/MdXH8s8ymurOhiAIU03bQrDUCDqZAebndaDiMxYGS5IG2BprZBP4+CWUTabEs597I X-Received: by 2002:a63:6407:: with SMTP id y7mr25314821pgb.188.1567434575259; Mon, 02 Sep 2019 07:29:35 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1567434575; cv=none; d=google.com; s=arc-20160816; b=IMm4t66tivlYYPg+eVugwy978woXP4CLP2S1FiaD+bv0KYgyxkVrpn0Wn4Ep62pWV3 NkwFl5AjayYpjR7Mjok9l0DSrSxX3rW+2xuB2AAY7e8VMQW0W3//M8L7T1d4F9J/IDsq BYkBdpDa12Mk/+dqxo46dPq860zimaxkRE/9GzH3QJERsxQNeSfKS9qkaCCx1FkwBA+h cs26C/TyIic/nt6s+p+NtjbcjdqxOhmtCpgp2J+/dq6/uxrx8072QONoNiDA98uVpLEL f4txX7zqapWmct67BlD1Do7yfOirA9CCGbKQSGQFHM3lbOs//9JKr3giDU0+GHj36Vah +1Dg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from; bh=wGvQOdXmvHp5HJzAySiZre6Xn0qwbFOVschnAF3jCMY=; b=JiLSw8f/wkgl9jI0r1ucb6hmUGRgk+0L0dckAqlb4gftuzqpMEBFyxwO2YNhyZT16l EN7itYCAWa+2cdwCu/CdyfbDpv9FJ4un0yqkkEEhhkjOiJScV7u+wdsDuNTtkApnSqQ9 i0Epw7BAMBch0nfLvXSu251jwL14IGDh3vdRQB4eRWsJnmm1qs5Mfa7PkGjgC2wfk1PW zNGoIAEoy136a1HR/L4d3q6mooABua/uipwFich2cxkv4ayKEJoskpBwn2E5hHTJkit4 lvvHpbBmS01Ohy0oK3UswHImMOh+mQ5qJtUzDmKJo2JH6S8okazeYXPY84ZKlo1fmB/W b/jA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id f14si11916217plr.388.2019.09.02.07.29.19; Mon, 02 Sep 2019 07:29:35 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731586AbfIBO1t (ORCPT + 99 others); Mon, 2 Sep 2019 10:27:49 -0400 Received: from mx1.redhat.com ([209.132.183.28]:38530 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1731482AbfIBO1t (ORCPT ); Mon, 2 Sep 2019 10:27:49 -0400 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id D111985546; Mon, 2 Sep 2019 14:27:48 +0000 (UTC) Received: from cantor.redhat.com (ovpn-116-156.phx2.redhat.com [10.3.116.156]) by smtp.corp.redhat.com (Postfix) with ESMTP id 51B0760C05; Mon, 2 Sep 2019 14:27:48 +0000 (UTC) From: Jerry Snitselaar To: linux-integrity@vger.kernel.org Cc: linux-kernel@vger.kernel.org, Alexey Klimov , Jarkko Sakkinen , Peter Huewe , Jason Gunthorpe Subject: [PATCH v4 0/4] tpm: add update_durations class op to allow override of chip supplied values Date: Mon, 2 Sep 2019 07:27:32 -0700 Message-Id: <20190902142735.6280-1-jsnitsel@redhat.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.28]); Mon, 02 Sep 2019 14:27:48 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. changes from v3: * Assign value to version when tpm1_getcap is successful for TPM 1.1 device not when it fails. changes from v2: * Added patch 1/3 * Rework tpm_tis_update_durations to make use of new version structs and pull tpm1_getcap calls out of loop. changes from v1: * Remove unneeded newline * Formatting cleanups * Change tpm_tis_update_durations to be a void function, and use chip->duration_adjusted to track whether adjustment was made. Jarkko Sakkinen (1): tpm: Remove duplicate code from caps_show() in tpm-sysfs.c Jerry Snitselaar (2): tpm: provide a way to override the chip returned durations tpm_tis: override durations for STM tpm with firmware 1.2.8.28