This series introduces the tee based EFI Runtime Variable Service.

The eMMC device is typically owned by the non-secure world(linux in
this case). There is an existing solution utilizing eMMC RPMB partition
for EFI Variables, it is implemented by interacting with
OP-TEE, StandaloneMM(as EFI Variable Service Pseudo TA), eMMC driver
and tee-supplicant. The last piece is the tee-based variable access
driver to interact with OP-TEE and StandaloneMM.

Changelog:
v5 -> v6
- new patch #4 is added in this series, #1-#3 patches are unchanged.
  automatically update super block flag when the efivarops support
  SetVariable runtime service, so that user does not need to manually
  remount the efivarfs as RW.

v4 -> v5
- rebase to efi-next based on v6.4-rc1
- set generic_ops.query_variable_info, it works as expected as follows.
$ df -h /sys/firmware/efi/efivars/
Filesystem      Size  Used Avail Use% Mounted on
efivarfs         16K  1.3K   15K   8% /sys/firmware/efi/efivars

v3 -> v4:
- replace the reference from EDK2 to PI Specification
- remove EDK2 source code reference comments
- prepare nonblocking variant of set_variable, it just returns
  EFI_UNSUPPORTED
- remove redundant buffer size check
- argument name change in mm_communicate
- function interface changes in setup_mm_hdr to remove (void **) cast

v2 -> v3:
- add CONFIG_EFI dependency to TEE_STMM_EFI
- add missing return code check for tee_client_invoke_func()
- directly call efivars_register/unregister from tee_stmm_efi.c

rfc v1 -> v2:
- split patch into three patches, one for drivers/tee,
  one for include/linux/efi.h, and one for the driver/firmware/efi/stmm
- context/session management into probe() and remove() same as other tee
client driver
- StMM variable driver is moved from driver/tee/optee to driver/firmware/efi
- use "tee" prefix instead of "optee" in driver/firmware/efi/stmm/tee_stmm_efi.c,
  this file does not contain op-tee specific code, abstracted by tee layer and
  StMM variable driver will work on other tee implementation.
- PTA_STMM_CMD_COMMUNICATE -> PTA_STMM_CMD_COMMUNICATE
- implement query_variable_store() but currently not used
- no use of TEEC_SUCCESS, it is defined in driver/tee/optee/optee_private.h.
  Other tee client drivers use 0 instead of using TEEC_SUCCESS
- remove TEEC_ERROR_EXCESS_DATA status, it is referred just to output
error message

Masahisa Kojima (4):
  efi: expose efivar generic ops register function
  efi: Add EFI_ACCESS_DENIED status code
  efi: Add tee-based EFI variable driver
  efivarfs: automatically update super block flag

 drivers/firmware/efi/Kconfig                 |  15 +
 drivers/firmware/efi/Makefile                |   1 +
 drivers/firmware/efi/efi.c                   |  18 +
 drivers/firmware/efi/stmm/mm_communication.h | 236 +++++++
 drivers/firmware/efi/stmm/tee_stmm_efi.c     | 638 +++++++++++++++++++
 drivers/firmware/efi/vars.c                  |   8 +
 fs/efivarfs/super.c                          |  33 +
 include/linux/efi.h                          |  12 +
 8 files changed, 961 insertions(+)
 create mode 100644 drivers/firmware/efi/stmm/mm_communication.h
 create mode 100644 drivers/firmware/efi/stmm/tee_stmm_efi.c


base-commit: d0a1865cf7e2211d9227592ef4141f4632e33908
-- 
2.30.2

On 22.06.23 10:51, Masahisa Kojima wrote:
> This series introduces the tee based EFI Runtime Variable Service.
> 
> The eMMC device is typically owned by the non-secure world(linux in
> this case). There is an existing solution utilizing eMMC RPMB partition
> for EFI Variables, it is implemented by interacting with
> OP-TEE, StandaloneMM(as EFI Variable Service Pseudo TA), eMMC driver
> and tee-supplicant. The last piece is the tee-based variable access
> driver to interact with OP-TEE and StandaloneMM.
> 
> Changelog:
> v5 -> v6
> - new patch #4 is added in this series, #1-#3 patches are unchanged.
>   automatically update super block flag when the efivarops support
>   SetVariable runtime service, so that user does not need to manually
>   remount the efivarfs as RW.

But that is not yet resolving the architectural problem with that
userspace daemon dependency. What are the next steps for that now?

Thanks,
Jan

-- 
Siemens AG, Technology
Competence Center Embedded Linux

Hi Jan,

