Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751909AbdDNGh3 (ORCPT ); Fri, 14 Apr 2017 02:37:29 -0400 Received: from smtp.codeaurora.org ([198.145.29.96]:49766 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750997AbdDNGh0 (ORCPT ); Fri, 14 Apr 2017 02:37:26 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 smtp.codeaurora.org 1D2DF60D60 Authentication-Results: pdx-caf-mail.web.codeaurora.org; dmarc=none (p=none dis=none) header.from=codeaurora.org Authentication-Results: pdx-caf-mail.web.codeaurora.org; spf=none smtp.mailfrom=harba@codeaurora.org Subject: Re: ARM64 TPM start method patches To: anjiandi@codeaurora.org, Mark Rutland References: <20170411113652.GB32267@leverpostej> <9890ce2f139b4204d17c6a398681083f@codeaurora.org> Cc: Jarkko Sakkinen , linux-kernel@vger.kernel.org, Shanker Donthineni , ard.biesheuvel@linaro.org From: "Abdulhamid, Harb" Message-ID: Date: Fri, 14 Apr 2017 02:37:22 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <9890ce2f139b4204d17c6a398681083f@codeaurora.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 4628 Lines: 114 On 4/14/2017 12:58 AM, anjiandi@codeaurora.org wrote: > Adding Harb Abdulhamid for SMC details > > On 2017-04-11 06:36, Mark Rutland wrote: >> Hi, >> >> I just stumbled upon the following commits in next-20170411: >> >> cf8252ca7ca76fa4 ("ACPICA: Update TPM2 ACPI table") >> 08eff49d63ca2bf4 ("tpm/tpm_crb: Enable TPM CRB interface for ARM64") >> >> ... which leave me a little concerned, for two reasons. >> >> Firstly, the spec these are based on (TCG ACPI Specification Family >> “1.2” and “2.0” Version 1.2, Revision 8), is a draft, open for public >> review until April 28th 2017 [1], and still subject to change, as noted >> in the title page of the document [2]: >> >> This document is an intermediate draft for comment only and is >> subject to change without notice. Readers should not design products >> based on this document. >> >> ... so I hope the plan is not to merge these until the final spec is >> published. That was our expectation. >> >> Secondly, the spec is very vague as to the workings of the SMC call, If you read the TPM 2.0 Mobile Command Response Buffer Interface Specification, along side the TCG ACPI Specification, you will find that it is pretty clear how CRB works. https://trustedcomputinggroup.org/wp-content/uploads/Mobile-Command-Response-Buffer-Interface-v2-r12-Specification_FINAL2.pdf The "TPM start method" is nothing more than a signal to firmware. It has no parameters or return values outside of what's defined in the CRB control area (i.e. this protocol does not rely on GPRs at all). I provide answers to your questions below. and >> does not define: >> >> * That the SMC call follows the SMC Calling Convention [3] Note that we have discussed this at great length with some of your colleagues. We had originally proposed standardizing this SMC, but ARM elected not to reserve a Function ID (FID) for the TPM CRB start method in the SMCCC specification. Instead, ARM preferred that silicon vendors rely on a vendor specific FID for this start method. Since there are no rules in the SMCCC for the vendor specific FID space (outside of ensuring that reserved FIDs are not used), the SMCCC does not apply here. The ARM extension to the TCG ACPI specification enabled us to specify the FID that will be used to invoke the TPM start method. Any firmware that specifies anything outside of the vendor specific FID space in the TCG ACPI table would be in implicit violation of the SMCCC specification. At the same time, we do not want to do any FID range checking in the driver itself, because in the future we may eventually elect to define a standard FID for this start method, and we'd like the driver to be forward compatible with future firmware. >> * The parameters to the SMC call Once the TPM start method is invoked (via SMC), The OS writes the command and parameters to the Command Buffer. Note that the command buffer address is specified in the CRB control area. Also note that, unlike standard SMC calls you are probably accustomed to, the values in the GPRs are irrelevant and ignored. >> * The return value(s) of the SMC call Trustzone firmware will ERET back to software, where software will poll the CRB status for completion or error. When the command is complete, the OS will retrieve return data from the Response Buffer (the response buffer address is also specified in the CRB control area). >> >> ... which I believe should be clarified in the spec before we make >> assumptions regarding these in the Linux driver. Otherwise, this is >> liable to vary in practice. Anything that strays from the above behavior is in clear spec violation and a firmware bug. I don't see how any of these specifications (TCG CRB, TCG ACPI, and SMCCC) allow for any variance in implementation. I disagree that any further clarification is needed in the spec. Folks who study the TCG specifications will clearly understand these flows. Again, please take a look at the TPM Mobile Command Response Buffer Interface Specification, you will find the details there. >> >> Thanks, >> Mark. >> >> [1] https://trustedcomputinggroup.org/specifications-public-review/ >> [2] >> https://trustedcomputinggroup.org/wp-content/uploads/TCG_ACPIGeneralSpecification-Family-1.2-and-2.0-Ver1.2-Rev8_public-revie....pdf >> >> [3] >> http://infocenter.arm.com/help/topic/com.arm.doc.den0028b/ARM_DEN0028B_SMC_Calling_Convention.pdf >> Thanks, Harb -- Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.