| Message ID | 20240527121340.3931987-5-jens.wiklander@linaro.org |
|---|---|
| State | Superseded |
| Headers | show |
| Series | Replay Protected Memory Block (RPMB) subsystem | expand |
On Tue, 28 May 2024 at 14:38, Jens Wiklander <jens.wiklander@linaro.org> wrote: > > Hi Sumit, > > On Mon, May 27, 2024 at 4:38 PM Sumit Garg <sumit.garg@linaro.org> wrote: > > > > On Mon, 27 May 2024 at 17:44, Jens Wiklander <jens.wiklander@linaro.org> wrote: > > > > > > Adds support in the OP-TEE drivers (both SMC and FF-A ABIs) to probe and > > > use an RPMB device via the RPMB subsystem instead of passing the RPMB > > > frames via tee-supplicant in user space. A fallback mechanism is kept to > > > route RPMB frames via tee-supplicant if the RPMB subsystem isn't > > > available. > > > > > > The OP-TEE RPC ABI is extended to support iterating over all RPMB > > > devices until one is found with the expected RPMB key already > > > programmed. > > > > > > Signed-off-by: Jens Wiklander <jens.wiklander@linaro.org> > > > Tested-by: Manuel Traut <manut@mecka.net> > > > --- > > > Documentation/ABI/testing/sysfs-class-tee | 15 ++ > > > MAINTAINERS | 1 + > > > drivers/tee/optee/core.c | 96 +++++++++++- > > > drivers/tee/optee/device.c | 7 + > > > drivers/tee/optee/ffa_abi.c | 14 ++ > > > drivers/tee/optee/optee_ffa.h | 2 + > > > drivers/tee/optee/optee_private.h | 26 +++- > > > drivers/tee/optee/optee_rpc_cmd.h | 35 +++++ > > > drivers/tee/optee/optee_smc.h | 2 + > > > drivers/tee/optee/rpc.c | 177 ++++++++++++++++++++++ > > > drivers/tee/optee/smc_abi.c | 14 ++ > > > 11 files changed, 387 insertions(+), 2 deletions(-) > > > create mode 100644 Documentation/ABI/testing/sysfs-class-tee > > > > > > diff --git a/Documentation/ABI/testing/sysfs-class-tee b/Documentation/ABI/testing/sysfs-class-tee > > > new file mode 100644 > > > index 000000000000..c9144d16003e > > > --- /dev/null > > > +++ b/Documentation/ABI/testing/sysfs-class-tee > > > @@ -0,0 +1,15 @@ > > > +What: /sys/class/tee/tee{,priv}X/rpmb_routing_model > > > +Date: May 2024 > > > +KernelVersion: 6.10 > > > +Contact: op-tee@lists.trustedfirmware.org > > > +Description: > > > + RPMB frames can be routed to the RPMB device via the > > > + user-space daemon tee-supplicant or the RPMB subsystem > > > + in the kernel. The value "user" means that the driver > > > + will route the RPMB frames via user space. Conversely, > > > + "kernel" means that the frames are routed via the RPMB > > > + subsystem without assistance from tee-supplicant. It > > > + should be assumed that RPMB frames are routed via user > > > + space if the variable is absent. The primary purpose > > > + of this variable is to let systemd know whether > > > + tee-supplicant is needed in the early boot with initramfs. > > > > Why do we need this if we already have [1] [2]? AFAICS, whichever > > devices like fTPM etc. systemd depends upon, it can be easily known > > via existing sysfs property. > > > > [1] https://docs.kernel.org/admin-guide/abi-testing.html?highlight=optee#abi-sys-bus-tee-devices-optee-ta-uuid-need-supplicant > > [2] Documentation/ABI/testing/sysfs-bus-optee-devices > > The dependency is reversed. A TA depending on tee-supplicant will not > be loaded until tee-supplicant is ready. rpmb_routing_model is used as > one of the inputs to determine if tee-supplicant must be started early > or if it can wait until the real rootfs is available. > Okay but I am still not able to understand the reasoning as to why tee-supplicant can't be started unconditionally. If it's available in the initrd then systemd should be able to launch it unconditionally. Or is there any dependency I am missing for the tee-supplicant to be started? RPMB routing isn't the only service offered by tee-supplcant, so gating it behind that for no real reason isn't making sense to me. IOW, why do we need to defer starting tee-supplicant until the real rootfs is available? -Sumit
Hi Mikko, On Tue, 28 May 2024 at 15:00, Mikko Rapeli <mikko.rapeli@linaro.org> wrote: > > Hi, > > On Mon, May 27, 2024 at 03:24:01PM +0200, Jens Wiklander wrote: > > On Mon, May 27, 2024 at 3:00 PM Jerome Forissier > > <jerome.forissier@linaro.org> wrote: > > > > > > On 5/27/24 14:13, Jens Wiklander wrote: > > > > Adds support in the OP-TEE drivers (both SMC and FF-A ABIs) to probe and > > > > use an RPMB device via the RPMB subsystem instead of passing the RPMB > > > > frames via tee-supplicant in user space. A fallback mechanism is kept to > > > > route RPMB frames via tee-supplicant if the RPMB subsystem isn't > > > > available. > > > > > > > > The OP-TEE RPC ABI is extended to support iterating over all RPMB > > > > devices until one is found with the expected RPMB key already > > > > programmed. > > > > > > > > Signed-off-by: Jens Wiklander <jens.wiklander@linaro.org> > > > > Tested-by: Manuel Traut <manut@mecka.net> > > > > --- > > > > Documentation/ABI/testing/sysfs-class-tee | 15 ++ > > > > MAINTAINERS | 1 + > > > > drivers/tee/optee/core.c | 96 +++++++++++- > > > > drivers/tee/optee/device.c | 7 + > > > > drivers/tee/optee/ffa_abi.c | 14 ++ > > > > drivers/tee/optee/optee_ffa.h | 2 + > > > > drivers/tee/optee/optee_private.h | 26 +++- > > > > drivers/tee/optee/optee_rpc_cmd.h | 35 +++++ > > > > drivers/tee/optee/optee_smc.h | 2 + > > > > drivers/tee/optee/rpc.c | 177 ++++++++++++++++++++++ > > > > drivers/tee/optee/smc_abi.c | 14 ++ > > > > 11 files changed, 387 insertions(+), 2 deletions(-) > > > > create mode 100644 Documentation/ABI/testing/sysfs-class-tee > > > > > > > > diff --git a/Documentation/ABI/testing/sysfs-class-tee b/Documentation/ABI/testing/sysfs-class-tee > > > > new file mode 100644 > > > > index 000000000000..c9144d16003e > > > > --- /dev/null > > > > +++ b/Documentation/ABI/testing/sysfs-class-tee > > > > @@ -0,0 +1,15 @@ > > > > +What: /sys/class/tee/tee{,priv}X/rpmb_routing_model > > > > > > Wouldn't /sys/class/tee/teeX/rpmb_routing_model be good enough? > > > > Doesn't the routing model concern tee-supplicant more than a TEE > > client? Then it might make more sense to have > > /sys/class/tee/teeprivX/rpmb_routing_model only. Keeping it for both > > devices representing the same internal struct optee makes it easier to > > find. Anyway, I don't mind removing one. Mikko, what do you prefer? > > As simple as possible. A single sysfs file is enough. Even the existence of the sysfs file > could be the needed indicator for userspace to queue tee-supplicant startup. > > Outside of these patches, I think the optee RPC setup with fTPM TA is one area which > currently requires tee-supplicant to be started. Detecting the existence of TPM before > kernel drivers are loaded is possible via the exported EFI logs from firmware to kernel > or ACPI TPM2 table entry, and detecting optee and thus starting tee-supplicant in userspace too. One thing I am trying to find an answer about is why do we need to defer tee-supplicant launch if it's bundled into initrd? Once you detect OP-TEE then tee-supplicant should be launched unconditionally. As per your example below, the motivation here seems to be the TPM2 device dependent on RPMB backend but what if other future systemd services come up and depend on other services offered by tee-supplicant? -Sumit > > In userspace and systemd it's just important to know that service need to wait for a TPM2 > device to appear in early initrd and when can things be postponed to main rootfs and later > stages. Kernel and udev will bring up the device then once discovered. > Knowledge about the RPMB backend is important when something like TPM2 device > depends on it. > > Hope this helps, > > -Mikko
Hi, On Wed, May 29, 2024 at 10:56:04AM +0530, Sumit Garg wrote: > Hi Mikko, > > On Tue, 28 May 2024 at 15:00, Mikko Rapeli <mikko.rapeli@linaro.org> wrote: > > > > Hi, > > > > On Mon, May 27, 2024 at 03:24:01PM +0200, Jens Wiklander wrote: > > > On Mon, May 27, 2024 at 3:00 PM Jerome Forissier > > > <jerome.forissier@linaro.org> wrote: > > > > > > > > On 5/27/24 14:13, Jens Wiklander wrote: > > > > > Adds support in the OP-TEE drivers (both SMC and FF-A ABIs) to probe and > > > > > use an RPMB device via the RPMB subsystem instead of passing the RPMB > > > > > frames via tee-supplicant in user space. A fallback mechanism is kept to > > > > > route RPMB frames via tee-supplicant if the RPMB subsystem isn't > > > > > available. > > > > > > > > > > The OP-TEE RPC ABI is extended to support iterating over all RPMB > > > > > devices until one is found with the expected RPMB key already > > > > > programmed. > > > > > > > > > > Signed-off-by: Jens Wiklander <jens.wiklander@linaro.org> > > > > > Tested-by: Manuel Traut <manut@mecka.net> > > > > > --- > > > > > Documentation/ABI/testing/sysfs-class-tee | 15 ++ > > > > > MAINTAINERS | 1 + > > > > > drivers/tee/optee/core.c | 96 +++++++++++- > > > > > drivers/tee/optee/device.c | 7 + > > > > > drivers/tee/optee/ffa_abi.c | 14 ++ > > > > > drivers/tee/optee/optee_ffa.h | 2 + > > > > > drivers/tee/optee/optee_private.h | 26 +++- > > > > > drivers/tee/optee/optee_rpc_cmd.h | 35 +++++ > > > > > drivers/tee/optee/optee_smc.h | 2 + > > > > > drivers/tee/optee/rpc.c | 177 ++++++++++++++++++++++ > > > > > drivers/tee/optee/smc_abi.c | 14 ++ > > > > > 11 files changed, 387 insertions(+), 2 deletions(-) > > > > > create mode 100644 Documentation/ABI/testing/sysfs-class-tee > > > > > > > > > > diff --git a/Documentation/ABI/testing/sysfs-class-tee b/Documentation/ABI/testing/sysfs-class-tee > > > > > new file mode 100644 > > > > > index 000000000000..c9144d16003e > > > > > --- /dev/null > > > > > +++ b/Documentation/ABI/testing/sysfs-class-tee > > > > > @@ -0,0 +1,15 @@ > > > > > +What: /sys/class/tee/tee{,priv}X/rpmb_routing_model > > > > > > > > Wouldn't /sys/class/tee/teeX/rpmb_routing_model be good enough? > > > > > > Doesn't the routing model concern tee-supplicant more than a TEE > > > client? Then it might make more sense to have > > > /sys/class/tee/teeprivX/rpmb_routing_model only. Keeping it for both > > > devices representing the same internal struct optee makes it easier to > > > find. Anyway, I don't mind removing one. Mikko, what do you prefer? > > > > As simple as possible. A single sysfs file is enough. Even the existence of the sysfs file > > could be the needed indicator for userspace to queue tee-supplicant startup. > > > > Outside of these patches, I think the optee RPC setup with fTPM TA is one area which > > currently requires tee-supplicant to be started. Detecting the existence of TPM before > > kernel drivers are loaded is possible via the exported EFI logs from firmware to kernel > > or ACPI TPM2 table entry, and detecting optee and thus starting tee-supplicant in userspace too. > > One thing I am trying to find an answer about is why do we need to > defer tee-supplicant launch if it's bundled into initrd? Once you > detect OP-TEE then tee-supplicant should be launched unconditionally. > As per your example below, the motivation here seems to be the TPM2 > device dependent on RPMB backend but what if other future systemd > services come up and depend on other services offered by > tee-supplicant? There is an annoying depedency between firmware side optee and TAs, and kernel optee driver, tee-supplicant in userspace and kernel TA drivers like fTPM. Kernel fTPM driver and fTPM TA require tee-supplicant in userspace for RPMB, RPC etc. This patch series is adding kernel side support for RPMB handling so that the dependency to tee-supplicant in userspace can be removed. For fTPM use case, there is still the optee RPC buffer setup which currently requires tee-supplicant in userspace or fTPM TA will panic. So yes, currently, tee-supplicant must be started. But it would be great if kernel drivers and firmware optee trusted applications would not depend on tee-supplicant running in userspace. The startup sequence is really tricky to get right. My fTPM use case is using the TPM device to encrypt rootfs and thus all SW components including tee-supplicant need to run early in initramfs. Currently also switch from initramfs to main rootfs requires unloading fTPM kernel driver and stopping tee-supplicant in initrd, and then starting tee-supplicant and loading fTPM kernel driver from main rootfs. udev and automatic module loading for fTPM can not be used due to the tee-supplicant userspace dependency. As an example, here is v6 of this series on rockpi4b using fTPM TA with systemd based initrd without tee-supplicant and fTPM TA panics because the RPC setup is missing: https://ledge.validation.linaro.org/scheduler/job/87488 [[0;32m OK [0m] Finished [0;1;39mFile System Check on /dev/mapper/usr[0m. E/TC:? 0 get_rpc_alloc_res:645 RPC allocation failed. Non-secure world result: ret=0xffff000c ret_origin=0x2 E/TC:? 0 E/TC:? 0 TA panicked with code 0xffff000c E/LD: Status of TA bc50d971-d4c9-42c4-82cb-343fb7f37896 E/LD: arch: aarch64 E/LD: region 0: va 0x40005000 pa 0x3061b000 size 0x002000 flags rw-s (ldelf) E/LD: region 1: va 0x40007000 pa 0x3061d000 size 0x008000 flags r-xs (ldelf) E/LD: region 2: va 0x4000f000 pa 0x30625000 size 0x001000 flags rw-s (ldelf) E/LD: region 3: va 0x40010000 pa 0x30626000 size 0x004000 flags rw-s (ldelf) E/LD: region 4: va 0x40014000 pa 0x3062a000 size 0x001000 flags r--s E/LD: region 5: va 0x40015000 pa 0x306b2000 size 0x011000 flags rw-s (stack) E/LD: region 6: va 0x40026000 pa 0xe50ce000 size 0x002000 flags rw-- (param) E/LD: region 7: va 0x40062000 pa 0x00001000 size 0x068000 flags r-xs [0] E/LD: region 8: va 0x400ca000 pa 0x00069000 size 0x01f000 flags rw-s [0] E/LD: [0] bc50d971-d4c9-42c4-82cb-343fb7f37896 @ 0x40062000 E/LD: Call stack: E/LD: 0x400a00c0 E/LD: 0x40062b40 E/LD: 0x400631b8 E/LD: 0x40081f44 E/LD: 0x4009b060 E/LD: 0x40063a2c E/LD: 0x400a6298 E/LD: 0x4009b214 [ 7.212584] tpm tpm0: ftpm_tee_tpm_op_send: SUBMIT_COMMAND invoke error: 0xffff3024 [ 7.213281] tpm tpm0: tpm_try_transmit: send(): error -53212 [ 7.213820] tpm tpm0: ftpm_tee_tpm_op_send: SUBMIT_COMMAND invoke error: 0xffff3024 [ 7.214493] tpm tpm0: tpm_try_transmit: send(): error -53212 [ 7.214996] optee-ftpm optee-ta-bc50d971-d4c9-42c4-82cb-343fb7f37896: ftpm_tee_probe: tpm_chip_register failed with rc=-53212 Mounting [0;1;39m/sysusr/usr[0m... This series adds the RPMB support in kernel, if HW supports it, but some HW doesn't and the tee-supplicant is emulating it as fall back. Userspace needs to know if tee-supplicant start is needed. Thus to me, exporting the RPMB routing details is useful for userspace. It's one thing to have a full control of HW and SW and force a policy, like always waiting for a specific TPM device to appear, but then again distros should be able to have automatic detection of TPM devices if firmware used them too and then start the needed bits in userspace, which depend on the firmware and HW configuration, like which SW components are needed for RPMB storage, kernel or tee-supplicant in userspace. These could possibly be just bugs in fTPM kernel driver and fTPM TA in optee world, which should be able to handle missing RPC and RPMB too and retry later on. Right now without tee-supplicant they panic early in boot and become unusable for the rest of the power cycle. Cheers, -Mikko
On Wed, 29 May 2024 at 12:39, Mikko Rapeli <mikko.rapeli@linaro.org> wrote: > > Hi, > > On Wed, May 29, 2024 at 10:56:04AM +0530, Sumit Garg wrote: > > Hi Mikko, > > > > On Tue, 28 May 2024 at 15:00, Mikko Rapeli <mikko.rapeli@linaro.org> wrote: > > > > > > Hi, > > > > > > On Mon, May 27, 2024 at 03:24:01PM +0200, Jens Wiklander wrote: > > > > On Mon, May 27, 2024 at 3:00 PM Jerome Forissier > > > > <jerome.forissier@linaro.org> wrote: > > > > > > > > > > On 5/27/24 14:13, Jens Wiklander wrote: > > > > > > Adds support in the OP-TEE drivers (both SMC and FF-A ABIs) to probe and > > > > > > use an RPMB device via the RPMB subsystem instead of passing the RPMB > > > > > > frames via tee-supplicant in user space. A fallback mechanism is kept to > > > > > > route RPMB frames via tee-supplicant if the RPMB subsystem isn't > > > > > > available. > > > > > > > > > > > > The OP-TEE RPC ABI is extended to support iterating over all RPMB > > > > > > devices until one is found with the expected RPMB key already > > > > > > programmed. > > > > > > > > > > > > Signed-off-by: Jens Wiklander <jens.wiklander@linaro.org> > > > > > > Tested-by: Manuel Traut <manut@mecka.net> > > > > > > --- > > > > > > Documentation/ABI/testing/sysfs-class-tee | 15 ++ > > > > > > MAINTAINERS | 1 + > > > > > > drivers/tee/optee/core.c | 96 +++++++++++- > > > > > > drivers/tee/optee/device.c | 7 + > > > > > > drivers/tee/optee/ffa_abi.c | 14 ++ > > > > > > drivers/tee/optee/optee_ffa.h | 2 + > > > > > > drivers/tee/optee/optee_private.h | 26 +++- > > > > > > drivers/tee/optee/optee_rpc_cmd.h | 35 +++++ > > > > > > drivers/tee/optee/optee_smc.h | 2 + > > > > > > drivers/tee/optee/rpc.c | 177 ++++++++++++++++++++++ > > > > > > drivers/tee/optee/smc_abi.c | 14 ++ > > > > > > 11 files changed, 387 insertions(+), 2 deletions(-) > > > > > > create mode 100644 Documentation/ABI/testing/sysfs-class-tee > > > > > > > > > > > > diff --git a/Documentation/ABI/testing/sysfs-class-tee b/Documentation/ABI/testing/sysfs-class-tee > > > > > > new file mode 100644 > > > > > > index 000000000000..c9144d16003e > > > > > > --- /dev/null > > > > > > +++ b/Documentation/ABI/testing/sysfs-class-tee > > > > > > @@ -0,0 +1,15 @@ > > > > > > +What: /sys/class/tee/tee{,priv}X/rpmb_routing_model > > > > > > > > > > Wouldn't /sys/class/tee/teeX/rpmb_routing_model be good enough? > > > > > > > > Doesn't the routing model concern tee-supplicant more than a TEE > > > > client? Then it might make more sense to have > > > > /sys/class/tee/teeprivX/rpmb_routing_model only. Keeping it for both > > > > devices representing the same internal struct optee makes it easier to > > > > find. Anyway, I don't mind removing one. Mikko, what do you prefer? > > > > > > As simple as possible. A single sysfs file is enough. Even the existence of the sysfs file > > > could be the needed indicator for userspace to queue tee-supplicant startup. > > > > > > Outside of these patches, I think the optee RPC setup with fTPM TA is one area which > > > currently requires tee-supplicant to be started. Detecting the existence of TPM before > > > kernel drivers are loaded is possible via the exported EFI logs from firmware to kernel > > > or ACPI TPM2 table entry, and detecting optee and thus starting tee-supplicant in userspace too. > > > > One thing I am trying to find an answer about is why do we need to > > defer tee-supplicant launch if it's bundled into initrd? Once you > > detect OP-TEE then tee-supplicant should be launched unconditionally. > > As per your example below, the motivation here seems to be the TPM2 > > device dependent on RPMB backend but what if other future systemd > > services come up and depend on other services offered by > > tee-supplicant? > > There is an annoying depedency between firmware side optee and TAs, and kernel optee driver, > tee-supplicant in userspace and kernel TA drivers like fTPM. > > Kernel fTPM driver and fTPM TA require tee-supplicant in userspace for RPMB, RPC etc. > > This patch series is adding kernel side support for RPMB handling so that the dependency to > tee-supplicant in userspace can be removed. For fTPM use case, there is still the optee RPC > buffer setup which currently requires tee-supplicant in userspace or fTPM TA will panic. > > So yes, currently, tee-supplicant must be started. But it would be great if kernel drivers > and firmware optee trusted applications would not depend on tee-supplicant running in userspace. Agree, we are aligned here. With this patch-set we aim to achieve that, the user-space dependency for kernel drivers is hard to manage and it's better to get rid of it. However, backwards compatibility for distros will still require starting tee-supplicant. > The startup sequence is really tricky to get right. My fTPM use case is using the TPM device > to encrypt rootfs and thus all SW components including tee-supplicant need to run early in > initramfs. Currently also switch from initramfs to main rootfs requires unloading > fTPM kernel driver and stopping tee-supplicant in initrd, and then starting tee-supplicant > and loading fTPM kernel driver from main rootfs. udev and automatic module loading for > fTPM can not be used due to the tee-supplicant userspace dependency. This is one of the reasons for gating tee-supplicant loading which I was looking for. What happens if we want to keep tee-supplicant alive when we migrate from initramfs to real rootfs? Does it work? > > As an example, here is v6 of this series on rockpi4b using fTPM TA with systemd based initrd > without tee-supplicant and fTPM TA panics because the RPC setup is missing: I think this is due to RPC allocation requested from tee-supplicant during RPMB operations. Can you try following untested optee-os diff and see if it resolves the problem for you? diff --git a/core/tee/tee_rpmb_fs.c b/core/tee/tee_rpmb_fs.c index 0ed30933b..b3d4d077a 100644 --- a/core/tee/tee_rpmb_fs.c +++ b/core/tee/tee_rpmb_fs.c @@ -418,11 +418,11 @@ static void tee_rpmb_free(struct tee_rpmb_mem *mem) return; if (mem->phreq_mobj) { - thread_rpc_free_payload(mem->phreq_mobj); + thread_rpc_free_kernel_payload(mem->phreq_mobj); mem->phreq_mobj = NULL; } if (mem->phresp_mobj) { - thread_rpc_free_payload(mem->phresp_mobj); + thread_rpc_free_kernel_payload(mem->phresp_mobj); mem->phresp_mobj = NULL; } } @@ -440,8 +440,8 @@ static TEE_Result tee_rpmb_alloc(size_t req_size, size_t resp_size, memset(mem, 0, sizeof(*mem)); - mem->phreq_mobj = thread_rpc_alloc_payload(req_s); - mem->phresp_mobj = thread_rpc_alloc_payload(resp_s); + mem->phreq_mobj = thread_rpc_alloc_kernel_payload(req_s); + mem->phresp_mobj = thread_rpc_alloc_kernel_payload(resp_s); if (!mem->phreq_mobj || !mem->phresp_mobj) { res = TEE_ERROR_OUT_OF_MEMORY; > > https://ledge.validation.linaro.org/scheduler/job/87488 > > [[0;32m OK [0m] Finished [0;1;39mFile System Check on /dev/mapper/usr[0m. > E/TC:? 0 get_rpc_alloc_res:645 RPC allocation failed. Non-secure world result: ret=0xffff000c ret_origin=0x2 > E/TC:? 0 > E/TC:? 0 TA panicked with code 0xffff000c > E/LD: Status of TA bc50d971-d4c9-42c4-82cb-343fb7f37896 > E/LD: arch: aarch64 > E/LD: region 0: va 0x40005000 pa 0x3061b000 size 0x002000 flags rw-s (ldelf) > E/LD: region 1: va 0x40007000 pa 0x3061d000 size 0x008000 flags r-xs (ldelf) > E/LD: region 2: va 0x4000f000 pa 0x30625000 size 0x001000 flags rw-s (ldelf) > E/LD: region 3: va 0x40010000 pa 0x30626000 size 0x004000 flags rw-s (ldelf) > E/LD: region 4: va 0x40014000 pa 0x3062a000 size 0x001000 flags r--s > E/LD: region 5: va 0x40015000 pa 0x306b2000 size 0x011000 flags rw-s (stack) > E/LD: region 6: va 0x40026000 pa 0xe50ce000 size 0x002000 flags rw-- (param) > E/LD: region 7: va 0x40062000 pa 0x00001000 size 0x068000 flags r-xs [0] > E/LD: region 8: va 0x400ca000 pa 0x00069000 size 0x01f000 flags rw-s [0] > E/LD: [0] bc50d971-d4c9-42c4-82cb-343fb7f37896 @ 0x40062000 > E/LD: Call stack: > E/LD: 0x400a00c0 > E/LD: 0x40062b40 > E/LD: 0x400631b8 > E/LD: 0x40081f44 > E/LD: 0x4009b060 > E/LD: 0x40063a2c > E/LD: 0x400a6298 > E/LD: 0x4009b214 > [ 7.212584] tpm tpm0: ftpm_tee_tpm_op_send: SUBMIT_COMMAND invoke error: 0xffff3024 > [ 7.213281] tpm tpm0: tpm_try_transmit: send(): error -53212 > [ 7.213820] tpm tpm0: ftpm_tee_tpm_op_send: SUBMIT_COMMAND invoke error: 0xffff3024 > [ 7.214493] tpm tpm0: tpm_try_transmit: send(): error -53212 > [ 7.214996] optee-ftpm optee-ta-bc50d971-d4c9-42c4-82cb-343fb7f37896: ftpm_tee_probe: tpm_chip_register failed with rc=-53212 > Mounting [0;1;39m/sysusr/usr[0m... > > This series adds the RPMB support in kernel, if HW supports it, but some HW doesn't and the > tee-supplicant is emulating it as fall back. That's just for testing purposes, right? It won't be used to implement disk encryption for that HW. > Userspace needs to know if tee-supplicant start > is needed. Thus to me, exporting the RPMB routing details is useful for userspace. > > It's one thing to have a full control of HW and SW and force a policy, like always > waiting for a specific TPM device to appear, but then again distros should be able > to have automatic detection of TPM devices if firmware used them too and then > start the needed bits in userspace, which depend on the firmware and HW configuration, > like which SW components are needed for RPMB storage, kernel or tee-supplicant in userspace. > > These could possibly be just bugs in fTPM kernel driver and fTPM TA in optee world, > which should be able to handle missing RPC and RPMB too and retry later on. Right now > without tee-supplicant they panic early in boot and become unusable for the rest of the > power cycle. I very much would like to see fTPM working without dependency on tee-supplicant. If there are any further problems you see then please feel free to report. -Sumit > > Cheers, > > -Mikko
On Wed, 29 May 2024 at 13:36, Sumit Garg <sumit.garg@linaro.org> wrote: > > On Wed, 29 May 2024 at 12:39, Mikko Rapeli <mikko.rapeli@linaro.org> wrote: > > > > Hi, > > > > On Wed, May 29, 2024 at 10:56:04AM +0530, Sumit Garg wrote: > > > Hi Mikko, > > > > > > On Tue, 28 May 2024 at 15:00, Mikko Rapeli <mikko.rapeli@linaro.org> wrote: > > > > > > > > Hi, > > > > > > > > On Mon, May 27, 2024 at 03:24:01PM +0200, Jens Wiklander wrote: > > > > > On Mon, May 27, 2024 at 3:00 PM Jerome Forissier > > > > > <jerome.forissier@linaro.org> wrote: > > > > > > > > > > > > On 5/27/24 14:13, Jens Wiklander wrote: > > > > > > > Adds support in the OP-TEE drivers (both SMC and FF-A ABIs) to probe and > > > > > > > use an RPMB device via the RPMB subsystem instead of passing the RPMB > > > > > > > frames via tee-supplicant in user space. A fallback mechanism is kept to > > > > > > > route RPMB frames via tee-supplicant if the RPMB subsystem isn't > > > > > > > available. > > > > > > > > > > > > > > The OP-TEE RPC ABI is extended to support iterating over all RPMB > > > > > > > devices until one is found with the expected RPMB key already > > > > > > > programmed. > > > > > > > > > > > > > > Signed-off-by: Jens Wiklander <jens.wiklander@linaro.org> > > > > > > > Tested-by: Manuel Traut <manut@mecka.net> > > > > > > > --- > > > > > > > Documentation/ABI/testing/sysfs-class-tee | 15 ++ > > > > > > > MAINTAINERS | 1 + > > > > > > > drivers/tee/optee/core.c | 96 +++++++++++- > > > > > > > drivers/tee/optee/device.c | 7 + > > > > > > > drivers/tee/optee/ffa_abi.c | 14 ++ > > > > > > > drivers/tee/optee/optee_ffa.h | 2 + > > > > > > > drivers/tee/optee/optee_private.h | 26 +++- > > > > > > > drivers/tee/optee/optee_rpc_cmd.h | 35 +++++ > > > > > > > drivers/tee/optee/optee_smc.h | 2 + > > > > > > > drivers/tee/optee/rpc.c | 177 ++++++++++++++++++++++ > > > > > > > drivers/tee/optee/smc_abi.c | 14 ++ > > > > > > > 11 files changed, 387 insertions(+), 2 deletions(-) > > > > > > > create mode 100644 Documentation/ABI/testing/sysfs-class-tee > > > > > > > > > > > > > > diff --git a/Documentation/ABI/testing/sysfs-class-tee b/Documentation/ABI/testing/sysfs-class-tee > > > > > > > new file mode 100644 > > > > > > > index 000000000000..c9144d16003e > > > > > > > --- /dev/null > > > > > > > +++ b/Documentation/ABI/testing/sysfs-class-tee > > > > > > > @@ -0,0 +1,15 @@ > > > > > > > +What: /sys/class/tee/tee{,priv}X/rpmb_routing_model > > > > > > > > > > > > Wouldn't /sys/class/tee/teeX/rpmb_routing_model be good enough? > > > > > > > > > > Doesn't the routing model concern tee-supplicant more than a TEE > > > > > client? Then it might make more sense to have > > > > > /sys/class/tee/teeprivX/rpmb_routing_model only. Keeping it for both > > > > > devices representing the same internal struct optee makes it easier to > > > > > find. Anyway, I don't mind removing one. Mikko, what do you prefer? > > > > > > > > As simple as possible. A single sysfs file is enough. Even the existence of the sysfs file > > > > could be the needed indicator for userspace to queue tee-supplicant startup. > > > > > > > > Outside of these patches, I think the optee RPC setup with fTPM TA is one area which > > > > currently requires tee-supplicant to be started. Detecting the existence of TPM before > > > > kernel drivers are loaded is possible via the exported EFI logs from firmware to kernel > > > > or ACPI TPM2 table entry, and detecting optee and thus starting tee-supplicant in userspace too. > > > > > > One thing I am trying to find an answer about is why do we need to > > > defer tee-supplicant launch if it's bundled into initrd? Once you > > > detect OP-TEE then tee-supplicant should be launched unconditionally. > > > As per your example below, the motivation here seems to be the TPM2 > > > device dependent on RPMB backend but what if other future systemd > > > services come up and depend on other services offered by > > > tee-supplicant? > > > > There is an annoying depedency between firmware side optee and TAs, and kernel optee driver, > > tee-supplicant in userspace and kernel TA drivers like fTPM. > > > > Kernel fTPM driver and fTPM TA require tee-supplicant in userspace for RPMB, RPC etc. > > > > This patch series is adding kernel side support for RPMB handling so that the dependency to > > tee-supplicant in userspace can be removed. For fTPM use case, there is still the optee RPC > > buffer setup which currently requires tee-supplicant in userspace or fTPM TA will panic. > > > > So yes, currently, tee-supplicant must be started. But it would be great if kernel drivers > > and firmware optee trusted applications would not depend on tee-supplicant running in userspace. > > Agree, we are aligned here. With this patch-set we aim to achieve > that, the user-space dependency for kernel drivers is hard to manage > and it's better to get rid of it. However, backwards compatibility for > distros will still require starting tee-supplicant. > > > The startup sequence is really tricky to get right. My fTPM use case is using the TPM device > > to encrypt rootfs and thus all SW components including tee-supplicant need to run early in > > initramfs. Currently also switch from initramfs to main rootfs requires unloading > > fTPM kernel driver and stopping tee-supplicant in initrd, and then starting tee-supplicant > > and loading fTPM kernel driver from main rootfs. udev and automatic module loading for > > fTPM can not be used due to the tee-supplicant userspace dependency. > > This is one of the reasons for gating tee-supplicant loading which I > was looking for. What happens if we want to keep tee-supplicant alive > when we migrate from initramfs to real rootfs? Does it work? > > > > > As an example, here is v6 of this series on rockpi4b using fTPM TA with systemd based initrd > > without tee-supplicant and fTPM TA panics because the RPC setup is missing: > > I think this is due to RPC allocation requested from tee-supplicant > during RPMB operations. Can you try following untested optee-os diff > and see if it resolves the problem for you? Scratch that as I can see Jens has already reworked that code here [1] and I suppose you are running on top of that. Can you rather add further RPC debugging prints to see which RPC gets invoked when running fTPM TA? [1] https://github.com/jenswi-linaro/optee_os/commits/rpmb_probe_v7/ -Sumit > > diff --git a/core/tee/tee_rpmb_fs.c b/core/tee/tee_rpmb_fs.c > index 0ed30933b..b3d4d077a 100644 > --- a/core/tee/tee_rpmb_fs.c > +++ b/core/tee/tee_rpmb_fs.c > @@ -418,11 +418,11 @@ static void tee_rpmb_free(struct tee_rpmb_mem *mem) > return; > > if (mem->phreq_mobj) { > - thread_rpc_free_payload(mem->phreq_mobj); > + thread_rpc_free_kernel_payload(mem->phreq_mobj); > mem->phreq_mobj = NULL; > } > if (mem->phresp_mobj) { > - thread_rpc_free_payload(mem->phresp_mobj); > + thread_rpc_free_kernel_payload(mem->phresp_mobj); > mem->phresp_mobj = NULL; > } > } > @@ -440,8 +440,8 @@ static TEE_Result tee_rpmb_alloc(size_t req_size, > size_t resp_size, > > memset(mem, 0, sizeof(*mem)); > > - mem->phreq_mobj = thread_rpc_alloc_payload(req_s); > - mem->phresp_mobj = thread_rpc_alloc_payload(resp_s); > + mem->phreq_mobj = thread_rpc_alloc_kernel_payload(req_s); > + mem->phresp_mobj = thread_rpc_alloc_kernel_payload(resp_s); > > if (!mem->phreq_mobj || !mem->phresp_mobj) { > res = TEE_ERROR_OUT_OF_MEMORY; > > > > > https://ledge.validation.linaro.org/scheduler/job/87488 > > > > [[0;32m OK [0m] Finished [0;1;39mFile System Check on /dev/mapper/usr[0m. > > E/TC:? 0 get_rpc_alloc_res:645 RPC allocation failed. Non-secure world result: ret=0xffff000c ret_origin=0x2 > > E/TC:? 0 > > E/TC:? 0 TA panicked with code 0xffff000c > > E/LD: Status of TA bc50d971-d4c9-42c4-82cb-343fb7f37896 > > E/LD: arch: aarch64 > > E/LD: region 0: va 0x40005000 pa 0x3061b000 size 0x002000 flags rw-s (ldelf) > > E/LD: region 1: va 0x40007000 pa 0x3061d000 size 0x008000 flags r-xs (ldelf) > > E/LD: region 2: va 0x4000f000 pa 0x30625000 size 0x001000 flags rw-s (ldelf) > > E/LD: region 3: va 0x40010000 pa 0x30626000 size 0x004000 flags rw-s (ldelf) > > E/LD: region 4: va 0x40014000 pa 0x3062a000 size 0x001000 flags r--s > > E/LD: region 5: va 0x40015000 pa 0x306b2000 size 0x011000 flags rw-s (stack) > > E/LD: region 6: va 0x40026000 pa 0xe50ce000 size 0x002000 flags rw-- (param) > > E/LD: region 7: va 0x40062000 pa 0x00001000 size 0x068000 flags r-xs [0] > > E/LD: region 8: va 0x400ca000 pa 0x00069000 size 0x01f000 flags rw-s [0] > > E/LD: [0] bc50d971-d4c9-42c4-82cb-343fb7f37896 @ 0x40062000 > > E/LD: Call stack: > > E/LD: 0x400a00c0 > > E/LD: 0x40062b40 > > E/LD: 0x400631b8 > > E/LD: 0x40081f44 > > E/LD: 0x4009b060 > > E/LD: 0x40063a2c > > E/LD: 0x400a6298 > > E/LD: 0x4009b214 > > [ 7.212584] tpm tpm0: ftpm_tee_tpm_op_send: SUBMIT_COMMAND invoke error: 0xffff3024 > > [ 7.213281] tpm tpm0: tpm_try_transmit: send(): error -53212 > > [ 7.213820] tpm tpm0: ftpm_tee_tpm_op_send: SUBMIT_COMMAND invoke error: 0xffff3024 > > [ 7.214493] tpm tpm0: tpm_try_transmit: send(): error -53212 > > [ 7.214996] optee-ftpm optee-ta-bc50d971-d4c9-42c4-82cb-343fb7f37896: ftpm_tee_probe: tpm_chip_register failed with rc=-53212 > > Mounting [0;1;39m/sysusr/usr[0m... > > > > This series adds the RPMB support in kernel, if HW supports it, but some HW doesn't and the > > tee-supplicant is emulating it as fall back. > > That's just for testing purposes, right? It won't be used to implement > disk encryption for that HW. > > > Userspace needs to know if tee-supplicant start > > is needed. Thus to me, exporting the RPMB routing details is useful for userspace. > > > > It's one thing to have a full control of HW and SW and force a policy, like always > > waiting for a specific TPM device to appear, but then again distros should be able > > to have automatic detection of TPM devices if firmware used them too and then > > start the needed bits in userspace, which depend on the firmware and HW configuration, > > like which SW components are needed for RPMB storage, kernel or tee-supplicant in userspace. > > > > These could possibly be just bugs in fTPM kernel driver and fTPM TA in optee world, > > which should be able to handle missing RPC and RPMB too and retry later on. Right now > > without tee-supplicant they panic early in boot and become unusable for the rest of the > > power cycle. > > I very much would like to see fTPM working without dependency on > tee-supplicant. If there are any further problems you see then please > feel free to report. > > -Sumit > > > > > Cheers, > > > > -Mikko
Hi Mikko, On 10:09 Wed 29 May , Mikko Rapeli wrote: > On Wed, May 29, 2024 at 10:56:04AM +0530, Sumit Garg wrote: > > On Tue, 28 May 2024 at 15:00, Mikko Rapeli <mikko.rapeli@linaro.org> wrote: > > > On Mon, May 27, 2024 at 03:24:01PM +0200, Jens Wiklander wrote: > > > > On Mon, May 27, 2024 at 3:00 PM Jerome Forissier > > > > <jerome.forissier@linaro.org> wrote: > > > > > On 5/27/24 14:13, Jens Wiklander wrote: > > > Outside of these patches, I think the optee RPC setup with fTPM TA is one area which > > > currently requires tee-supplicant to be started. Detecting the existence of TPM before > > > kernel drivers are loaded is possible via the exported EFI logs from firmware to kernel > > > or ACPI TPM2 table entry, and detecting optee and thus starting tee-supplicant in userspace too. > > > > One thing I am trying to find an answer about is why do we need to > > defer tee-supplicant launch if it's bundled into initrd? Once you > > detect OP-TEE then tee-supplicant should be launched unconditionally. > > As per your example below, the motivation here seems to be the TPM2 > > device dependent on RPMB backend but what if other future systemd > > services come up and depend on other services offered by > > tee-supplicant? > > There is an annoying depedency between firmware side optee and TAs, and kernel optee driver, > tee-supplicant in userspace and kernel TA drivers like fTPM. > > Kernel fTPM driver and fTPM TA require tee-supplicant in userspace for RPMB, RPC etc. > > This patch series is adding kernel side support for RPMB handling so that the dependency to > tee-supplicant in userspace can be removed. For fTPM use case, there is still the optee RPC > buffer setup which currently requires tee-supplicant in userspace or fTPM TA will panic. > > So yes, currently, tee-supplicant must be started. But it would be great if kernel drivers > and firmware optee trusted applications would not depend on tee-supplicant running in userspace. > The startup sequence is really tricky to get right. My fTPM use case is using the TPM device > to encrypt rootfs and thus all SW components including tee-supplicant need to run early in > initramfs. Currently also switch from initramfs to main rootfs requires unloading > fTPM kernel driver and stopping tee-supplicant in initrd, and then starting tee-supplicant > and loading fTPM kernel driver from main rootfs. udev and automatic module loading for > fTPM can not be used due to the tee-supplicant userspace dependency. I decided to build fTPM as buildin-TA into OP-TEE. RPMB routing is already implemented in u-boot so it can already write PCR registers. With this series and the required changes in OP-TEE and a compiled in fTPM kernel driver and systemd v256 it is possible to use the fTPM in the initrd without tee-supplicant. Maybe this information is helpful to you, regards Manuel
Hi, On Wed, May 29, 2024 at 11:38:06AM +0200, Manuel Traut wrote: > Hi Mikko, > > On 10:09 Wed 29 May , Mikko Rapeli wrote: > > On Wed, May 29, 2024 at 10:56:04AM +0530, Sumit Garg wrote: > > > On Tue, 28 May 2024 at 15:00, Mikko Rapeli <mikko.rapeli@linaro.org> wrote: > > > > On Mon, May 27, 2024 at 03:24:01PM +0200, Jens Wiklander wrote: > > > > > On Mon, May 27, 2024 at 3:00 PM Jerome Forissier > > > > > <jerome.forissier@linaro.org> wrote: > > > > > > On 5/27/24 14:13, Jens Wiklander wrote: > > > > Outside of these patches, I think the optee RPC setup with fTPM TA is one area which > > > > currently requires tee-supplicant to be started. Detecting the existence of TPM before > > > > kernel drivers are loaded is possible via the exported EFI logs from firmware to kernel > > > > or ACPI TPM2 table entry, and detecting optee and thus starting tee-supplicant in userspace too. > > > > > > One thing I am trying to find an answer about is why do we need to > > > defer tee-supplicant launch if it's bundled into initrd? Once you > > > detect OP-TEE then tee-supplicant should be launched unconditionally. > > > As per your example below, the motivation here seems to be the TPM2 > > > device dependent on RPMB backend but what if other future systemd > > > services come up and depend on other services offered by > > > tee-supplicant? > > > > There is an annoying depedency between firmware side optee and TAs, and kernel optee driver, > > tee-supplicant in userspace and kernel TA drivers like fTPM. > > > > Kernel fTPM driver and fTPM TA require tee-supplicant in userspace for RPMB, RPC etc. > > > > This patch series is adding kernel side support for RPMB handling so that the dependency to > > tee-supplicant in userspace can be removed. For fTPM use case, there is still the optee RPC > > buffer setup which currently requires tee-supplicant in userspace or fTPM TA will panic. > > > > So yes, currently, tee-supplicant must be started. But it would be great if kernel drivers > > and firmware optee trusted applications would not depend on tee-supplicant running in userspace. > > The startup sequence is really tricky to get right. My fTPM use case is using the TPM device > > to encrypt rootfs and thus all SW components including tee-supplicant need to run early in > > initramfs. Currently also switch from initramfs to main rootfs requires unloading > > fTPM kernel driver and stopping tee-supplicant in initrd, and then starting tee-supplicant > > and loading fTPM kernel driver from main rootfs. udev and automatic module loading for > > fTPM can not be used due to the tee-supplicant userspace dependency. > > I decided to build fTPM as buildin-TA into OP-TEE. RPMB routing is already > implemented in u-boot so it can already write PCR registers. Is build in TA same as early TA? I presume so. > With this series and the required changes in OP-TEE and a compiled in fTPM > kernel driver and systemd v256 it is possible to use the fTPM in the initrd > without tee-supplicant. > > Maybe this information is helpful to you, regards This is very interesting and I'm trying to get to the same state, though with fTPM kernel driver as module. With v6 of this patch set and matching optee changes I was not able to make this work as fTPM TA was crashing when loading ftpm kernel driver due to failing RPC allocation, which tee-supplicant was setting up in the whole chain. I'll try to get v7 patches working and test this again on my yocto based setup and kernel 6.6.y. Cheers, -Mikko
Hi Mikko, On Wed, May 29, 2024 at 05:26:15PM +0300, Mikko Rapeli wrote: > Hi, > > On Wed, May 29, 2024 at 11:38:06AM +0200, Manuel Traut wrote: > > Hi Mikko, > > > > On 10:09 Wed 29 May , Mikko Rapeli wrote: > > > On Wed, May 29, 2024 at 10:56:04AM +0530, Sumit Garg wrote: > > > > On Tue, 28 May 2024 at 15:00, Mikko Rapeli <mikko.rapeli@linaro.org> wrote: > > > > > On Mon, May 27, 2024 at 03:24:01PM +0200, Jens Wiklander wrote: > > > > > > On Mon, May 27, 2024 at 3:00 PM Jerome Forissier > > > > > > <jerome.forissier@linaro.org> wrote: > > > > > > > On 5/27/24 14:13, Jens Wiklander wrote: > > > > > Outside of these patches, I think the optee RPC setup with fTPM TA is one area which > > > > > currently requires tee-supplicant to be started. Detecting the existence of TPM before > > > > > kernel drivers are loaded is possible via the exported EFI logs from firmware to kernel > > > > > or ACPI TPM2 table entry, and detecting optee and thus starting tee-supplicant in userspace too. > > > > > > > > One thing I am trying to find an answer about is why do we need to > > > > defer tee-supplicant launch if it's bundled into initrd? Once you > > > > detect OP-TEE then tee-supplicant should be launched unconditionally. > > > > As per your example below, the motivation here seems to be the TPM2 > > > > device dependent on RPMB backend but what if other future systemd > > > > services come up and depend on other services offered by > > > > tee-supplicant? > > > > > > There is an annoying depedency between firmware side optee and TAs, and kernel optee driver, > > > tee-supplicant in userspace and kernel TA drivers like fTPM. > > > > > > Kernel fTPM driver and fTPM TA require tee-supplicant in userspace for RPMB, RPC etc. > > > > > > This patch series is adding kernel side support for RPMB handling so that the dependency to > > > tee-supplicant in userspace can be removed. For fTPM use case, there is still the optee RPC > > > buffer setup which currently requires tee-supplicant in userspace or fTPM TA will panic. > > > > > > So yes, currently, tee-supplicant must be started. But it would be great if kernel drivers > > > and firmware optee trusted applications would not depend on tee-supplicant running in userspace. > > > The startup sequence is really tricky to get right. My fTPM use case is using the TPM device > > > to encrypt rootfs and thus all SW components including tee-supplicant need to run early in > > > initramfs. Currently also switch from initramfs to main rootfs requires unloading > > > fTPM kernel driver and stopping tee-supplicant in initrd, and then starting tee-supplicant > > > and loading fTPM kernel driver from main rootfs. udev and automatic module loading for > > > fTPM can not be used due to the tee-supplicant userspace dependency. > > > > I decided to build fTPM as buildin-TA into OP-TEE. RPMB routing is already > > implemented in u-boot so it can already write PCR registers. > > Is build in TA same as early TA? I presume so. Indeed.. sorry for using the wrong term. > > With this series and the required changes in OP-TEE and a compiled in fTPM > > kernel driver and systemd v256 it is possible to use the fTPM in the initrd > > without tee-supplicant. > > > > Maybe this information is helpful to you, regards > > This is very interesting and I'm trying to get to the same state, though with > fTPM kernel driver as module. With v6 of this patch set and matching optee changes > I was not able to make this work as fTPM TA was crashing when loading ftpm kernel driver > due to failing RPC allocation, which tee-supplicant was setting up in the whole chain. > I'll try to get v7 patches working and test this again on my yocto based setup and kernel 6.6.y. I'll try today also with v7 and 6.10-rc1 on an i.MX8MM. It should also work with fTPM as kernel module if you use systemd in the initrd with the new tpm.target in systemd v256. Regards Manuel
On Thu, May 30, 2024 at 09:35:10AM +0200, Manuel Traut wrote: > Hi Mikko, > > On Wed, May 29, 2024 at 05:26:15PM +0300, Mikko Rapeli wrote: > > Hi, > > > > On Wed, May 29, 2024 at 11:38:06AM +0200, Manuel Traut wrote: > > > Hi Mikko, > > > > > > On 10:09 Wed 29 May , Mikko Rapeli wrote: > > > > On Wed, May 29, 2024 at 10:56:04AM +0530, Sumit Garg wrote: > > > > > On Tue, 28 May 2024 at 15:00, Mikko Rapeli <mikko.rapeli@linaro.org> wrote: > > > > > > On Mon, May 27, 2024 at 03:24:01PM +0200, Jens Wiklander wrote: > > > > > > > On Mon, May 27, 2024 at 3:00 PM Jerome Forissier > > > > > > > <jerome.forissier@linaro.org> wrote: > > > > > > > > On 5/27/24 14:13, Jens Wiklander wrote: > > > > > > Outside of these patches, I think the optee RPC setup with fTPM TA is one area which > > > > > > currently requires tee-supplicant to be started. Detecting the existence of TPM before > > > > > > kernel drivers are loaded is possible via the exported EFI logs from firmware to kernel > > > > > > or ACPI TPM2 table entry, and detecting optee and thus starting tee-supplicant in userspace too. > > > > > > > > > > One thing I am trying to find an answer about is why do we need to > > > > > defer tee-supplicant launch if it's bundled into initrd? Once you > > > > > detect OP-TEE then tee-supplicant should be launched unconditionally. > > > > > As per your example below, the motivation here seems to be the TPM2 > > > > > device dependent on RPMB backend but what if other future systemd > > > > > services come up and depend on other services offered by > > > > > tee-supplicant? > > > > > > > > There is an annoying depedency between firmware side optee and TAs, and kernel optee driver, > > > > tee-supplicant in userspace and kernel TA drivers like fTPM. > > > > > > > > Kernel fTPM driver and fTPM TA require tee-supplicant in userspace for RPMB, RPC etc. > > > > > > > > This patch series is adding kernel side support for RPMB handling so that the dependency to > > > > tee-supplicant in userspace can be removed. For fTPM use case, there is still the optee RPC > > > > buffer setup which currently requires tee-supplicant in userspace or fTPM TA will panic. > > > > > > > > So yes, currently, tee-supplicant must be started. But it would be great if kernel drivers > > > > and firmware optee trusted applications would not depend on tee-supplicant running in userspace. > > > > The startup sequence is really tricky to get right. My fTPM use case is using the TPM device > > > > to encrypt rootfs and thus all SW components including tee-supplicant need to run early in > > > > initramfs. Currently also switch from initramfs to main rootfs requires unloading > > > > fTPM kernel driver and stopping tee-supplicant in initrd, and then starting tee-supplicant > > > > and loading fTPM kernel driver from main rootfs. udev and automatic module loading for > > > > fTPM can not be used due to the tee-supplicant userspace dependency. > > > > > > I decided to build fTPM as buildin-TA into OP-TEE. RPMB routing is already > > > implemented in u-boot so it can already write PCR registers. > > > > Is build in TA same as early TA? I presume so. > > Indeed.. sorry for using the wrong term. Ok, no problem. Then we have the same fTPM TA setup. I'm using optee 4.1 with RPMB kernel support changes from Jens cherry-picked on top. > > > With this series and the required changes in OP-TEE and a compiled in fTPM > > > kernel driver and systemd v256 it is possible to use the fTPM in the initrd > > > without tee-supplicant. > > > > > > Maybe this information is helpful to you, regards > > > > This is very interesting and I'm trying to get to the same state, though with > > fTPM kernel driver as module. With v6 of this patch set and matching optee changes > > I was not able to make this work as fTPM TA was crashing when loading ftpm kernel driver > > due to failing RPC allocation, which tee-supplicant was setting up in the whole chain. > > I'll try to get v7 patches working and test this again on my yocto based setup and kernel 6.6.y. > > I'll try today also with v7 and 6.10-rc1 on an i.MX8MM. It should also > work with fTPM as kernel module if you use systemd in the initrd > with the new tpm.target in systemd v256. Thanks for the details. I'm testing on qemu, rockpi4b (Rockchip rk3399 SoC) and synquacer (Socionext Developer Box, SC2A11:Cortex-A53 MPCore 24cores). Kernel and rootfs are from our yocto master branch based Trusted Reference Stack distro ( https://gitlab.com/Linaro/trusted-reference-stack/trs ) with kernel 6.6.29 (porting the RPMB v7 patches currently), systemd 255.4 (tpm2.target backported), tee-supplicant 4.1 etc. I'm switching the initramfs from shell scripts to systemd currently, but running into various issues. UEFI firmware is our Trusted Substrate ( https://gitlab.com/Linaro/trustedsubstrate/meta-ts/ ) ARM System Ready IR compatible with secure boot and TPM support, u-boot 2024.04 (except rockpi4b still on 2023.01), optee 4.1, fTPM etc from meta-arm yocto layer. Booting without tee-supplicant has so far only resulted in the fTPM TA panic'ing because RPC setup is failing. Also the fTPM TA enumation needs to be changed from current yocto defaults to always discoverable if there is no tee-supplicant: https://git.yoctoproject.org/meta-arm/tree/meta-arm/recipes-security/optee-ftpm/optee-ftpm/0001-add-enum-to-ta-flags.patch I hope to get v7 of these patches into testing today. Cheers, -Mikko
On Thu, May 30, 2024 at 11:29:11AM +0300, Mikko Rapeli wrote: > On Thu, May 30, 2024 at 09:35:10AM +0200, Manuel Traut wrote: > > Hi Mikko, > > > > On Wed, May 29, 2024 at 05:26:15PM +0300, Mikko Rapeli wrote: > > > Hi, > > > > > > On Wed, May 29, 2024 at 11:38:06AM +0200, Manuel Traut wrote: > > > > Hi Mikko, > > > > > > > > On 10:09 Wed 29 May , Mikko Rapeli wrote: > > > > > On Wed, May 29, 2024 at 10:56:04AM +0530, Sumit Garg wrote: > > > > > > On Tue, 28 May 2024 at 15:00, Mikko Rapeli <mikko.rapeli@linaro.org> wrote: > > > > > > > On Mon, May 27, 2024 at 03:24:01PM +0200, Jens Wiklander wrote: > > > > > > > > On Mon, May 27, 2024 at 3:00 PM Jerome Forissier > > > > > > > > <jerome.forissier@linaro.org> wrote: > > > > > > > > > On 5/27/24 14:13, Jens Wiklander wrote: > > > > > > > Outside of these patches, I think the optee RPC setup with fTPM TA is one area which > > > > > > > currently requires tee-supplicant to be started. Detecting the existence of TPM before > > > > > > > kernel drivers are loaded is possible via the exported EFI logs from firmware to kernel > > > > > > > or ACPI TPM2 table entry, and detecting optee and thus starting tee-supplicant in userspace too. > > > > > > > > > > > > One thing I am trying to find an answer about is why do we need to > > > > > > defer tee-supplicant launch if it's bundled into initrd? Once you > > > > > > detect OP-TEE then tee-supplicant should be launched unconditionally. > > > > > > As per your example below, the motivation here seems to be the TPM2 > > > > > > device dependent on RPMB backend but what if other future systemd > > > > > > services come up and depend on other services offered by > > > > > > tee-supplicant? > > > > > > > > > > There is an annoying depedency between firmware side optee and TAs, and kernel optee driver, > > > > > tee-supplicant in userspace and kernel TA drivers like fTPM. > > > > > > > > > > Kernel fTPM driver and fTPM TA require tee-supplicant in userspace for RPMB, RPC etc. > > > > > > > > > > This patch series is adding kernel side support for RPMB handling so that the dependency to > > > > > tee-supplicant in userspace can be removed. For fTPM use case, there is still the optee RPC > > > > > buffer setup which currently requires tee-supplicant in userspace or fTPM TA will panic. > > > > > > > > > > So yes, currently, tee-supplicant must be started. But it would be great if kernel drivers > > > > > and firmware optee trusted applications would not depend on tee-supplicant running in userspace. > > > > > The startup sequence is really tricky to get right. My fTPM use case is using the TPM device > > > > > to encrypt rootfs and thus all SW components including tee-supplicant need to run early in > > > > > initramfs. Currently also switch from initramfs to main rootfs requires unloading > > > > > fTPM kernel driver and stopping tee-supplicant in initrd, and then starting tee-supplicant > > > > > and loading fTPM kernel driver from main rootfs. udev and automatic module loading for > > > > > fTPM can not be used due to the tee-supplicant userspace dependency. > > > > > > > > I decided to build fTPM as buildin-TA into OP-TEE. RPMB routing is already > > > > implemented in u-boot so it can already write PCR registers. > > > > > > Is build in TA same as early TA? I presume so. > > > > Indeed.. sorry for using the wrong term. > > Ok, no problem. Then we have the same fTPM TA setup. I'm using optee 4.1 > with RPMB kernel support changes from Jens cherry-picked on top. > > > > > With this series and the required changes in OP-TEE and a compiled in fTPM > > > > kernel driver and systemd v256 it is possible to use the fTPM in the initrd > > > > without tee-supplicant. > > > > > > > > Maybe this information is helpful to you, regards > > > > > > This is very interesting and I'm trying to get to the same state, though with > > > fTPM kernel driver as module. With v6 of this patch set and matching optee changes > > > I was not able to make this work as fTPM TA was crashing when loading ftpm kernel driver > > > due to failing RPC allocation, which tee-supplicant was setting up in the whole chain. > > > I'll try to get v7 patches working and test this again on my yocto based setup and kernel 6.6.y. > > > > I'll try today also with v7 and 6.10-rc1 on an i.MX8MM. It should also > > work with fTPM as kernel module if you use systemd in the initrd > > with the new tpm.target in systemd v256. > > Thanks for the details. I'm testing on qemu, rockpi4b (Rockchip rk3399 SoC) and synquacer > (Socionext Developer Box, SC2A11:Cortex-A53 MPCore 24cores). Kernel and rootfs > are from our yocto master branch based Trusted Reference Stack distro > ( https://gitlab.com/Linaro/trusted-reference-stack/trs ) > with kernel 6.6.29 (porting the RPMB v7 patches currently), systemd 255.4 (tpm2.target > backported), tee-supplicant 4.1 etc. I'm switching the initramfs from shell scripts > to systemd currently, but running into various issues. I just use a mkosi generated Debian/sid image.. > UEFI firmware is our Trusted Substrate ( https://gitlab.com/Linaro/trustedsubstrate/meta-ts/ ) This is a cool project! I was not aware of it. Thanks for sharing. > ARM System Ready IR compatible with secure boot and TPM support, u-boot > 2024.04 (except rockpi4b still on 2023.01), optee 4.1, fTPM etc from meta-arm > yocto layer. I am on a Toradex Verdin board with an i.MX8MM SoM. u-boot is still 2024.01, optee_os from Jens referenced branch, with a little change in: lib/libutee/include/user_ta_header.h -#define TA_FLAGS_MASK GENMASK_32(10, 0) +#define TA_FLAGS_MASK GENMASK_32(12, 0) fTPM is from ms-tpm-20-ref.git on github. Need to check what is in the meta-arm. Figured out some problems with this regarding OrPolicies used by systemd-cryptenroll.. > Booting without tee-supplicant has so far only resulted in the fTPM TA panic'ing > because RPC setup is failing. Also the fTPM TA enumation needs to be changed > from current yocto defaults to always discoverable if there is no tee-supplicant: > https://git.yoctoproject.org/meta-arm/tree/meta-arm/recipes-security/optee-ftpm/optee-ftpm/0001-add-enum-to-ta-flags.patch Ah, seems to be the same change than above, just limited to the fTPM TA? Shouldn't it be part of optee_os since it is a capability of it? > I hope to get v7 of these patches into testing today. Was able to test it. But ended also in TA panic. Will share the details in another mail. Regards Manuel
On 14:13 Mon 27 May , Jens Wiklander wrote: > --- a/drivers/tee/optee/ffa_abi.c > +++ b/drivers/tee/optee/ffa_abi.c > @@ -7,6 +7,7 @@ > > #include <linux/arm_ffa.h> > #include <linux/errno.h> > +#include <linux/rpmb.h> > #include <linux/scatterlist.h> > #include <linux/sched.h> > #include <linux/slab.h> > @@ -903,6 +904,10 @@ static int optee_ffa_probe(struct ffa_device *ffa_dev) > optee->ffa.bottom_half_value = U32_MAX; > optee->rpc_param_count = rpc_param_count; > > + if (IS_REACHABLE(CONFIG_RPMB) && > + (sec_caps & OPTEE_FFA_SEC_CAP_RPMB_PROBE)) > + optee->in_kernel_rpmb_routing = true; The SEC_CAP_RPMB_PROBE flag seems to be missing in optee_os at the moment. If I remove this check here, the series works for me. Cheers Manuel
Hi Manuel, On Mon, Jun 3, 2024 at 11:10 AM Manuel Traut <manut@mecka.net> wrote: > > On 14:13 Mon 27 May , Jens Wiklander wrote: > > --- a/drivers/tee/optee/ffa_abi.c > > +++ b/drivers/tee/optee/ffa_abi.c > > @@ -7,6 +7,7 @@ > > > > #include <linux/arm_ffa.h> > > #include <linux/errno.h> > > +#include <linux/rpmb.h> > > #include <linux/scatterlist.h> > > #include <linux/sched.h> > > #include <linux/slab.h> > > @@ -903,6 +904,10 @@ static int optee_ffa_probe(struct ffa_device *ffa_dev) > > optee->ffa.bottom_half_value = U32_MAX; > > optee->rpc_param_count = rpc_param_count; > > > > + if (IS_REACHABLE(CONFIG_RPMB) && > > + (sec_caps & OPTEE_FFA_SEC_CAP_RPMB_PROBE)) > > + optee->in_kernel_rpmb_routing = true; > > The SEC_CAP_RPMB_PROBE flag seems to be missing in optee_os at the moment. > If I remove this check here, the series works for me. You're right, I missed pushing those flags to optee_os. I've pushed them now. Cheers, Jens
Hi, On Mon, Jun 10, 2024 at 02:52:31PM +0200, Jens Wiklander wrote: > Hi Manuel, > > On Mon, Jun 3, 2024 at 11:10 AM Manuel Traut <manut@mecka.net> wrote: > > > > On 14:13 Mon 27 May , Jens Wiklander wrote: > > > --- a/drivers/tee/optee/ffa_abi.c > > > +++ b/drivers/tee/optee/ffa_abi.c > > > @@ -7,6 +7,7 @@ > > > > > > #include <linux/arm_ffa.h> > > > #include <linux/errno.h> > > > +#include <linux/rpmb.h> > > > #include <linux/scatterlist.h> > > > #include <linux/sched.h> > > > #include <linux/slab.h> > > > @@ -903,6 +904,10 @@ static int optee_ffa_probe(struct ffa_device *ffa_dev) > > > optee->ffa.bottom_half_value = U32_MAX; > > > optee->rpc_param_count = rpc_param_count; > > > > > > + if (IS_REACHABLE(CONFIG_RPMB) && > > > + (sec_caps & OPTEE_FFA_SEC_CAP_RPMB_PROBE)) > > > + optee->in_kernel_rpmb_routing = true; > > > > The SEC_CAP_RPMB_PROBE flag seems to be missing in optee_os at the moment. > > If I remove this check here, the series works for me. > > You're right, I missed pushing those flags to optee_os. I've pushed them now. Thanks! Tested with optee 4.1 and your patches from https://github.com/jenswi-linaro/optee_os/commits/rpmb_probe_v7/ in Trusted Substrate uefi firmware ( https://gitlab.com/Linaro/trustedsubstrate/meta-ts/ ) and this series and a bunch of dependencies backported to our Trusted Reference Stack ( https://trs.readthedocs.io/en/latest/ ) 6.6.29 kernel on rockpi4b (rk3399 ARM64 SoC) with secure boot and the optee side fTPM TA device used to create an encrypted rootfs with systemd. Kernel side RPMB routing is in use and works for the TPM use cases. Full boot and test log (with unrelated test failures) https://ledge.validation.linaro.org/scheduler/job/88692 root@trs-qemuarm64:~# cat /sys/class/tee/tee0/rpmb_routing_model ... kernel Tested-by: Mikko Rapeli <mikko.rapeli@linaro.org> Cheers, -Mikko
On Tue, 11 Jun 2024 at 08:32, Mikko Rapeli <mikko.rapeli@linaro.org> wrote: > > Hi, > > On Mon, Jun 10, 2024 at 02:52:31PM +0200, Jens Wiklander wrote: > > Hi Manuel, > > > > On Mon, Jun 3, 2024 at 11:10 AM Manuel Traut <manut@mecka.net> wrote: > > > > > > On 14:13 Mon 27 May , Jens Wiklander wrote: > > > > --- a/drivers/tee/optee/ffa_abi.c > > > > +++ b/drivers/tee/optee/ffa_abi.c > > > > @@ -7,6 +7,7 @@ > > > > > > > > #include <linux/arm_ffa.h> > > > > #include <linux/errno.h> > > > > +#include <linux/rpmb.h> > > > > #include <linux/scatterlist.h> > > > > #include <linux/sched.h> > > > > #include <linux/slab.h> > > > > @@ -903,6 +904,10 @@ static int optee_ffa_probe(struct ffa_device *ffa_dev) > > > > optee->ffa.bottom_half_value = U32_MAX; > > > > optee->rpc_param_count = rpc_param_count; > > > > > > > > + if (IS_REACHABLE(CONFIG_RPMB) && > > > > + (sec_caps & OPTEE_FFA_SEC_CAP_RPMB_PROBE)) > > > > + optee->in_kernel_rpmb_routing = true; > > > > > > The SEC_CAP_RPMB_PROBE flag seems to be missing in optee_os at the moment. > > > If I remove this check here, the series works for me. > > > > You're right, I missed pushing those flags to optee_os. I've pushed them now. > > Thanks! Tested with optee 4.1 and your patches from > https://github.com/jenswi-linaro/optee_os/commits/rpmb_probe_v7/ > in Trusted Substrate uefi firmware > ( https://gitlab.com/Linaro/trustedsubstrate/meta-ts/ ) > and this series and a bunch of dependencies backported to > our Trusted Reference Stack > ( https://trs.readthedocs.io/en/latest/ ) > 6.6.29 kernel on rockpi4b (rk3399 ARM64 SoC) with secure boot and > the optee side fTPM TA device used to create an encrypted rootfs with > systemd. Kernel side RPMB routing is in use and works for the TPM use cases. > Glad to see that you can get fTPM to work without tee-supplicant after this patch-set. > Full boot and test log (with unrelated test failures) > https://ledge.validation.linaro.org/scheduler/job/88692 > > root@trs-qemuarm64:~# cat /sys/class/tee/tee0/rpmb_routing_model > ... > kernel So coming back to the real question, do we really need this new rpmb_routing_model ABI? Did systemd still need it with no tee-supplicant dependency? IMHO, a user-space ABI requires use-case justification otherwise it's just going to add on maintenance burden. -Sumit > > Tested-by: Mikko Rapeli <mikko.rapeli@linaro.org> > > Cheers, > > -Mikko
Hi, Adding TPM maintainers and linux-integrity since discussion relates to firmware TPM driver tpm_ftpm_tee On Tue, Jun 11, 2024 at 04:13:21PM +0530, Sumit Garg wrote: > On Tue, 11 Jun 2024 at 08:32, Mikko Rapeli <mikko.rapeli@linaro.org> wrote: > > > > Hi, > > > > On Mon, Jun 10, 2024 at 02:52:31PM +0200, Jens Wiklander wrote: > > > Hi Manuel, > > > > > > On Mon, Jun 3, 2024 at 11:10 AM Manuel Traut <manut@mecka.net> wrote: > > > > > > > > On 14:13 Mon 27 May , Jens Wiklander wrote: > > > > > --- a/drivers/tee/optee/ffa_abi.c > > > > > +++ b/drivers/tee/optee/ffa_abi.c > > > > > @@ -7,6 +7,7 @@ > > > > > > > > > > #include <linux/arm_ffa.h> > > > > > #include <linux/errno.h> > > > > > +#include <linux/rpmb.h> > > > > > #include <linux/scatterlist.h> > > > > > #include <linux/sched.h> > > > > > #include <linux/slab.h> > > > > > @@ -903,6 +904,10 @@ static int optee_ffa_probe(struct ffa_device *ffa_dev) > > > > > optee->ffa.bottom_half_value = U32_MAX; > > > > > optee->rpc_param_count = rpc_param_count; > > > > > > > > > > + if (IS_REACHABLE(CONFIG_RPMB) && > > > > > + (sec_caps & OPTEE_FFA_SEC_CAP_RPMB_PROBE)) > > > > > + optee->in_kernel_rpmb_routing = true; > > > > > > > > The SEC_CAP_RPMB_PROBE flag seems to be missing in optee_os at the moment. > > > > If I remove this check here, the series works for me. > > > > > > You're right, I missed pushing those flags to optee_os. I've pushed them now. > > > > Thanks! Tested with optee 4.1 and your patches from > > https://github.com/jenswi-linaro/optee_os/commits/rpmb_probe_v7/ > > in Trusted Substrate uefi firmware > > ( https://gitlab.com/Linaro/trustedsubstrate/meta-ts/ ) > > and this series and a bunch of dependencies backported to > > our Trusted Reference Stack > > ( https://trs.readthedocs.io/en/latest/ ) > > 6.6.29 kernel on rockpi4b (rk3399 ARM64 SoC) with secure boot and > > the optee side fTPM TA device used to create an encrypted rootfs with > > systemd. Kernel side RPMB routing is in use and works for the TPM use cases. > > > > Glad to see that you can get fTPM to work without tee-supplicant after > this patch-set. Sorry but the fTPM TA only works with tee-supplicant in userspace. It's needed for RPC setup. For RPMB it is not needed or used with these patches applied. > > Full boot and test log (with unrelated test failures) > > https://ledge.validation.linaro.org/scheduler/job/88692 > > > > root@trs-qemuarm64:~# cat /sys/class/tee/tee0/rpmb_routing_model > > ... > > kernel > > So coming back to the real question, do we really need this new > rpmb_routing_model ABI? Did systemd still need it with no > tee-supplicant dependency? IMHO, a user-space ABI requires use-case > justification otherwise it's just going to add on maintenance burden. Currently it is not needed, because tee-supplicant is still required to setup RPC with fTPM. If the RPC setup were also done in kernel directly and tee-supplicant need is removed, then this kind of ABI is important so that userspace init knows if it needs to queue startup of tee-supplicant or not. On a related note, the kernel tpm_ftpm_tee driver for fTPM TA really has a hard dependency to tee-supplicant in userspace. If tee-supplicant is stopped, restarted etc without unloading the kernel module (or otherwise disabling the TPM device), then all TPM device actions done without tee-supplicant running will fail ane keep failing until next reboot. The kernel driver is not crashing but all functionality breaks. The availability of tpm_ftpm_tee should be tied much harder to the tee-supplicant running in userspace, e.g. optee should be in charge to start and bring tpm_ftpm_tee down based on tee-supplicant userspace daemon availability. Or the needed tee-supplicant code should be moved to kernel side. Currently systemd side init scripts have issues switching from initrd to main rootfs since they need to disable tpm_ftpm_tee driver, built in or a module, before shutting down tee-supplicant. A suspend or other inactive state in the ftpm driver needs to be triggered, which AFAIK is not currently possible, at least from userspace (I'd happy be proven wrong here). An alternative for tpm_fptm_tee driver is to use optee APIs so that the calls wait for tee-supplicant in userspace if needed: --- a/drivers/char/tpm/tpm_ftpm_tee.c +++ b/drivers/char/tpm/tpm_ftpm_tee.c @@ -237,6 +237,9 @@ static int ftpm_tee_probe(struct device *dev) return PTR_ERR(pvt_data->ctx); } + /* wait for tee-supplicant in userspace, fTPM TA really depends on it */ + pvt_data->ctx->supp_nowait = false; + /* Open a session with fTPM TA */ memset(&sess_arg, 0, sizeof(sess_arg)); export_uuid(sess_arg.uuid, &ftpm_ta_uuid); This works pretty well for the tee-supplicant initrd to main rootfs switch but currently breaks for example reboot (just hangs), and Jens doesn't approve of this as a real solution. So as an alternative, userspace needs to be very careful in initrd and rootfs to start tee-supplicant earlier than loading tpm_ftpm_tee driver which can only be supported as module and removed before shutting down tee-supplicant. In other use cases, TPM drivers are only supported if driver is built into the kernel (or ACPI table entry for a TPM device exists) which I'm trying to change with [PATCH] efi: expose TPM event log to userspace via sysfs https://lore.kernel.org/lkml/20240422112711.362779-1-mikko.rapeli@linaro.org/ where userspace init can check if it should wait longer for the tpm device to appear, e.g. let udev load optee etc drivers which eventually start also tee-supplicant and thus load tpm_ftpm_tee driver (fTPM TA enumration is tied to tee-supplicant in userspace https://git.yoctoproject.org/meta-arm/tree/meta-arm/recipes-security/optee-ftpm/optee-ftpm/0001-add-enum-to-ta-flags.patch ) Cheers, -Mikko
On Wed, Jun 12, 2024 at 3:14 AM Mikko Rapeli <mikko.rapeli@linaro.org> wrote: > > Hi, > > Adding TPM maintainers and linux-integrity since discussion relates to firmware TPM > driver tpm_ftpm_tee > > On Tue, Jun 11, 2024 at 04:13:21PM +0530, Sumit Garg wrote: > > On Tue, 11 Jun 2024 at 08:32, Mikko Rapeli <mikko.rapeli@linaro.org> wrote: > > > > > > Hi, > > > > > > On Mon, Jun 10, 2024 at 02:52:31PM +0200, Jens Wiklander wrote: > > > > Hi Manuel, > > > > > > > > On Mon, Jun 3, 2024 at 11:10 AM Manuel Traut <manut@mecka.net> wrote: > > > > > > > > > > On 14:13 Mon 27 May , Jens Wiklander wrote: > > > > > > --- a/drivers/tee/optee/ffa_abi.c > > > > > > +++ b/drivers/tee/optee/ffa_abi.c > > > > > > @@ -7,6 +7,7 @@ > > > > > > > > > > > > #include <linux/arm_ffa.h> > > > > > > #include <linux/errno.h> > > > > > > +#include <linux/rpmb.h> > > > > > > #include <linux/scatterlist.h> > > > > > > #include <linux/sched.h> > > > > > > #include <linux/slab.h> > > > > > > @@ -903,6 +904,10 @@ static int optee_ffa_probe(struct ffa_device *ffa_dev) > > > > > > optee->ffa.bottom_half_value = U32_MAX; > > > > > > optee->rpc_param_count = rpc_param_count; > > > > > > > > > > > > + if (IS_REACHABLE(CONFIG_RPMB) && > > > > > > + (sec_caps & OPTEE_FFA_SEC_CAP_RPMB_PROBE)) > > > > > > + optee->in_kernel_rpmb_routing = true; > > > > > > > > > > The SEC_CAP_RPMB_PROBE flag seems to be missing in optee_os at the moment. > > > > > If I remove this check here, the series works for me. > > > > > > > > You're right, I missed pushing those flags to optee_os. I've pushed them now. > > > > > > Thanks! Tested with optee 4.1 and your patches from > > > https://github.com/jenswi-linaro/optee_os/commits/rpmb_probe_v7/ > > > in Trusted Substrate uefi firmware > > > ( https://gitlab.com/Linaro/trustedsubstrate/meta-ts/ ) > > > and this series and a bunch of dependencies backported to > > > our Trusted Reference Stack > > > ( https://trs.readthedocs.io/en/latest/ ) > > > 6.6.29 kernel on rockpi4b (rk3399 ARM64 SoC) with secure boot and > > > the optee side fTPM TA device used to create an encrypted rootfs with > > > systemd. Kernel side RPMB routing is in use and works for the TPM use cases. > > > > > > > Glad to see that you can get fTPM to work without tee-supplicant after > > this patch-set. > > Sorry but the fTPM TA only works with tee-supplicant in userspace. It's needed > for RPC setup. For RPMB it is not needed or used with these patches applied. I've never been able to find out what fTPM is trying to do with tee-supplicant at this stage. I guess the RPC is a shared memory allocation preparing for another request. > > > > Full boot and test log (with unrelated test failures) > > > https://ledge.validation.linaro.org/scheduler/job/88692 > > > > > > root@trs-qemuarm64:~# cat /sys/class/tee/tee0/rpmb_routing_model > > > ... > > > kernel > > > > So coming back to the real question, do we really need this new > > rpmb_routing_model ABI? Did systemd still need it with no > > tee-supplicant dependency? IMHO, a user-space ABI requires use-case > > justification otherwise it's just going to add on maintenance burden. > > Currently it is not needed, because tee-supplicant is still required to > setup RPC with fTPM. If the RPC setup were also done in kernel directly and > tee-supplicant need is removed, then this kind of ABI is important so that > userspace init knows if it needs to queue startup of tee-supplicant or not. > > On a related note, the kernel tpm_ftpm_tee driver for fTPM TA really has > a hard dependency to tee-supplicant in userspace. If tee-supplicant is stopped, > restarted etc without unloading the kernel module (or otherwise disabling the TPM device), > then all TPM device actions done without tee-supplicant running will fail ane keep > failing until next reboot. The kernel driver is not crashing but all functionality > breaks. > > The availability of tpm_ftpm_tee should be tied much harder to the tee-supplicant > running in userspace, e.g. optee should be in charge to start and bring tpm_ftpm_tee down > based on tee-supplicant userspace daemon availability. Or the needed tee-supplicant code > should be moved to kernel side. Currently systemd side init scripts have issues switching > from initrd to main rootfs since they need to disable tpm_ftpm_tee driver, built in or a module, > before shutting down tee-supplicant. A suspend or other inactive state in the ftpm driver > needs to be triggered, which AFAIK is not currently possible, at least from userspace > (I'd happy be proven wrong here). > > An alternative for tpm_fptm_tee driver is to use optee APIs so that the calls > wait for tee-supplicant in userspace if needed: > > --- a/drivers/char/tpm/tpm_ftpm_tee.c > +++ b/drivers/char/tpm/tpm_ftpm_tee.c > @@ -237,6 +237,9 @@ static int ftpm_tee_probe(struct device *dev) > return PTR_ERR(pvt_data->ctx); > } > > + /* wait for tee-supplicant in userspace, fTPM TA really depends on it */ > + pvt_data->ctx->supp_nowait = false; > + > /* Open a session with fTPM TA */ > memset(&sess_arg, 0, sizeof(sess_arg)); > export_uuid(sess_arg.uuid, &ftpm_ta_uuid); > > This works pretty well for the tee-supplicant initrd to main rootfs switch but currently > breaks for example reboot (just hangs), and Jens doesn't approve of this as a > real solution. Yes, the hang part is my main concern. > > So as an alternative, userspace needs to be very careful in initrd and rootfs > to start tee-supplicant earlier than loading tpm_ftpm_tee driver which can > only be supported as module and removed before shutting down tee-supplicant. Unbind/bind via sysfs might be an option. But that's still only a workaround since getting rid of the tee-supplicant dependency in initrd should avoid the problem entirely. Cheers, Jens > In other use cases, TPM drivers are only supported if driver is built into > the kernel (or ACPI table entry for a TPM device exists) which I'm trying > to change with > > [PATCH] efi: expose TPM event log to userspace via sysfs > > https://lore.kernel.org/lkml/20240422112711.362779-1-mikko.rapeli@linaro.org/ > > where userspace init can check if it should wait longer for the tpm device to appear, > e.g. let udev load optee etc drivers which eventually start also tee-supplicant and > thus load tpm_ftpm_tee driver (fTPM TA enumration is tied to tee-supplicant in userspace > https://git.yoctoproject.org/meta-arm/tree/meta-arm/recipes-security/optee-ftpm/optee-ftpm/0001-add-enum-to-ta-flags.patch ) > > Cheers, > > -Mikko
diff --git a/Documentation/ABI/testing/sysfs-class-tee b/Documentation/ABI/testing/sysfs-class-tee new file mode 100644 index 000000000000..c9144d16003e --- /dev/null +++ b/Documentation/ABI/testing/sysfs-class-tee @@ -0,0 +1,15 @@ +What: /sys/class/tee/tee{,priv}X/rpmb_routing_model +Date: May 2024 +KernelVersion: 6.10 +Contact: op-tee@lists.trustedfirmware.org +Description: + RPMB frames can be routed to the RPMB device via the + user-space daemon tee-supplicant or the RPMB subsystem + in the kernel. The value "user" means that the driver + will route the RPMB frames via user space. Conversely, + "kernel" means that the frames are routed via the RPMB + subsystem without assistance from tee-supplicant. It + should be assumed that RPMB frames are routed via user + space if the variable is absent. The primary purpose + of this variable is to let systemd know whether + tee-supplicant is needed in the early boot with initramfs. diff --git a/MAINTAINERS b/MAINTAINERS index 4c671827a08b..0d0bc01fd3eb 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -21709,6 +21709,7 @@ M: Jens Wiklander <jens.wiklander@linaro.org> R: Sumit Garg <sumit.garg@linaro.org> L: op-tee@lists.trustedfirmware.org S: Maintained +F: Documentation/ABI/testing/sysfs-class-tee F: Documentation/driver-api/tee.rst F: Documentation/tee/ F: Documentation/userspace-api/tee.rst diff --git a/drivers/tee/optee/core.c b/drivers/tee/optee/core.c index 3aed554bc8d8..3194c071a175 100644 --- a/drivers/tee/optee/core.c +++ b/drivers/tee/optee/core.c @@ -11,12 +11,28 @@ #include <linux/io.h> #include <linux/mm.h> #include <linux/module.h> +#include <linux/rpmb.h> #include <linux/slab.h> #include <linux/string.h> #include <linux/tee_drv.h> #include <linux/types.h> #include "optee_private.h" +struct blocking_notifier_head optee_rpmb_intf_added = + BLOCKING_NOTIFIER_INIT(optee_rpmb_intf_added); + +static int rpmb_add_dev(struct device *dev) +{ + blocking_notifier_call_chain(&optee_rpmb_intf_added, 0, + to_rpmb_dev(dev)); + + return 0; +} + +static struct class_interface rpmb_class_intf = { + .add_dev = rpmb_add_dev, +}; + int optee_pool_op_alloc_helper(struct tee_shm_pool *pool, struct tee_shm *shm, size_t size, size_t align, int (*shm_register)(struct tee_context *ctx, @@ -80,11 +96,63 @@ void optee_pool_op_free_helper(struct tee_shm_pool *pool, struct tee_shm *shm, shm->pages = NULL; } +void optee_bus_scan_rpmb(struct work_struct *work) +{ + struct optee *optee = container_of(work, struct optee, + rpmb_scan_bus_work); + int ret; + + if (!optee->rpmb_scan_bus_done) { + ret = optee_enumerate_devices(PTA_CMD_GET_DEVICES_RPMB); + optee->rpmb_scan_bus_done = !ret; + if (ret && ret != -ENODEV) + pr_info("Scanning for RPMB device: ret %d\n", ret); + } +} + +int optee_rpmb_intf_rdev(struct notifier_block *intf, unsigned long action, + void *data) +{ + struct optee *optee = container_of(intf, struct optee, rpmb_intf); + + schedule_work(&optee->rpmb_scan_bus_work); + + return 0; +} + static void optee_bus_scan(struct work_struct *work) { WARN_ON(optee_enumerate_devices(PTA_CMD_GET_DEVICES_SUPP)); } +static ssize_t rpmb_routing_model_show(struct device *dev, + struct device_attribute *attr, char *buf) +{ + struct optee *optee = dev_get_drvdata(dev); + const char *s; + + if (optee->in_kernel_rpmb_routing) + s = "kernel"; + else + s = "user"; + + return scnprintf(buf, PAGE_SIZE, "%s\n", s); +} +static DEVICE_ATTR_RO(rpmb_routing_model); + +static struct attribute *optee_dev_attrs[] = { + &dev_attr_rpmb_routing_model.attr, + NULL +}; + +ATTRIBUTE_GROUPS(optee_dev); + +void optee_set_dev_group(struct optee *optee) +{ + tee_device_set_dev_groups(optee->teedev, optee_dev_groups); + tee_device_set_dev_groups(optee->supp_teedev, optee_dev_groups); +} + int optee_open(struct tee_context *ctx, bool cap_memref_null) { struct optee_context_data *ctxdata; @@ -161,6 +229,9 @@ void optee_release_supp(struct tee_context *ctx) void optee_remove_common(struct optee *optee) { + blocking_notifier_chain_unregister(&optee_rpmb_intf_added, + &optee->rpmb_intf); + cancel_work_sync(&optee->rpmb_scan_bus_work); /* Unregister OP-TEE specific client devices on TEE bus */ optee_unregister_devices(); @@ -177,13 +248,18 @@ void optee_remove_common(struct optee *optee) tee_shm_pool_free(optee->pool); optee_supp_uninit(&optee->supp); mutex_destroy(&optee->call_queue.mutex); + rpmb_dev_put(optee->rpmb_dev); + mutex_destroy(&optee->rpmb_dev_mutex); } static int smc_abi_rc; static int ffa_abi_rc; +static bool intf_is_regged; static int __init optee_core_init(void) { + int rc; + /* * The kernel may have crashed at the same time that all available * secure world threads were suspended and we cannot reschedule the @@ -194,18 +270,36 @@ static int __init optee_core_init(void) if (is_kdump_kernel()) return -ENODEV; + if (IS_ENABLED(CONFIG_RPMB)) { + rc = rpmb_interface_register(&rpmb_class_intf); + if (rc) + return rc; + intf_is_regged = true; + } + smc_abi_rc = optee_smc_abi_register(); ffa_abi_rc = optee_ffa_abi_register(); /* If both failed there's no point with this module */ - if (smc_abi_rc && ffa_abi_rc) + if (smc_abi_rc && ffa_abi_rc) { + if (IS_ENABLED(CONFIG_RPMB)) { + rpmb_interface_unregister(&rpmb_class_intf); + intf_is_regged = false; + } return smc_abi_rc; + } + return 0; } module_init(optee_core_init); static void __exit optee_core_exit(void) { + if (IS_ENABLED(CONFIG_RPMB) && intf_is_regged) { + rpmb_interface_unregister(&rpmb_class_intf); + intf_is_regged = false; + } + if (!smc_abi_rc) optee_smc_abi_unregister(); if (!ffa_abi_rc) diff --git a/drivers/tee/optee/device.c b/drivers/tee/optee/device.c index 1892e49a8e6a..ff26850f704f 100644 --- a/drivers/tee/optee/device.c +++ b/drivers/tee/optee/device.c @@ -43,6 +43,13 @@ static int get_devices(struct tee_context *ctx, u32 session, ret = tee_client_invoke_func(ctx, &inv_arg, param); if ((ret < 0) || ((inv_arg.ret != TEEC_SUCCESS) && (inv_arg.ret != TEEC_ERROR_SHORT_BUFFER))) { + /* + * TEE_ERROR_STORAGE_NOT_AVAILABLE is returned when getting + * the list of device TAs that depends on RPMB but a usable + * RPMB device isn't found. + */ + if (inv_arg.ret == TEE_ERROR_STORAGE_NOT_AVAILABLE) + return -ENODEV; pr_err("PTA_CMD_GET_DEVICES invoke function err: %x\n", inv_arg.ret); return -EINVAL; diff --git a/drivers/tee/optee/ffa_abi.c b/drivers/tee/optee/ffa_abi.c index ecb5eb079408..b3b87e49f7fb 100644 --- a/drivers/tee/optee/ffa_abi.c +++ b/drivers/tee/optee/ffa_abi.c @@ -7,6 +7,7 @@ #include <linux/arm_ffa.h> #include <linux/errno.h> +#include <linux/rpmb.h> #include <linux/scatterlist.h> #include <linux/sched.h> #include <linux/slab.h> @@ -903,6 +904,10 @@ static int optee_ffa_probe(struct ffa_device *ffa_dev) optee->ffa.bottom_half_value = U32_MAX; optee->rpc_param_count = rpc_param_count; + if (IS_REACHABLE(CONFIG_RPMB) && + (sec_caps & OPTEE_FFA_SEC_CAP_RPMB_PROBE)) + optee->in_kernel_rpmb_routing = true; + teedev = tee_device_alloc(&optee_ffa_clnt_desc, NULL, optee->pool, optee); if (IS_ERR(teedev)) { @@ -919,6 +924,8 @@ static int optee_ffa_probe(struct ffa_device *ffa_dev) } optee->supp_teedev = teedev; + optee_set_dev_group(optee); + rc = tee_device_register(optee->teedev); if (rc) goto err_unreg_supp_teedev; @@ -934,6 +941,7 @@ static int optee_ffa_probe(struct ffa_device *ffa_dev) optee_cq_init(&optee->call_queue, 0); optee_supp_init(&optee->supp); optee_shm_arg_cache_init(optee, arg_cache_flags); + mutex_init(&optee->rpmb_dev_mutex); ffa_dev_set_drvdata(ffa_dev, optee); ctx = teedev_open(optee->teedev); if (IS_ERR(ctx)) { @@ -955,6 +963,10 @@ static int optee_ffa_probe(struct ffa_device *ffa_dev) if (rc) goto err_unregister_devices; + INIT_WORK(&optee->rpmb_scan_bus_work, optee_bus_scan_rpmb); + optee->rpmb_intf.notifier_call = optee_rpmb_intf_rdev; + blocking_notifier_chain_register(&optee_rpmb_intf_added, + &optee->rpmb_intf); pr_info("initialized driver\n"); return 0; @@ -968,6 +980,8 @@ static int optee_ffa_probe(struct ffa_device *ffa_dev) teedev_close_context(ctx); err_rhashtable_free: rhashtable_free_and_destroy(&optee->ffa.global_ids, rh_free_fn, NULL); + rpmb_dev_put(optee->rpmb_dev); + mutex_destroy(&optee->rpmb_dev_mutex); optee_supp_uninit(&optee->supp); mutex_destroy(&optee->call_queue.mutex); mutex_destroy(&optee->ffa.mutex); diff --git a/drivers/tee/optee/optee_ffa.h b/drivers/tee/optee/optee_ffa.h index 5db779dc00de..257735ae5b56 100644 --- a/drivers/tee/optee/optee_ffa.h +++ b/drivers/tee/optee/optee_ffa.h @@ -92,6 +92,8 @@ #define OPTEE_FFA_SEC_CAP_ARG_OFFSET BIT(0) /* OP-TEE supports asynchronous notification via FF-A */ #define OPTEE_FFA_SEC_CAP_ASYNC_NOTIF BIT(1) +/* OP-TEE supports probing for RPMB device if needed */ +#define OPTEE_FFA_SEC_CAP_RPMB_PROBE BIT(2) #define OPTEE_FFA_EXCHANGE_CAPABILITIES OPTEE_FFA_BLOCKING_CALL(2) diff --git a/drivers/tee/optee/optee_private.h b/drivers/tee/optee/optee_private.h index 7a5243c78b55..1a41d4736bf8 100644 --- a/drivers/tee/optee/optee_private.h +++ b/drivers/tee/optee/optee_private.h @@ -7,7 +7,9 @@ #define OPTEE_PRIVATE_H #include <linux/arm-smccc.h> +#include <linux/notifier.h> #include <linux/rhashtable.h> +#include <linux/rpmb.h> #include <linux/semaphore.h> #include <linux/tee_drv.h> #include <linux/types.h> @@ -20,11 +22,13 @@ /* Some Global Platform error codes used in this driver */ #define TEEC_SUCCESS 0x00000000 #define TEEC_ERROR_BAD_PARAMETERS 0xFFFF0006 +#define TEEC_ERROR_ITEM_NOT_FOUND 0xFFFF0008 #define TEEC_ERROR_NOT_SUPPORTED 0xFFFF000A #define TEEC_ERROR_COMMUNICATION 0xFFFF000E #define TEEC_ERROR_OUT_OF_MEMORY 0xFFFF000C #define TEEC_ERROR_BUSY 0xFFFF000D #define TEEC_ERROR_SHORT_BUFFER 0xFFFF0010 +#define TEE_ERROR_STORAGE_NOT_AVAILABLE 0xF0100003 #define TEEC_ORIGIN_COMMS 0x00000002 @@ -197,6 +201,12 @@ struct optee_ops { * @notif: notification synchronization struct * @supp: supplicant synchronization struct for RPC to supplicant * @pool: shared memory pool + * @mutex: mutex protecting @rpmb_dev + * @rpmb_dev: current RPMB device or NULL + * @rpmb_scan_bus_done flag if device registation of RPMB dependent devices + * was already done + * @rpmb_scan_bus_work workq to for an RPMB device and to scan optee bus + * and register RPMB dependent optee drivers * @rpc_param_count: If > 0 number of RPC parameters to make room for * @scan_bus_done flag if device registation was already done. * @scan_bus_work workq to scan optee bus and register optee drivers @@ -215,9 +225,16 @@ struct optee { struct optee_notif notif; struct optee_supp supp; struct tee_shm_pool *pool; + /* Protects rpmb_dev pointer */ + struct mutex rpmb_dev_mutex; + struct rpmb_dev *rpmb_dev; + struct notifier_block rpmb_intf; unsigned int rpc_param_count; - bool scan_bus_done; + bool scan_bus_done; + bool rpmb_scan_bus_done; + bool in_kernel_rpmb_routing; struct work_struct scan_bus_work; + struct work_struct rpmb_scan_bus_work; }; struct optee_session { @@ -250,6 +267,8 @@ struct optee_call_ctx { size_t num_entries; }; +extern struct blocking_notifier_head optee_rpmb_intf_added; + int optee_notif_init(struct optee *optee, u_int max_key); void optee_notif_uninit(struct optee *optee); int optee_notif_wait(struct optee *optee, u_int key); @@ -280,8 +299,12 @@ int optee_cancel_req(struct tee_context *ctx, u32 cancel_id, u32 session); #define PTA_CMD_GET_DEVICES 0x0 #define PTA_CMD_GET_DEVICES_SUPP 0x1 +#define PTA_CMD_GET_DEVICES_RPMB 0x2 int optee_enumerate_devices(u32 func); void optee_unregister_devices(void); +void optee_bus_scan_rpmb(struct work_struct *work); +int optee_rpmb_intf_rdev(struct notifier_block *intf, unsigned long action, + void *data); int optee_pool_op_alloc_helper(struct tee_shm_pool *pool, struct tee_shm *shm, size_t size, size_t align, @@ -295,6 +318,7 @@ void optee_pool_op_free_helper(struct tee_shm_pool *pool, struct tee_shm *shm, struct tee_shm *shm)); +void optee_set_dev_group(struct optee *optee); void optee_remove_common(struct optee *optee); int optee_open(struct tee_context *ctx, bool cap_memref_null); void optee_release(struct tee_context *ctx); diff --git a/drivers/tee/optee/optee_rpc_cmd.h b/drivers/tee/optee/optee_rpc_cmd.h index f3f06e0994a7..4a3c02914f9c 100644 --- a/drivers/tee/optee/optee_rpc_cmd.h +++ b/drivers/tee/optee/optee_rpc_cmd.h @@ -103,4 +103,39 @@ /* I2C master control flags */ #define OPTEE_RPC_I2C_FLAGS_TEN_BIT BIT(0) +/* + * Reset RPMB probing + * + * Releases an eventually already used RPMB devices and starts over searching + * for RPMB devices. Returns the kind of shared memory to use in subsequent + * OPTEE_RPC_CMD_RPMB_PROBE_NEXT and OPTEE_RPC_CMD_RPMB calls. + * + * [out] value[0].a OPTEE_RPC_SHM_TYPE_*, the parameter for + * OPTEE_RPC_CMD_SHM_ALLOC + */ +#define OPTEE_RPC_CMD_RPMB_PROBE_RESET 22 + +/* + * Probe next RPMB device + * + * [out] value[0].a Type of RPMB device, OPTEE_RPC_RPMB_* + * [out] value[0].b EXT CSD-slice 168 "RPMB Size" + * [out] value[0].c EXT CSD-slice 222 "Reliable Write Sector Count" + * [out] memref[1] Buffer with the raw CID + */ +#define OPTEE_RPC_CMD_RPMB_PROBE_NEXT 23 + +/* Type of RPMB device */ +#define OPTEE_RPC_RPMB_EMMC 0 +#define OPTEE_RPC_RPMB_UFS 1 +#define OPTEE_RPC_RPMB_NVME 2 + +/* + * Replay Protected Memory Block access + * + * [in] memref[0] Frames to device + * [out] memref[1] Frames from device + */ +#define OPTEE_RPC_CMD_RPMB_FRAMES 24 + #endif /*__OPTEE_RPC_CMD_H*/ diff --git a/drivers/tee/optee/optee_smc.h b/drivers/tee/optee/optee_smc.h index 7d9fa426505b..879426300821 100644 --- a/drivers/tee/optee/optee_smc.h +++ b/drivers/tee/optee/optee_smc.h @@ -278,6 +278,8 @@ struct optee_smc_get_shm_config_result { #define OPTEE_SMC_SEC_CAP_ASYNC_NOTIF BIT(5) /* Secure world supports pre-allocating RPC arg struct */ #define OPTEE_SMC_SEC_CAP_RPC_ARG BIT(6) +/* Secure world supports probing for RPMB device if needed */ +#define OPTEE_SMC_SEC_CAP_RPMB_PROBE BIT(7) #define OPTEE_SMC_FUNCID_EXCHANGE_CAPABILITIES 9 #define OPTEE_SMC_EXCHANGE_CAPABILITIES \ diff --git a/drivers/tee/optee/rpc.c b/drivers/tee/optee/rpc.c index e69bc6380683..cf6a4b97549c 100644 --- a/drivers/tee/optee/rpc.c +++ b/drivers/tee/optee/rpc.c @@ -7,6 +7,7 @@ #include <linux/delay.h> #include <linux/i2c.h> +#include <linux/rpmb.h> #include <linux/slab.h> #include <linux/tee_drv.h> #include "optee_private.h" @@ -255,6 +256,154 @@ void optee_rpc_cmd_free_suppl(struct tee_context *ctx, struct tee_shm *shm) optee_supp_thrd_req(ctx, OPTEE_RPC_CMD_SHM_FREE, 1, ¶m); } +static void handle_rpc_func_rpmb_probe_reset(struct tee_context *ctx, + struct optee *optee, + struct optee_msg_arg *arg) +{ + struct tee_param params[1]; + + if (arg->num_params != ARRAY_SIZE(params) || + optee->ops->from_msg_param(optee, params, arg->num_params, + arg->params) || + params[0].attr != TEE_IOCTL_PARAM_ATTR_TYPE_VALUE_OUTPUT) { + arg->ret = TEEC_ERROR_BAD_PARAMETERS; + return; + } + + params[0].u.value.a = OPTEE_RPC_SHM_TYPE_KERNEL; + params[0].u.value.b = 0; + params[0].u.value.c = 0; + if (optee->ops->to_msg_param(optee, arg->params, + arg->num_params, params)) { + arg->ret = TEEC_ERROR_BAD_PARAMETERS; + return; + } + + mutex_lock(&optee->rpmb_dev_mutex); + rpmb_dev_put(optee->rpmb_dev); + optee->rpmb_dev = NULL; + mutex_unlock(&optee->rpmb_dev_mutex); + + arg->ret = TEEC_SUCCESS; +} + +static int rpmb_type_to_rpc_type(enum rpmb_type rtype) +{ + switch (rtype) { + case RPMB_TYPE_EMMC: + return OPTEE_RPC_RPMB_EMMC; + case RPMB_TYPE_UFS: + return OPTEE_RPC_RPMB_UFS; + case RPMB_TYPE_NVME: + return OPTEE_RPC_RPMB_NVME; + default: + return -1; + } +} + +static int rpc_rpmb_match(struct device *dev, const void *data) +{ + struct rpmb_dev *rdev = to_rpmb_dev(dev); + + return rpmb_type_to_rpc_type(rdev->descr.type) >= 0; +} + +static void handle_rpc_func_rpmb_probe_next(struct tee_context *ctx, + struct optee *optee, + struct optee_msg_arg *arg) +{ + struct rpmb_dev *rdev; + struct tee_param params[2]; + void *buf; + + if (arg->num_params != ARRAY_SIZE(params) || + optee->ops->from_msg_param(optee, params, arg->num_params, + arg->params) || + params[0].attr != TEE_IOCTL_PARAM_ATTR_TYPE_VALUE_OUTPUT || + params[1].attr != TEE_IOCTL_PARAM_ATTR_TYPE_MEMREF_OUTPUT) { + arg->ret = TEEC_ERROR_BAD_PARAMETERS; + return; + } + buf = tee_shm_get_va(params[1].u.memref.shm, + params[1].u.memref.shm_offs); + if (!buf) { + arg->ret = TEEC_ERROR_BAD_PARAMETERS; + return; + } + + mutex_lock(&optee->rpmb_dev_mutex); + rdev = rpmb_dev_find_device(NULL, optee->rpmb_dev, rpc_rpmb_match); + rpmb_dev_put(optee->rpmb_dev); + optee->rpmb_dev = rdev; + mutex_unlock(&optee->rpmb_dev_mutex); + + if (!rdev) { + arg->ret = TEEC_ERROR_ITEM_NOT_FOUND; + return; + } + + if (params[1].u.memref.size < rdev->descr.dev_id_len) { + arg->ret = TEEC_ERROR_SHORT_BUFFER; + return; + } + memcpy(buf, rdev->descr.dev_id, rdev->descr.dev_id_len); + params[1].u.memref.size = rdev->descr.dev_id_len; + params[0].u.value.a = rpmb_type_to_rpc_type(rdev->descr.type); + params[0].u.value.b = rdev->descr.capacity; + params[0].u.value.c = rdev->descr.reliable_wr_count; + if (optee->ops->to_msg_param(optee, arg->params, + arg->num_params, params)) { + arg->ret = TEEC_ERROR_BAD_PARAMETERS; + return; + } + + arg->ret = TEEC_SUCCESS; +} + +static void handle_rpc_func_rpmb_frames(struct tee_context *ctx, + struct optee *optee, + struct optee_msg_arg *arg) +{ + struct tee_param params[2]; + struct rpmb_dev *rdev; + void *p0, *p1; + + mutex_lock(&optee->rpmb_dev_mutex); + rdev = rpmb_dev_get(optee->rpmb_dev); + mutex_unlock(&optee->rpmb_dev_mutex); + if (!rdev) { + arg->ret = TEEC_ERROR_ITEM_NOT_FOUND; + return; + } + + if (arg->num_params != ARRAY_SIZE(params) || + optee->ops->from_msg_param(optee, params, arg->num_params, + arg->params) || + params[0].attr != TEE_IOCTL_PARAM_ATTR_TYPE_MEMREF_INPUT || + params[1].attr != TEE_IOCTL_PARAM_ATTR_TYPE_MEMREF_OUTPUT) { + arg->ret = TEEC_ERROR_BAD_PARAMETERS; + goto out; + } + + p0 = tee_shm_get_va(params[0].u.memref.shm, + params[0].u.memref.shm_offs); + p1 = tee_shm_get_va(params[1].u.memref.shm, + params[1].u.memref.shm_offs); + if (rpmb_route_frames(rdev, p0, params[0].u.memref.size, p1, + params[1].u.memref.size)) { + arg->ret = TEEC_ERROR_BAD_PARAMETERS; + goto out; + } + if (optee->ops->to_msg_param(optee, arg->params, + arg->num_params, params)) { + arg->ret = TEEC_ERROR_BAD_PARAMETERS; + goto out; + } + arg->ret = TEEC_SUCCESS; +out: + rpmb_dev_put(rdev); +} + void optee_rpc_cmd(struct tee_context *ctx, struct optee *optee, struct optee_msg_arg *arg) { @@ -271,6 +420,34 @@ void optee_rpc_cmd(struct tee_context *ctx, struct optee *optee, case OPTEE_RPC_CMD_I2C_TRANSFER: handle_rpc_func_cmd_i2c_transfer(ctx, arg); break; + /* + * optee->in_kernel_rpmb_routing true means that OP-TEE supports + * in-kernel RPMB routing _and_ that the RPMB subsystem is + * reachable. This is reported to user space with + * rpmb_routing_model=kernel in sysfs. + * + * rpmb_routing_model=kernel is also a promise to user space that + * RPMB access will not require supplicant support, hence the + * checks below. + */ + case OPTEE_RPC_CMD_RPMB_PROBE_RESET: + if (optee->in_kernel_rpmb_routing) + handle_rpc_func_rpmb_probe_reset(ctx, optee, arg); + else + handle_rpc_supp_cmd(ctx, optee, arg); + break; + case OPTEE_RPC_CMD_RPMB_PROBE_NEXT: + if (optee->in_kernel_rpmb_routing) + handle_rpc_func_rpmb_probe_next(ctx, optee, arg); + else + handle_rpc_supp_cmd(ctx, optee, arg); + break; + case OPTEE_RPC_CMD_RPMB_FRAMES: + if (optee->in_kernel_rpmb_routing) + handle_rpc_func_rpmb_frames(ctx, optee, arg); + else + handle_rpc_supp_cmd(ctx, optee, arg); + break; default: handle_rpc_supp_cmd(ctx, optee, arg); } diff --git a/drivers/tee/optee/smc_abi.c b/drivers/tee/optee/smc_abi.c index a37f87087e5c..fd689dfb5697 100644 --- a/drivers/tee/optee/smc_abi.c +++ b/drivers/tee/optee/smc_abi.c @@ -20,6 +20,7 @@ #include <linux/of_irq.h> #include <linux/of_platform.h> #include <linux/platform_device.h> +#include <linux/rpmb.h> #include <linux/sched.h> #include <linux/slab.h> #include <linux/string.h> @@ -1688,6 +1689,10 @@ static int optee_probe(struct platform_device *pdev) optee->smc.sec_caps = sec_caps; optee->rpc_param_count = rpc_param_count; + if (IS_REACHABLE(CONFIG_RPMB) && + (sec_caps & OPTEE_SMC_SEC_CAP_RPMB_PROBE)) + optee->in_kernel_rpmb_routing = true; + teedev = tee_device_alloc(&optee_clnt_desc, NULL, pool, optee); if (IS_ERR(teedev)) { rc = PTR_ERR(teedev); @@ -1702,6 +1707,8 @@ static int optee_probe(struct platform_device *pdev) } optee->supp_teedev = teedev; + optee_set_dev_group(optee); + rc = tee_device_register(optee->teedev); if (rc) goto err_unreg_supp_teedev; @@ -1715,6 +1722,7 @@ static int optee_probe(struct platform_device *pdev) optee->smc.memremaped_shm = memremaped_shm; optee->pool = pool; optee_shm_arg_cache_init(optee, arg_cache_flags); + mutex_init(&optee->rpmb_dev_mutex); platform_set_drvdata(pdev, optee); ctx = teedev_open(optee->teedev); @@ -1769,6 +1777,10 @@ static int optee_probe(struct platform_device *pdev) if (rc) goto err_disable_shm_cache; + INIT_WORK(&optee->rpmb_scan_bus_work, optee_bus_scan_rpmb); + optee->rpmb_intf.notifier_call = optee_rpmb_intf_rdev; + blocking_notifier_chain_register(&optee_rpmb_intf_added, + &optee->rpmb_intf); pr_info("initialized driver\n"); return 0; @@ -1782,6 +1794,8 @@ static int optee_probe(struct platform_device *pdev) err_close_ctx: teedev_close_context(ctx); err_supp_uninit: + rpmb_dev_put(optee->rpmb_dev); + mutex_destroy(&optee->rpmb_dev_mutex); optee_shm_arg_cache_uninit(optee); optee_supp_uninit(&optee->supp); mutex_destroy(&optee->call_queue.mutex);