-----Original Message----- From: Ilias Apalodimas ilias.apalodimas@linaro.org Sent: Thursday, July 4, 2019 11:11 AM To: Thirupathaiah Annapureddy thiruan@microsoft.com Cc: Jarkko Sakkinen jarkko.sakkinen@linux.intel.com; Sasha Levin sashal@kernel.org; peterhuewe@gmx.de; jgg@ziepe.ca; corbet@lwn.net; linux- kernel@vger.kernel.org; linux-doc@vger.kernel.org; linux- integrity@vger.kernel.org; Microsoft Linux Kernel List <linux- kernel@microsoft.com>; Bryan Kelly (CSI) bryankel@microsoft.com; tee- dev@lists.linaro.org; sumit.garg@linaro.org; rdunlap@infradead.org; Joakim Bech joakim.bech@linaro.org Subject: Re: [PATCH v7 1/2] fTPM: firmware TPM running in TEE
Hi Thirupathaiah, [...]
I managed to do some quick testing in QEMU. Everything works fine when i build this as a module (using IBM's TPM
2.0
TSS)
- As module
# insmod /lib/modules/5.2.0-
rc1/kernel/drivers/char/tpm/tpm_ftpm_tee.ko
# getrandom -by 8 randomBytes length 8 23 b9 3d c3 90 13 d9 6b
- Built-in
# dmesg | grep optee ftpm-tee firmware:optee: ftpm_tee_probe:tee_client_open_session
failed,
err=ffff0008
This (0xffff0008) translates to TEE_ERROR_ITEM_NOT_FOUND.
Where is fTPM TA located in the your test setup? Is it stitched into TEE binary as an EARLY_TA or Is it expected to be loaded during run-time with the help of user mode
OP-
TEE supplicant?
My guess is that you are trying to load fTPM TA through user mode OP-
TEE
supplicant.
Can you confirm?
I tried both
Ok apparently there was a failure with my built-in binary which i didn't notice. I did a full rebuilt and checked the elf this time :)
Built as an earlyTA my error now is: ftpm-tee firmware:optee: ftpm_tee_probe:tee_client_open_session failed, err=ffff3024 (translates to TEE_ERROR_TARGET_DEAD) Since you tested it on real hardware i guess you tried both module/built-in. Which TEE version are you using?
I am glad that the first issue (TEE_ERROR_ITEM_NOT_FOUND) is resolved after
stitching
fTPM TA as an EARLY_TA.
Regarding TEE_ERROR_TARGET_DEAD error, may I know which HW platform you are
using to test?
QEMU, on armv7
What is the preboot environment (UEFI or U-boot)? Where is the secure storage in that HW platform? I could think of two classes of secure storage.
- UFS/eMMC RPMB : If Supplicant in U-boot/UEFI initializes the
fTPM TA NV Storage, there should be no issue. If fTPM TA NV storage is not initialized in pre-boot environment and you are
using
built-in fTPM Linux driver, you can run into this issue as TA will try to
initialize
NV store and fail.
- other storage devices like QSPI accessible to only secure mode after
EBS/ReadyToBoot mile posts during boot. In this case, there should be no
issue at all
as there is no dependency on non-secure side services provided by supplicant.
Please check the previous mail from Sumit. It explains exaclty what's going on. The tl;dr version is that the storage is up only when the supplicant is running.
I definitely know that OP-TEE can access storage only when the "user mode" supplicant is running :). But fTPM NV storage should have been initialized in in the preboot environment (UEFI/U-boot).
It would also be helpful to understand the overall use case/scenario (Measured boot?)you are trying to exercise with the fTPM.
I also want to emphasize that this discussion is turning into more of how fTPM gets integrated/enabled in a new HW platform. fTPM is hosted in github and you definitely bring any issues/feature requests there.
If you let me know the HW platform details, I am happy to work with you to
enable/integrate
fTPM TA on that HW platform.
Thanks, The hardware i am waiting for for has an eMMC RPMB. In theory the U-Boot supplicant support will be there so i'll be able to test it.
Can you give me the details of HW so that I can order one for myself? Is it one of the 96boards? The reason for the ask is that we have not upstreamd u-boot fTPM stack yet, although we have future plans for it.
--Thiru