linux-kernel - Re: [PATCH v2 0/4] rpmb subsystem, uapi and virtio-rpmb driver

lists.openwall.net		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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 2 Jun 2023 11:25:46 +0300
From:   Ilias Apalodimas <ilias.apalodimas@...aro.org>
To:     Sumit Garg <sumit.garg@...aro.org>
Cc:     "Zhu, Bing" <bing.zhu@...el.com>,
        Shyam Saini <shyamsaini@...ux.microsoft.com>,
        "alex.bennee@...aro.org" <alex.bennee@...aro.org>,
        "code@...icks.com" <code@...icks.com>,
        "Matti.Moell@...nsynergy.com" <Matti.Moell@...nsynergy.com>,
        "arnd@...aro.org" <arnd@...aro.org>,
        "hmo@...nsynergy.com" <hmo@...nsynergy.com>,
        "joakim.bech@...aro.org" <joakim.bech@...aro.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-mmc@...r.kernel.org" <linux-mmc@...r.kernel.org>,
        "linux-scsi@...r.kernel.org" <linux-scsi@...r.kernel.org>,
        "maxim.uvarov@...aro.org" <maxim.uvarov@...aro.org>,
        "ruchika.gupta@...aro.org" <ruchika.gupta@...aro.org>,
        "Winkler, Tomas" <tomas.winkler@...el.com>,
        "ulf.hansson@...aro.org" <ulf.hansson@...aro.org>,
        "Huang, Yang" <yang.huang@...el.com>,
        "jens.wiklander@...aro.org" <jens.wiklander@...aro.org>,
        "op-tee@...ts.trustedfirmware.org" <op-tee@...ts.trustedfirmware.org>
Subject: Re: [PATCH v2 0/4] rpmb subsystem, uapi and virtio-rpmb driver

On Thu, 1 Jun 2023 at 08:49, Sumit Garg <sumit.garg@...aro.org> wrote:
>
> On Thu, 1 Jun 2023 at 11:02, Ilias Apalodimas
> <ilias.apalodimas@...aro.org> wrote:
> >
> > Hi Bing
> >
> > On Thu, 1 Jun 2023 at 04:03, Zhu, Bing <bing.zhu@...el.com> 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 <shyamsaini@...ux.microsoft.com>
> > > Sent: Thursday, June 1, 2023 3:10 AM
> > > To: alex.bennee@...aro.org
> > > Cc: code@...icks.com; Matti.Moell@...nsynergy.com; arnd@...aro.org; Zhu, Bing <bing.zhu@...el.com>; hmo@...nsynergy.com; ilias.apalodimas@...aro.org; joakim.bech@...aro.org; linux-kernel@...r.kernel.org; linux-mmc@...r.kernel.org; linux-scsi@...r.kernel.org; maxim.uvarov@...aro.org; ruchika.gupta@...aro.org; Winkler, Tomas <tomas.winkler@...el.com>; ulf.hansson@...aro.org; Huang, Yang <yang.huang@...el.com>; sumit.garg@...aro.org; jens.wiklander@...aro.org; op-tee@...ts.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