Received: by 2002:a25:ad19:0:0:0:0:0 with SMTP id y25csp965623ybi; Wed, 3 Jul 2019 07:18:37 -0700 (PDT) X-Google-Smtp-Source: APXvYqyYtwxUO9vJQEaKNf8j4RI0V2vosdyLUJekEXvtCw5IHJcjr6ICFZVqNX+lVL73oNqt/K88 X-Received: by 2002:a63:130f:: with SMTP id i15mr32993872pgl.158.1562163517076; Wed, 03 Jul 2019 07:18:37 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1562163517; cv=none; d=google.com; s=arc-20160816; b=bpagRR82B5hY2RdrhJf/KPssZ94AKAZ7+FyG3M2xOQR07MJ9hEwJ2p6M5POihtAyDx hi/zRzLduGEYomi7P/tNMBpcEI5w1gSYRWptTCpgLwYlzOJxPxV9gNVMYszCUhkgI7+b iry0DaGq4HgTG76aay1/ll3TlWRaCjUPaYPJp3IVMlrqv8ieMaK3gM437ED/Utqyp3bR nVGu9lCGF41xcJ2GaFiL+2Ge/tDmYnig6gKjcDoPKYu58EUufWzRRfSxg1ivYd/u1Sol XwtJzXflisco+fv/nH83Rg3iG1fGd+KhrXfgRmnwOqdvQoVY2YSkGtqSyzqHs0yPg7pN yw7g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=8DKdbUgQ2jVt8K/6qfz1G9yQLM6zzf/4kO2TWk7/Q2I=; b=hnqZvUk/p1/De4l3cwWjqEVdF+wWCxhqsqKM7TgyCriJqjgAY6sZXczpqxdL/DMPdl AVNzhxCzCFz5TTWw132XPn3cammaY7WsAIbIEbFLN8qI7OyrwkR6EkkKTsMaG90kYEGp uaLbucUZKrJEfBXCqZvEOmiBlwmiGSYOsYKw3LumMPRI1186jY1/So5i1CmFh5PR1Z/x kjWPIUMKW+oRU902rmMHwGH8eet+UGVE8/Hobg6U6BcH+JZw1FPlI5C7L3nFKM4lNG5F dAB2XAGiQSjYmQJuAxLe5BfKtaDjSZM3H3/iOEUhp9WSU3CHlxrxrDnl83ZhnaIKR7R8 Vbdg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=yoGgAuhK; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id t191si2453446pgd.370.2019.07.03.07.18.21; Wed, 03 Jul 2019 07:18:37 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=yoGgAuhK; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727142AbfGCOQL (ORCPT + 99 others); Wed, 3 Jul 2019 10:16:11 -0400 Received: from mail-ed1-f66.google.com ([209.85.208.66]:43240 "EHLO mail-ed1-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727034AbfGCOQI (ORCPT ); Wed, 3 Jul 2019 10:16:08 -0400 Received: by mail-ed1-f66.google.com with SMTP id e3so2235557edr.10 for ; Wed, 03 Jul 2019 07:16:06 -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=8DKdbUgQ2jVt8K/6qfz1G9yQLM6zzf/4kO2TWk7/Q2I=; b=yoGgAuhKXkHJtjTmsoIY1ltoABbwgoH4O2/u8mUvBkgk65XAlbzp9wlFR/oFrSWTx9 ZCsCR3BVFGPGC6bYgfwm3xRJQ5BJMcfaMt7WN5uklWjMlkTNw18k2aMokV1fw+NDbmnp tYjbVLeqmMFJj+dPJUb4BFJdACG+A9sOY1/giqckYB9YZwlecSMLG9ZaoBW9VRV3WptH 4zV2LQYbdMjjIogOzL3LIcJH4bSgxg+CRaBqg/sOkxawmRHhg7pr7SoAaMtHHiVNmD5T pgSLhq7vmgRujivkOGWRy4NJnuByC0ZwmzVaBJz+7zpQPZEtpCsRqDOYywJi0ng+U00l 612A== 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=8DKdbUgQ2jVt8K/6qfz1G9yQLM6zzf/4kO2TWk7/Q2I=; b=RIh6heZihDuEC7l7fvLmUSlwtr9f0mWO104t+spXUUhjrebo35XQ+EJ5YVly4K1mSy /ZYHrVytAF2frp4OTuJ59d27EF+aa172GAXa+4NAUrrJRvJdEOtr7UKczIdvnc24kjvb B5NUgxZV+JHsSa9aY609JGNFbIpnQ46w8Hla+uvkv6L6mfRAc6cN4Axsum2ocdt/v+j2 22/B63rxS4bq9rgvQBbkBCYwt+AsWqFNGjQygkwJTPmamjx6bctKBSCr1/ZXBFuh57Jk l9VBodlKfGVBF1ORVYjR0CUfrxLXQRnj/N8pjhXbeyH6XjG301yqbbclwnpZeT2JClcQ HFkw== X-Gm-Message-State: APjAAAXvqZZHEJGfonjwEtOpkmZjYKcCpBnVuSLT7cZ+fgA4YPbmElFJ jc8aVaDZpO9X5erKjwrnE+Ej7A== X-Received: by 2002:a17:906:3956:: with SMTP id g22mr34311793eje.292.1562163366123; Wed, 03 Jul 2019 07:16:06 -0700 (PDT) Received: from debby (81-231-61-154-no276.tbcn.telia.com. [81.231.61.154]) by smtp.gmail.com with ESMTPSA id d4sm737274edb.4.2019.07.03.07.16.03 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 03 Jul 2019 07:16:04 -0700 (PDT) Date: Wed, 3 Jul 2019 16:16:02 +0200 From: Joakim Bech To: Sumit Garg Cc: Ilias Apalodimas , Thirupathaiah Annapureddy , 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" , "rdunlap@infradead.org" Subject: Re: [PATCH v7 1/2] fTPM: firmware TPM running in TEE Message-ID: <20190703141602.fky5x5buuqdjw7wx@debby> 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=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170113 (1.7.2) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jul 03, 2019 at 03:33:14PM +0530, Sumit Garg wrote: > On Wed, 3 Jul 2019 at 13:42, Ilias Apalodimas > wrote: > > > > Hi Thirupathaiah, > > > > (+Joakim) > > > > On Wed, 3 Jul 2019 at 09:58, Ilias Apalodimas > > wrote: > > > > > > Hi Thirupathaiah, > > > > > > > > First of all, Thanks a lot for trying to test the driver. > > > > > > > np > > > > > > [...] > > > > > 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? > > > > > > > U-boot and Linux driver stacks work seamlessly without dependency on supplicant. > > Is this true? > > It looks like this fTPM driver can't work as a built-in driver. The > reason seems to be secure storage access required by OP-TEE fTPM TA > that is provided via OP-TEE supplicant that's not available during > kernel boot. > > Snippet from ms-tpm-20-ref/Samples/ARM32-FirmwareTPM/optee_ta/fTPM/fTPM.c +145: > > // If we fail to open fTPM storage we cannot continue. > if (_plat__NVEnable(NULL) == 0) { > TEE_Panic(TEE_ERROR_BAD_STATE); > } > > So it seems like this module will work as a loadable module only after > OP-TEE supplicant is up. > This seems to be the same issues that I faced when trying to put together a setup for Linaro Connect discussions. When compiling the fTPM driver into the kernel (instead of a module) I saw mainly two issues. 1) fTPM driver seems to be probed before the TEE driver has been probed. I temporary solved that by doing a late_initcall. 2) With the late_initcall hack applied, the TEE side was called successfully (if the fTPM TA's is compiled as "early TAs", i.e., built into the TEE core iself), but as Sumit said, it got stock on secure storage operations, since tee-supplicant, the userspace process serving the TEE with storage access hasn't been started. The first issue can(?)/should(?) be solved by some deferred probing mechanism. Regarding the second issue, is there a must to access secure storage when Linux kernel is booting up? I suppose this is some kind of initialization of the "NV" (adding TPM measurements?), but I guess it should be possible to delay those calls to a later point, when tee-supplicant is up and running and the first call to the TEE is made. -- Regards, Joakim