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] [thread-next>] [day] [month] [year] [list]
Date:   Sat, 6 Apr 2019 11:30:47 -0400
From:   Sasha Levin <>
To:     Jarkko Sakkinen <>
Subject: Re: [PATCH 2/2] ftpm: firmware TPM running in TEE

On Wed, Apr 03, 2019 at 09:27:28PM +0300, Jarkko Sakkinen wrote:
>On Wed, Apr 03, 2019 at 09:18:27PM +0300, Jarkko Sakkinen wrote:
>> On Tue, Apr 02, 2019 at 03:33:16PM -0400, Sasha Levin wrote:
>> > This patch adds support for a software-only implementation of a TPM
>> > running in TEE.
>> >
>> > There is extensive documentation of the design here:
>> > .
>> >
>> > As well as reference code for the firmware available here:
>> >
>> >
>> > Signed-off-by: Thirupathaiah Annapureddy <>
>> > Signed-off-by: Sasha Levin <>
>> What is the context anyway? I mean tpm_crb already supports fTPM running
>> in TZ.
>Might take 2-3 weeks before I have time to go through ftpm1.pdf with
>full concentration. I did search through the PDF for CRB and found
>zero hits.

The fTPM as described in that paper and implemented in practice does not
use the CRB interface, thus we can't use tpm_crb to interface with the
firmware TPM.

>The commit message should absolutely better explain what is going on
>and preferably there should be some more broad documentation in

The code itself is just a small shim between the firmware TPM and the
kernel's TPM interface. There's really not much else to expand on in the
commit log.

I'll add some background to Documentation/security/tpm.

>Now this is just a random code dump and nothing else.

It pretty much is, but that's because this is just a "stupid" shim,
there heavy lifting is done outside of the kernel.

>Also, I have zero idea how to test this. Any recommendations on ARM
>board that can be easily used to test custom TZ applications would be

We are testing this on a Broadcom's Stingray SST100 board, and if you
have one we can help out with setting up a test environment. Otherwise,
we haven't really tried it on other boards.


Powered by blists - more mailing lists