On Thu, 22 Jun 2023 at 17:56, Jan Kiszka <jan.kiszka@siemens.com> wrote:
>
> On 22.06.23 10:51, Masahisa Kojima wrote:
> > This series introduces the tee based EFI Runtime Variable Service.
> >
> > The eMMC device is typically owned by the non-secure world(linux in
> > this case). There is an existing solution utilizing eMMC RPMB partition
> > for EFI Variables, it is implemented by interacting with
> > OP-TEE, StandaloneMM(as EFI Variable Service Pseudo TA), eMMC driver
> > and tee-supplicant. The last piece is the tee-based variable access
> > driver to interact with OP-TEE and StandaloneMM.
> >
> > Changelog:
> > v5 -> v6
> > - new patch #4 is added in this series, #1-#3 patches are unchanged.
> >   automatically update super block flag when the efivarops support
> >   SetVariable runtime service, so that user does not need to manually
> >   remount the efivarfs as RW.
>
> But that is not yet resolving the architectural problem with that
> userspace daemon dependency. What are the next steps for that now?

We are trying to find some cycles to work on that, however, I don't
have a time estimate on that.  But the question is different here.
Since this addresses the problems distros have wrt to SetVariableRT
(even for a limited set of platforms) are we ok pulling this in?  I
can't think of a technical reason we shouldn't.  The supplicant
limitations are known and the firrmwareTPM has a similar set of
problems.

Thanks
/Ilias

>
> Thanks,
> Jan
>
> --
> Siemens AG, Technology
> Competence Center Embedded Linux
>

On 22.06.23 17:04, Ilias Apalodimas wrote:
> Hi Jan,
> 
> On Thu, 22 Jun 2023 at 17:56, Jan Kiszka <jan.kiszka@siemens.com> wrote:
>>
>> On 22.06.23 10:51, Masahisa Kojima wrote:
>>> This series introduces the tee based EFI Runtime Variable Service.
>>>
>>> The eMMC device is typically owned by the non-secure world(linux in
>>> this case). There is an existing solution utilizing eMMC RPMB partition
>>> for EFI Variables, it is implemented by interacting with
>>> OP-TEE, StandaloneMM(as EFI Variable Service Pseudo TA), eMMC driver
>>> and tee-supplicant. The last piece is the tee-based variable access
>>> driver to interact with OP-TEE and StandaloneMM.
>>>
>>> Changelog:
>>> v5 -> v6
>>> - new patch #4 is added in this series, #1-#3 patches are unchanged.
>>>   automatically update super block flag when the efivarops support
>>>   SetVariable runtime service, so that user does not need to manually
>>>   remount the efivarfs as RW.
>>
>> But that is not yet resolving the architectural problem with that
>> userspace daemon dependency. What are the next steps for that now?
> 
> We are trying to find some cycles to work on that, however, I don't
> have a time estimate on that.  But the question is different here.
> Since this addresses the problems distros have wrt to SetVariableRT
> (even for a limited set of platforms) are we ok pulling this in?  I
> can't think of a technical reason we shouldn't.  The supplicant
> limitations are known and the firrmwareTPM has a similar set of
> problems.

It will not change we have to do on the distro side because we have to
deal not only with the startup issue and StMM but also with fTPM and
with shutdown. Only an in-kernel supplicant for RPMB would resolve that
according to my understanding.

But the question is fair if we can evolve from this stage here to an
in-kernel approach without causing breakages or other headache to
distros adopting it (too early). That's why I asked for the roadmap.

Jan

-- 
Siemens AG, Technology
Competence Center Embedded Linux

On Thu, Jun 22, 2023 at 08:32:44PM +0200, Jan Kiszka wrote:
> On 22.06.23 17:04, Ilias Apalodimas wrote:
> > Hi Jan,
> >
> > On Thu, 22 Jun 2023 at 17:56, Jan Kiszka <jan.kiszka@siemens.com> wrote:
> >>
> >> On 22.06.23 10:51, Masahisa Kojima wrote:
> >>> This series introduces the tee based EFI Runtime Variable Service.
> >>>
> >>> The eMMC device is typically owned by the non-secure world(linux in
> >>> this case). There is an existing solution utilizing eMMC RPMB partition
> >>> for EFI Variables, it is implemented by interacting with
> >>> OP-TEE, StandaloneMM(as EFI Variable Service Pseudo TA), eMMC driver
> >>> and tee-supplicant. The last piece is the tee-based variable access
> >>> driver to interact with OP-TEE and StandaloneMM.
> >>>
> >>> Changelog:
> >>> v5 -> v6
> >>> - new patch #4 is added in this series, #1-#3 patches are unchanged.
> >>>   automatically update super block flag when the efivarops support
> >>>   SetVariable runtime service, so that user does not need to manually
> >>>   remount the efivarfs as RW.
> >>
> >> But that is not yet resolving the architectural problem with that
> >> userspace daemon dependency. What are the next steps for that now?
> >
> > We are trying to find some cycles to work on that, however, I don't
> > have a time estimate on that.  But the question is different here.
> > Since this addresses the problems distros have wrt to SetVariableRT
> > (even for a limited set of platforms) are we ok pulling this in?  I
> > can't think of a technical reason we shouldn't.  The supplicant
> > limitations are known and the firrmwareTPM has a similar set of
> > problems.
>
> It will not change we have to do on the distro side because we have to
> deal not only with the startup issue and StMM but also with fTPM and
> with shutdown. Only an in-kernel supplicant for RPMB would resolve that
> according to my understanding.
>

