Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Message-ID: <7729a41ac22dab84a785bc7a6228af28b814a33a.camel@HansenPartnership.com>
Subject: Re: WARN_ONCE triggered: tpm_tis: Add a check for invalid status
From:   James Bottomley <James.Bottomley@HansenPartnership.com>
To:     Dirk Gouders <dirk@gouders.net>,
        Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Cc:     linux-integrity@vger.kernel.org, linux-kernel@vger.kernel.org
Date:   Wed, 14 Oct 2020 11:24:08 -0700
In-Reply-To: <ghsgagsnag.fsf@gouders.net>
References: <ghsgagsnag.fsf@gouders.net>
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.34.4 
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Precedence: bulk

On Wed, 2020-10-14 at 19:57 +0200, Dirk Gouders wrote:
> On my laptop the check introduced with 55707d531af62b (tpm_tis: Add a
> check for invalid status) triggered the warning (output below).
> 
> So, my laptop seems to be a candidate for testing.

I'm afraid this is a known problem on a wide range of TIS TPMs ... it's
fixed by the patch set I'm trying to get upstream:

https://lore.kernel.org/linux-integrity/20201001180925.13808-1-James.Bottomley@HansenPartnership.com/

But in the meantime, it's harmless.  The TIS code at the point in the
trace is trying to send a TPM2_GetCapability() command which fails
because the locality isn't listening, but the design of that command is
only to trigger an interrupt to probe the interrupt handling nothing
else depends on it succeeding.

James