Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752822AbdDHUZo (ORCPT ); Sat, 8 Apr 2017 16:25:44 -0400 Received: from quartz.orcorp.ca ([184.70.90.242]:42607 "EHLO quartz.orcorp.ca" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752240AbdDHUZh (ORCPT ); Sat, 8 Apr 2017 16:25:37 -0400 Date: Sat, 8 Apr 2017 14:25:09 -0600 From: Jason Gunthorpe To: "Denis 'GNUtoo' Carikli" Cc: Paul Menzel , "Maciej S. Szmigiero" , tpmdd-devel@lists.sourceforge.net, linux-kernel@vger.kernel.org Subject: Re: [tpmdd-devel] Regression between Linux 3.16 and 4.8/4.9 on Lenovo X60 with coreboot Message-ID: <20170408202509.GA26119@obsidianresearch.com> References: <20170406165557.GD7657@obsidianresearch.com> <20170408123651.76f18ba4@second-laptop.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170408123651.76f18ba4@second-laptop.localdomain> User-Agent: Mutt/1.5.24 (2015-08-30) X-Broken-Reverse-DNS: no host name found for IP address 10.0.0.156 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1683 Lines: 43 On Sat, Apr 08, 2017 at 12:40:25PM +0200, Denis 'GNUtoo' Carikli wrote: > I am working on it[1]. This commit has not been merged and is a work in > progress. It is however available in coreboot's gerrit. How did this work on any kernels if there was no PNP or ACPI entry? FWIW, I wonder if coreboot is missing the code for wait_startup in drivers/char/tpm/tpm_tis_core.c. If you don't do that step then the DID/VID might not read properly. > So far with it and a recent kernel and the patch mentioned above: > - The linux driver finds the TPM automatically and doesn't require > force=1 > - The driver however still require itpm=1 to fully work: without it the > tpm is found, but I wasn't able to read the PCRs. Unless it is an actual broken intel TPM you should never use itpm=1. Juding by the log messages, it certainly is not. Intel mode breaks the driver and removes certain error detection, eg it may erronously succeed. It is more likely that the failure to read PCRs reflects reality and itpm=1 just supresses that error detection. The TPM may need to be setup (eg cleared, EK generated, p/vflags setup etc, etc) before it will support PCRs. Usually the BIOS would do these steps when the TPM is first enabled, you probably need to do them in userspace instead. WARNING: Failure to provision the TPM properly before first use could leave it in 'factory test' mode, which basically means it doesn't work properly at all. > - I want to make it work without itpm=1 if possible. I'll test with > INTC0102 as it is in the driver in the is_itpm function, and it was > also suggested to me by someone on IRC. Don't do this unless it is actually that TPM. Jason