Exactly and it's worth noting that even that will come with some minor
limitations.  E.g the randomseed variables set by the efistub currently
won't be supported as the modules will come alive way later.  But it's all
reasonable compromises for hardware that wasn't designed to have a
dedicated storage in the secure world and support runtime variables sanely.

> But the question is fair if we can evolve from this stage here to an
> in-kernel approach without causing breakages or other headache to
> distros adopting it (too early). That's why I asked for the roadmap.

Exactly and this is my point as well.  I can't see a technical difference
other than 'you won't need to launch the supplicant'.  The only thing we
need to keep in mind is introduce the fallback between the supplicant and
the (future) kernel supplicant gracefully.  People might still need to run
the supplicant for other reasons.  But if we design it with the kernel
module taking precedence over the supplicant we should be fine.

So since we lived with it a for a few years, I suggest we let it soak a bit
and get tested while we try to move the supplicant bits needed over to the
kernel. In the meantime patch #4 needs some adjustments, so I'll rethink
the supplicant vs kernel module scenario in case I missed something.

Thanks
/Ilias

>
> Jan
>
> --
> Siemens AG, Technology
> Competence Center Embedded Linux
>

On 22.06.23 21:03, Ilias Apalodimas wrote:
> On Thu, Jun 22, 2023 at 08:32:44PM +0200, Jan Kiszka wrote:
>> On 22.06.23 17:04, Ilias Apalodimas wrote:
>>> Hi Jan,
>>>
>>> On Thu, 22 Jun 2023 at 17:56, Jan Kiszka <jan.kiszka@siemens.com> wrote:
>>>>
>>>> On 22.06.23 10:51, Masahisa Kojima wrote:
>>>>> This series introduces the tee based EFI Runtime Variable Service.
>>>>>
>>>>> The eMMC device is typically owned by the non-secure world(linux in
>>>>> this case). There is an existing solution utilizing eMMC RPMB partition
>>>>> for EFI Variables, it is implemented by interacting with
>>>>> OP-TEE, StandaloneMM(as EFI Variable Service Pseudo TA), eMMC driver
>>>>> and tee-supplicant. The last piece is the tee-based variable access
>>>>> driver to interact with OP-TEE and StandaloneMM.
>>>>>
>>>>> Changelog:
>>>>> v5 -> v6
>>>>> - new patch #4 is added in this series, #1-#3 patches are unchanged.
>>>>>   automatically update super block flag when the efivarops support
>>>>>   SetVariable runtime service, so that user does not need to manually
>>>>>   remount the efivarfs as RW.
>>>>
>>>> But that is not yet resolving the architectural problem with that
>>>> userspace daemon dependency. What are the next steps for that now?
>>>
>>> We are trying to find some cycles to work on that, however, I don't
>>> have a time estimate on that.  But the question is different here.
>>> Since this addresses the problems distros have wrt to SetVariableRT
>>> (even for a limited set of platforms) are we ok pulling this in?  I
>>> can't think of a technical reason we shouldn't.  The supplicant
>>> limitations are known and the firrmwareTPM has a similar set of
>>> problems.
>>
>> It will not change we have to do on the distro side because we have to
>> deal not only with the startup issue and StMM but also with fTPM and
>> with shutdown. Only an in-kernel supplicant for RPMB would resolve that
>> according to my understanding.
>>
> 
> Exactly and it's worth noting that even that will come with some minor
> limitations.  E.g the randomseed variables set by the efistub currently
> won't be supported as the modules will come alive way later.  But it's all
> reasonable compromises for hardware that wasn't designed to have a
> dedicated storage in the secure world and support runtime variables sanely.

My feeling is that such simpler setups will be the minority, simply
because eMMCs with RPMBs are standardized, often included anyway, so
come "for free".

