linux-kernel - Re: ARM64 TPM start method patches

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <cb0ae75f-e79d-97bb-7807-92942ee9ee35@codeaurora.org>
Date:   Fri, 14 Apr 2017 02:37:22 -0400
From:   "Abdulhamid, Harb" <harba@...eaurora.org>
To:     anjiandi@...eaurora.org, Mark Rutland <mark.rutland@....com>
Cc:     Jarkko Sakkinen <jarkko.sakkinen@...ux.intel.com>,
        linux-kernel@...r.kernel.org,
        Shanker Donthineni <shankerd@...eaurora.org>,
        ard.biesheuvel@...aro.org
Subject: Re: ARM64 TPM start method patches

On 4/14/2017 12:58 AM, anjiandi@...eaurora.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.