Received: by 10.223.164.202 with SMTP id h10csp824069wrb; Thu, 23 Nov 2017 06:49:59 -0800 (PST) X-Google-Smtp-Source: AGs4zMY6fq680CMNT6IgENAwygS3bDPllvZFjdGU38d5qeiSv0kJxbRZPvevxynGyWii7dfr79AZ X-Received: by 10.101.97.204 with SMTP id j12mr10754037pgv.75.1511448599803; Thu, 23 Nov 2017 06:49:59 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1511448599; cv=none; d=google.com; s=arc-20160816; b=XGYv+X+1wu8TqwIqjRpQOQpf5fQsP+T855xk/KKLlIuZDlv2bAfCIif246kGRW1DcM ggSQEbXSyhlqKDCTJqASJN19D6Sd2Jnry4Rmjv6weTqqjMClxvN7ww1nxiJVTjaB5FOw 2EW1/9Q4gr2SLQfKnSZumEkz/QNlBP22wkdOnX0+PfIo0fQJIpe8wfZrniAUf+zBIn9E bO7Bts+k9Gn+oNbrzKqUt8oBcjpk6Xx44k9cIbwbAa74gB9wQtfnYCYiIrwYzrhbiFfj Lxlf4uXvoX5lMIEhWnQR6S/X3qDifsrC7zsfyt0mrndJYuCA548CF4MJrS3NcBHCeNoS WsRw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:message-id:user-agent:in-reply-to :content-disposition:mime-version:references:subject:cc:to:from:date :arc-authentication-results; bh=jZdZlZL7vsPMt7hpcJqVZfMhBtID5lTrXawFnDjaIik=; b=feqhBPuYe9UaPcXRJMst1rq5u85kP8HQuKhBglii9WZq7wddvnfHcKNZW7gg54Yy8g Q9cg565pQZXIL2/kJkExAUMzKypR0qhFhQ3oWUYSIphNpfNsvpao+kP+qPlH19EseuU3 gnAkeT3Q81Y4S5zVF39I5AV6kVxqVLtCoHpDW/f2zZ3S4qD/lPgL4kBvoy7Zbh9+CWBu MtUMSNRFa+WNoZikVN1KdlmdIn5qbiHeY6BlJWolSYiii2QK6BibQdaQUibg2azFQeKm MALaTBXrLbIkVUsD5Rv6Req10v9tCAm+EHc5bjjghOqerX3VsrsvdKuxOzwLuPwqsh92 O7fA== 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=ibm.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id v11si16259955pgo.483.2017.11.23.06.49.48; Thu, 23 Nov 2017 06:49:59 -0800 (PST) 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=ibm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753135AbdKWOss (ORCPT + 76 others); Thu, 23 Nov 2017 09:48:48 -0500 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:33900 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753126AbdKWOsq (ORCPT ); Thu, 23 Nov 2017 09:48:46 -0500 Received: from pps.filterd (m0098399.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id vANEmafk137411 for ; Thu, 23 Nov 2017 09:48:46 -0500 Received: from e37.co.us.ibm.com (e37.co.us.ibm.com [32.97.110.158]) by mx0a-001b2d01.pphosted.com with ESMTP id 2eduwc0jaq-1 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT) for ; Thu, 23 Nov 2017 09:48:45 -0500 Received: from localhost by e37.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 23 Nov 2017 07:48:44 -0700 Received: from b03cxnp08028.gho.boulder.ibm.com (9.17.130.20) by e37.co.us.ibm.com (192.168.1.137) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Thu, 23 Nov 2017 07:48:41 -0700 Received: from b03ledav004.gho.boulder.ibm.com (b03ledav004.gho.boulder.ibm.com [9.17.130.235]) by b03cxnp08028.gho.boulder.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id vANEmfSN066040; Thu, 23 Nov 2017 07:48:41 -0700 Received: from b03ledav004.gho.boulder.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 1B9A178041; Thu, 23 Nov 2017 07:48:41 -0700 (MST) Received: from swastik (unknown [9.77.192.206]) by b03ledav004.gho.boulder.ibm.com (Postfix) with ESMTPS id B4C3C78038; Thu, 23 Nov 2017 07:48:37 -0700 (MST) Date: Thu, 23 Nov 2017 20:17:42 +0530 From: Nayna Jain To: Alexander.Steffen@infineon.com Cc: linux-integrity@vger.kernel.org, zohar@linux.vnet.ibm.com, linux-security-module@vger.kernel.org, linux-kernel@vger.kernel.org, peterhuewe@gmx.de, jarkko.sakkinen@linux.intel.com, tpmdd@selhorst.net, patrickc@us.ibm.com Subject: Re: [PATCH v4 2/4] tpm: ignore burstcount to improve tpm_tis send() performance References: <20171017203232.2262-1-nayna@linux.vnet.ibm.com> <20171017203232.2262-3-nayna@linux.vnet.ibm.com> <5ef60315f2254b3b8bcc217a572280e5@infineon.com> <3ff12c6536de4379aa61cb09ebc9d105@infineon.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3ff12c6536de4379aa61cb09ebc9d105@infineon.com> User-Agent: Mutt/1.9.1 (2017-09-22) X-TM-AS-GCONF: 00 x-cbid: 17112314-0024-0000-0000-0000178B8CAC X-IBM-SpamModules-Scores: X-IBM-SpamModules-Versions: BY=3.00008107; HX=3.00000241; KW=3.00000007; PH=3.00000004; SC=3.00000241; SDB=6.00950065; UDB=6.00479789; IPR=6.00730175; BA=6.00005706; NDR=6.00000001; ZLA=6.00000005; ZF=6.00000009; ZB=6.00000000; ZP=6.00000000; ZH=6.00000000; ZU=6.00000002; MB=3.00018148; XFM=3.00000015; UTC=2017-11-23 14:48:43 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 17112314-0025-0000-0000-00004DA0E445 Message-Id: <20171123144742.GC8862@swastik> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-11-23_05:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=1 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1709140000 definitions=main-1711230201 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Nov 22, 2017 at 06:52:03AM +0000, Alexander.Steffen@infineon.com wrote: > > > > > This seems to fail reliably with my SPI TPM 2.0. I get EIO when trying to > > > > send large amounts of data, e.g. with TPM2_Hash, and subsequent tests > > > > seem to take an unusual amount of time. More analysis probably has to > > > wait > > > > until November, since I am going to be in Prague next week. > > > > > > > > Thanks Alex for testing these.. Did you get the chance to do any further > > > > analysis ? > > > > > > I am working on that now. Ken's suggestion seems reasonable, so I am > > going > > > to test whether correctly waiting for the flags to change fixes the problem. > > If > > > it does, I'll send the patches. > > > > Sorry for the delay, I had to take care of some device tree changes in v4.14 > > that broke my ARM test machines. > > > > I've implemented some patches that fix the issue that Ken pointed out and > > rebased your patch 2/4 ("ignore burstcount") on top. While doing this I > > noticed that your original patch does not, as the commit message says, write > > all the bytes at once, but still unnecessarily splits all commands into at least > > two transfers (as did the original code). I've fixed this as well in my patches, > > so that all bytes are indeed sent in a single call, without special handling for > > the last byte. This should speed up things further, especially for small > > commands and drivers like tpm_tis_spi, where writing a single byte > > translates into additional SPI transfers. Thanks Alex, for digging into. Yeah, you are right, the first version of this patch sent all the bytes together, but after hearing ddwg inputs, i.e. "The last byte was introduced for error checking purposes (history).", I reverted back to original to be safe. It seems that the last byte was sent from the beginning (27084ef [PATCH] tpm: driver for next generation TPM chips,), does anyone remember the reason ? > > > > Unfortunately, even with those changes the problem persists. But I've got > > more detailed logs now and will try to understand and hopefully fix the issue. > > I'll follow up with more details and/or patches once I know more. > > Okay, so the problem seems to be that at some point the TPM starts inserting wait states for the FIFO access. The driver tries to handle this, but fails since even the 50 retries that are currently used do not seem to be enough. Adding small (millisecond) delays between the attempts did not help so far. > > Is there any limit in the specification for how many wait states the TPM may generate or for how long it may do so? I could not find anything, but we need to use something there to prevent a faulty TPM from blocking the kernel forever. > I have been thinking on this, so was wondering: 1. As you said the problem started while sending large amounts of data for TPM2_Hash, how large is "large" ? I mean did it work for some specific large values before failing. 2. Are these wait states limited to SPI, or does it happen on LPC as well? Thanks & Regards, - Nayna > Alexander > From 1584748116147496887@xxx Wed Nov 22 06:52:56 +0000 2017 X-GM-THRID: 1581600980137441547 X-Gmail-Labels: Inbox,Category Forums,HistoricalUnread