From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on archive.lwn.net X-Spam-Level: X-Spam-Status: No, score=-6.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, RCVD_IN_DNSWL_HI,SPF_HELO_NONE,SPF_NONE autolearn=ham autolearn_force=no version=3.4.2 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by archive.lwn.net (Postfix) with ESMTP id 08F787D90F for ; Thu, 4 Jul 2019 18:11:28 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727090AbfGDSL1 (ORCPT ); Thu, 4 Jul 2019 14:11:27 -0400 Received: from mail-wr1-f68.google.com ([209.85.221.68]:36582 "EHLO mail-wr1-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727026AbfGDSL1 (ORCPT ); Thu, 4 Jul 2019 14:11:27 -0400 Received: by mail-wr1-f68.google.com with SMTP id n4so7501490wrs.3 for ; Thu, 04 Jul 2019 11:11:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=EeY1//zgHjHvZL8PlJS76RO/TPLoiFY9/zkEu270Qfs=; b=SgKiCrhYnxaQpOWryEwRE0jUNEKFhFz3Iw6QyUsme9ZyaVqDNoXUooFMnA9vLDiVP7 nDCBoZ9A80UD5z1G3VQD8CFzjxv1gj4kZfqNLxR1Zggc2VAX4N3/+gOBFNCAY2gxuw+7 H2pmvBR0LaFZT07eB3T7R1Y+sXr6XU3udnIPQ9T0D+ULJpDhKybLGnxrq4OBUbr8YTq6 iaoVk1x+JEIbZ5//8L00zQqNoEWsUB56O+t81vS12tlef8yb3zrkg5NHgLA8aZQXsTfU cSFGAcip1OWVtzXCumPbhhUl7zPMoDq0Vt5/rfzG2HoM7Xc9+VLgoV2PBisnbK/CIbsP IlUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=EeY1//zgHjHvZL8PlJS76RO/TPLoiFY9/zkEu270Qfs=; b=D1fl7PZfSbtDQUpp8dNHEgsyj7gMMtRtijmxVY192K80mV7cZbsvqKKz7kikmX7y6q 4Kc9zH1A7nUfLfMySGSZ3d1vBGS6Ln/6jWRO4n9Vl7X/J+UHIxiomW2hqiVZTfSovrAM xuVmXYvLPsO3Zm7wlLBQbKZ2mY/rXDnHMc+Zo01jmiGaaVajYYRQHrx7ytyNP8InwELu CaWAfjEs1PMCYDnbER498ctj2D5q1Bz8aemZlF5GtYyC94tT5nKIGT3rMAVTBRfFDA42 J6lOG4CZwDB9dkiiqmwelh1ASWiTnMdcPL7U7TvpjjBFMQHFgHkkxorUseMCpf7CQGPq iKxQ== X-Gm-Message-State: APjAAAVcqC7TYRmQOPwtOUVtqGYwFWrZjkMz0RUvpZvksslwqbAu9qdE hA6dviGYPgjqXxI5YnfNoKzU9Q== X-Google-Smtp-Source: APXvYqyG/pol3jM2+TZsOqHSuN2Z8zVhvdIGUGLFjgj1lkzu8Hii2SD1es3NYfFmFBlXgWjxuCr5Vg== X-Received: by 2002:adf:aacf:: with SMTP id i15mr24167399wrc.124.1562263884453; Thu, 04 Jul 2019 11:11:24 -0700 (PDT) Received: from apalos (athedsl-428434.home.otenet.gr. [79.131.225.144]) by smtp.gmail.com with ESMTPSA id o4sm6313945wmh.35.2019.07.04.11.11.22 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 04 Jul 2019 11:11:23 -0700 (PDT) Date: Thu, 4 Jul 2019 21:11:20 +0300 From: Ilias Apalodimas To: Thirupathaiah Annapureddy Cc: Jarkko Sakkinen , Sasha Levin , "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 , "Bryan Kelly (CSI)" , "tee-dev@lists.linaro.org" , "sumit.garg@linaro.org" , "rdunlap@infradead.org" , Joakim Bech Subject: Re: [PATCH v7 1/2] fTPM: firmware TPM running in TEE Message-ID: <20190704181120.GA21445@apalos> References: <673dd30d03e8ed9825bb46ef21b2efef015f6f2a.camel@linux.intel.com> <20190626235653.GL7898@sasha-vm> <20190627133004.GA3757@apalos> <0893dc429d4c3f3b52d423f9e61c08a5012a7519.camel@linux.intel.com> <20190702142109.GA32069@apalos> <20190703065813.GA12724@apalos> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-doc-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-doc@vger.kernel.org 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. > 1. 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. > > 2. 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. > 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. Thanks /Ilias