From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id D94F5C7EE2F for ; Tue, 13 Jun 2023 00:49:22 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232574AbjFMAtV (ORCPT ); Mon, 12 Jun 2023 20:49:21 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44196 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229480AbjFMAtT (ORCPT ); Mon, 12 Jun 2023 20:49:19 -0400 Received: from linux.microsoft.com (linux.microsoft.com [13.77.154.182]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 4464210D3; Mon, 12 Jun 2023 17:49:18 -0700 (PDT) Received: by linux.microsoft.com (Postfix, from userid 1152) id ACDC420FE86C; Mon, 12 Jun 2023 17:49:17 -0700 (PDT) DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com ACDC420FE86C DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com; s=default; t=1686617357; bh=Tp1WzQdcx12W1fzBArAndkSd8SuQkzZ/5ksg+tQwJqs=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=Cz69bezj1h7WpyniLbBF79JtEUf+PZyKWL//KV4CS0zag0E+zewbtPPKGhuM5DCPR I+T8kVYutZi3ZltH+cHOdLHJ0D4KYmjQlRfeWhIbRcXSaN8jeQM86TZc/KySzKPMGs zhv8/1LsPyC+ovVB6Fd1J8TdQGwTmrqCghYEDXKs= Received: from localhost (localhost [127.0.0.1]) by linux.microsoft.com (Postfix) with ESMTP id A98CB307032D; Mon, 12 Jun 2023 17:49:17 -0700 (PDT) Date: Mon, 12 Jun 2023 17:49:17 -0700 (PDT) From: Shyam Saini To: alex.bennee@linaro.org cc: Sumit Garg , "Zhu, Bing" , "alex.bennee@linaro.org" , "code@tyhicks.com" , "Matti.Moell@opensynergy.com" , "arnd@linaro.org" , "hmo@opensynergy.com" , "joakim.bech@linaro.org" , "linux-kernel@vger.kernel.org" , "linux-mmc@vger.kernel.org" , "linux-scsi@vger.kernel.org" , "maxim.uvarov@linaro.org" , "ruchika.gupta@linaro.org" , "Winkler, Tomas" , "ulf.hansson@linaro.org" , "Huang, Yang" , "jens.wiklander@linaro.org" , "op-tee@lists.trustedfirmware.org" , ilias.apalodimas@linaro.org Subject: Re: [PATCH v2 0/4] rpmb subsystem, uapi and virtio-rpmb driver In-Reply-To: Message-ID: References: <20220405093759.1126835-1-alex.bennee@linaro.org> <20230531191007.13460-1-shyamsaini@linux.microsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Precedence: bulk List-ID: X-Mailing-List: linux-mmc@vger.kernel.org Thank you everyone for your valueable feedback. Alex, are you planning submit this patch series ? Please let me know. > On Thu, 1 Jun 2023 at 08:49, Sumit Garg wrote: >> >> On Thu, 1 Jun 2023 at 11:02, Ilias Apalodimas >> wrote: >>> >>> Hi Bing >>> >>> On Thu, 1 Jun 2023 at 04:03, Zhu, Bing wrote: >>>> >>>> As an alternative, Is it possible to change ftpm design not to depend on RPMB access at the earlier/boot stage? Because to my understanding, typically PCRs don't require persistent/NV storage (for example, before RPMB or tee-supplicant is ready, use TEE memory instead as temporary storage) >>> >>> I am not entirely sure this will solve our problem here. You are >>> right that we shouldn't depend on the supplicant to extend PCRs. But >>> what happens if an object is sealed against certain PCR values? We >>> are back to the same problem >> >> +1 >> >> Temporary storage may be a stop gap solution for some use-cases but >> having a fast path access to RPMB via kernel should be our final goal. >> I would suggest we start small with the MMC subsystem to expose RPMB >> access APIs for OP-TEE driver rather than a complete RPMB subsystem. > > I discussed with the OP-TEE maintainers about adding parts of the > supplicant in the kernel. The supplicant 'just' sends an ioctl to > store/read stuff anyway. So it would make sense to have a closer and > see if that looks reasonable. > Thanks > > /Ilias > >> >> -Sumit >> >>> >>> Thanks >>> /Ilias >>>> >>>> Bing >>>> >>>> IPAS Security Brown Belt (https://www.credly.com/badges/69ea809f-3a96-4bc7-bb2f-442c1b17af26) >>>> System Software Engineering >>>> Software and Advanced Technology Group >>>> Zizhu Science Park, Shanghai, China >>>> >>>> -----Original Message----- >>>> From: Shyam Saini >>>> Sent: Thursday, June 1, 2023 3:10 AM >>>> To: alex.bennee@linaro.org >>>> Cc: code@tyhicks.com; Matti.Moell@opensynergy.com; arnd@linaro.org; Zhu, Bing ; hmo@opensynergy.com; ilias.apalodimas@linaro.org; joakim.bech@linaro.org; linux-kernel@vger.kernel.org; linux-mmc@vger.kernel.org; linux-scsi@vger.kernel.org; maxim.uvarov@linaro.org; ruchika.gupta@linaro.org; Winkler, Tomas ; ulf.hansson@linaro.org; Huang, Yang ; sumit.garg@linaro.org; jens.wiklander@linaro.org; op-tee@lists.trustedfirmware.org >>>> Subject: [PATCH v2 0/4] rpmb subsystem, uapi and virtio-rpmb driver >>>> >>>> Hi Alex, >>>> >>>> [ Resending, Sorry for the noise ] >>>> >>>> Are you still working on it or planning to resubmit it ? >>>> >>>> [1] The current optee tee kernel driver implementation doesn't work when IMA is used with optee implemented ftpm. >>>> >>>> The ftpm has dependency on tee-supplicant which comes once the user space is up and running and IMA attestation happens at boot time and it requires to extend ftpm PCRs. >>>> >>>> But IMA can't use PCRs if ftpm use secure emmc RPMB partition. As optee can only access RPMB via tee-supplicant(user space). So, there should be a fast path to allow optee os to access the RPMB parititon without waiting for user-space tee supplicant. >>>> >>>> To achieve this fast path linux optee driver and mmc driver needs some work and finally it will need RPMB driver which you posted. >>>> >>>> Please let me know what's your plan on this. >>>> >>>> [1] https://optee.readthedocs.io/en/latest/architecture/secure_storage.html >>>> >>>> Best Regards, >>>> Shyam > From mboxrd@z Thu Jan 1 00:00:00 1970 From: Shyam Saini To: op-tee@lists.trustedfirmware.org Subject: Re: [PATCH v2 0/4] rpmb subsystem, uapi and virtio-rpmb driver Date: Tue, 13 Jun 2023 00:49:19 +0000 Message-ID: In-Reply-To: < > MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3919478477566097733==" List-Id: --===============3919478477566097733== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Thank you everyone for your valueable feedback. Alex, are you planning submit this patch series ? Please let me know. > On Thu, 1 Jun 2023 at 08:49, Sumit Garg wrote: >> >> On Thu, 1 Jun 2023 at 11:02, Ilias Apalodimas >> wrote: >>> >>> Hi Bing >>> >>> On Thu, 1 Jun 2023 at 04:03, Zhu, Bing wrote: >>>> >>>> As an alternative, Is it possible to change ftpm design not to depend on= RPMB access at the earlier/boot stage? Because to my understanding, typicall= y PCRs don't require persistent/NV storage (for example, before RPMB or tee-s= upplicant is ready, use TEE memory instead as temporary storage) >>> >>> I am not entirely sure this will solve our problem here. You are >>> right that we shouldn't depend on the supplicant to extend PCRs. But >>> what happens if an object is sealed against certain PCR values? We >>> are back to the same problem >> >> +1 >> >> Temporary storage may be a stop gap solution for some use-cases but >> having a fast path access to RPMB via kernel should be our final goal. >> I would suggest we start small with the MMC subsystem to expose RPMB >> access APIs for OP-TEE driver rather than a complete RPMB subsystem. > > I discussed with the OP-TEE maintainers about adding parts of the > supplicant in the kernel. The supplicant 'just' sends an ioctl to > store/read stuff anyway. So it would make sense to have a closer and > see if that looks reasonable. > Thanks > > /Ilias > >> >> -Sumit >> >>> >>> Thanks >>> /Ilias >>>> >>>> Bing >>>> >>>> IPAS Security Brown Belt (https://www.credly.com/badges/69ea809f-3a96-4b= c7-bb2f-442c1b17af26) >>>> System Software Engineering >>>> Software and Advanced Technology Group >>>> Zizhu Science Park, Shanghai, China >>>> >>>> -----Original Message----- >>>> From: Shyam Saini >>>> Sent: Thursday, June 1, 2023 3:10 AM >>>> To: alex.bennee(a)linaro.org >>>> Cc: code(a)tyhicks.com; Matti.Moell(a)opensynergy.com; arnd(a)linaro.org= ; Zhu, Bing ; hmo(a)opensynergy.com; ilias.apalodimas(a= )linaro.org; joakim.bech(a)linaro.org; linux-kernel(a)vger.kernel.org; linux-= mmc(a)vger.kernel.org; linux-scsi(a)vger.kernel.org; maxim.uvarov(a)linaro.or= g; ruchika.gupta(a)linaro.org; Winkler, Tomas ; ul= f.hansson(a)linaro.org; Huang, Yang ; sumit.garg(a)li= naro.org; jens.wiklander(a)linaro.org; op-tee(a)lists.trustedfirmware.org >>>> Subject: [PATCH v2 0/4] rpmb subsystem, uapi and virtio-rpmb driver >>>> >>>> Hi Alex, >>>> >>>> [ Resending, Sorry for the noise ] >>>> >>>> Are you still working on it or planning to resubmit it ? >>>> >>>> [1] The current optee tee kernel driver implementation doesn't work when= IMA is used with optee implemented ftpm. >>>> >>>> The ftpm has dependency on tee-supplicant which comes once the user spac= e is up and running and IMA attestation happens at boot time and it requires = to extend ftpm PCRs. >>>> >>>> But IMA can't use PCRs if ftpm use secure emmc RPMB partition. As optee = can only access RPMB via tee-supplicant(user space). So, there should be a fa= st path to allow optee os to access the RPMB parititon without waiting for us= er-space tee supplicant. >>>> >>>> To achieve this fast path linux optee driver and mmc driver needs some w= ork and finally it will need RPMB driver which you posted. >>>> >>>> Please let me know what's your plan on this. >>>> >>>> [1] https://optee.readthedocs.io/en/latest/architecture/secure_storage.h= tml >>>> >>>> Best Regards, >>>> Shyam > --===============3919478477566097733==--