> 
>> But the question is fair if we can evolve from this stage here to an
>> in-kernel approach without causing breakages or other headache to
>> distros adopting it (too early). That's why I asked for the roadmap.
> 
> Exactly and this is my point as well.  I can't see a technical difference
> other than 'you won't need to launch the supplicant'.  The only thing we
> need to keep in mind is introduce the fallback between the supplicant and
> the (future) kernel supplicant gracefully.  People might still need to run
> the supplicant for other reasons.  But if we design it with the kernel
> module taking precedence over the supplicant we should be fine.
> 
> So since we lived with it a for a few years, I suggest we let it soak a bit
> and get tested while we try to move the supplicant bits needed over to the
> kernel. In the meantime patch #4 needs some adjustments, so I'll rethink
> the supplicant vs kernel module scenario in case I missed something.

Were there distros adopting all this already? I thought this was a
privilege of custom integrations where you can evolve things simply in
lock-step? At least Debian wasn't considering all these dependencies
yet, even though now providing tee-supplicant. We are patching it for
now [1].

Jan

[1]
https://github.com/BaochengSu/isar/commit/d7646e3bb9d882b26eaf2517fece624010cdd46e

-- 
Siemens AG, Technology
Competence Center Embedded Linux

[...]

> >>>>
> >>>> But that is not yet resolving the architectural problem with that
> >>>> userspace daemon dependency. What are the next steps for that now?
> >>>
> >>> We are trying to find some cycles to work on that, however, I don't
> >>> have a time estimate on that.  But the question is different here.
> >>> Since this addresses the problems distros have wrt to SetVariableRT
> >>> (even for a limited set of platforms) are we ok pulling this in?  I
> >>> can't think of a technical reason we shouldn't.  The supplicant
> >>> limitations are known and the firrmwareTPM has a similar set of
> >>> problems.
> >>
> >> It will not change we have to do on the distro side because we have to
> >> deal not only with the startup issue and StMM but also with fTPM and
> >> with shutdown. Only an in-kernel supplicant for RPMB would resolve that
> >> according to my understanding.
> >>
> >
> > Exactly and it's worth noting that even that will come with some minor
> > limitations.  E.g the randomseed variables set by the efistub currently
> > won't be supported as the modules will come alive way later.  But it's all
> > reasonable compromises for hardware that wasn't designed to have a
> > dedicated storage in the secure world and support runtime variables sanely.
>
> My feeling is that such simpler setups will be the minority, simply
> because eMMCs with RPMBs are standardized, often included anyway, so
> come "for free".
>

Yea maybe, I always have the (maybe false) hope that hardware will evolve
sanely.

> >
> >> But the question is fair if we can evolve from this stage here to an
> >> in-kernel approach without causing breakages or other headache to
> >> distros adopting it (too early). That's why I asked for the roadmap.
> >
> > Exactly and this is my point as well.  I can't see a technical difference
> > other than 'you won't need to launch the supplicant'.  The only thing we
> > need to keep in mind is introduce the fallback between the supplicant and
> > the (future) kernel supplicant gracefully.  People might still need to run
> > the supplicant for other reasons.  But if we design it with the kernel
> > module taking precedence over the supplicant we should be fine.
> >
> > So since we lived with it a for a few years, I suggest we let it soak a bit
> > and get tested while we try to move the supplicant bits needed over to the
> > kernel. In the meantime patch #4 needs some adjustments, so I'll rethink
> > the supplicant vs kernel module scenario in case I missed something.
>
> Were there distros adopting all this already? I thought this was a
> privilege of custom integrations where you can evolve things simply in
> lock-step? At least Debian wasn't considering all these dependencies
> yet, even though now providing tee-supplicant. We are patching it for
> now [1].

I've been working with Fedora and the OP-TEE community to get some of the
pieces in place. As a result, Fedora already compiles the TEE client without
RPMB emulation support [0]. We've also fixed the optee-client and removed the
compile time dependency of choosing the right RPMB.  The device the
supplicant now binds to is selectable at runtime [1]. With these two
already merged the user-space tee client is hardware agnostic (as it should
be).

There's two things missing from distros
- Lift the !PSTORE Kconfig limitation this patchset carries so distros can
  unconditionally enable the module in their builds.  But we can do this
  later while coordinating with distros that build the userspace packages
  correctly.
- Distros needs to scan for the rpmb they want to control in sysfs and
  launch the supplicant with the appropriate --rpmb-cid option

[0] https://src.fedoraproject.org/rpms/optee_client/blob/rawhide/f/optee_client.spec
[1] commit 5a69d55d6596 ("tee-supplicant: add --rpmb-cid command line option")
    in the optee_client repo

Thanks
/Ilias
>
> Jan
>
> [1]
> https://github.com/BaochengSu/isar/commit/d7646e3bb9d882b26eaf2517fece624010cdd46e
>
> --
> Siemens AG, Technology
> Competence Center Embedded Linux
>