Hi Jens,
As we are developing platforms to enable RPMB secure storage + fTPM TA, we realize that the current design of optee-os relying on a user space daemon tee-supplicant to serve requests cannot meet requirements of another open source linux kernel, IMA(Integrity Measurement Architecture). This module will try to collect data from TPM devices, which in our case, is fTPM TA. It has to collect data when kernel space is booting up, so we cannot delay these requests further until user space is up. With RPMB as our secure storage, some requests will be sent back to kernel space, but tee-supplicant context is not yet initialized, which results in IMA detection of TPM devices failed. Therefore, failed on the measurements we need. I am wondering if we have related discussion on how modify the design to serve optee-os requests during kernel bootup. I can't find related topics in LKML archive.
Thank you. Judy.
Cat from /Documentation/ABI/testing/sysfs-bus-optee-devices What: /sys/bus/tee/devices/optee-ta-<uuid>/ Date: May 2020 KernelVersion 5.8 Contact: op-tee@lists.trustedfirmware.orgmailto:op-tee@lists.trustedfirmware.org Description: OP-TEE bus provides reference to registered drivers under this directory. The <uuid> matches Trusted Application (TA) driver and corresponding TA in secure OS. Drivers are free to create needed API under optee-ta-<uuid> directory.
Reference:
fTPM TA: microsoft/MSRSec: Security and Privacy Research at Microsoft (github.com)https://github.com/microsoft/MSRSec IMA enabling: https://sourceforge.net/p/linux-ima/wiki/Home/#enabling-ima-measurement:~:te...
Hi Judy,
On Wed, 20 Jul 2022 at 18:29, Judy Wang via OP-TEE op-tee@lists.trustedfirmware.org wrote:
Hi Jens,
As we are developing platforms to enable RPMB secure storage + fTPM TA, we realize that the current design of optee-os relying on a user space daemon tee-supplicant to serve requests cannot meet requirements of another open source linux kernel, IMA(Integrity Measurement Architecture). This module will try to collect data from TPM devices, which in our case, is fTPM TA. It has to collect data when kernel space is booting up, so we cannot delay these requests further until user space is up. With RPMB as our secure storage, some requests will be sent back to kernel space, but tee-supplicant context is not yet initialized, which results in IMA detection of TPM devices failed. Therefore, failed on the measurements we need. I am wondering if we have related discussion on how modify the design to serve optee-os requests during kernel bootup. I can't find related topics in LKML archive.
So the requirement here is to have RPMB accesses routed via the TEE kernel driver itself rather than being dependent on user-mode tee-supplicant. That's a valid use-case and there have been efforts in the past to add a RPMB subsystem within the kernel (the most recent one here [1]). Although for this use-case, I don't think we need that entire RPMB subsystem but some kind of forwarding agent within the TEE kernel driver to read/write encrypted RPMB frames to/from MMC/UFS subsystem.
This has been something on my wish list that I wanted to explore earlier but didn't get enough time. So I would be happy to chip in with reviews/suggestions if you have a proposal/RFC to implement this feature.
[1] https://lore.kernel.org/lkml/20210303135500.24673-1-alex.bennee@linaro.org/
-Sumit
Thank you. Judy.
Cat from /Documentation/ABI/testing/sysfs-bus-optee-devices What: /sys/bus/tee/devices/optee-ta-<uuid>/ Date: May 2020 KernelVersion 5.8 Contact: op-tee@lists.trustedfirmware.orgmailto:op-tee@lists.trustedfirmware.org Description: OP-TEE bus provides reference to registered drivers under this directory. The <uuid> matches Trusted Application (TA) driver and corresponding TA in secure OS. Drivers are free to create needed API under optee-ta-<uuid> directory.
Reference:
fTPM TA: microsoft/MSRSec: Security and Privacy Research at Microsoft (github.com)https://github.com/microsoft/MSRSec IMA enabling: https://sourceforge.net/p/linux-ima/wiki/Home/#enabling-ima-measurement:~:te...
Hi Sumit,
Thanks for the headstart. Is this patch in mainline? I just checked the latest in https://github.com/torvalds/linux or git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git and it's not there. There's definitely worth to borrow the concept to build a solution but as you've figured out, we do not need a whole rpmb driver to manage the request from optee-os. In our platform, optee-os has been booted by firmware so most of the info has been retrieved through rpmb driver in uboot of firmware. When uboot handover control to linux kernel, the requests from IMA are simply registering share memory and use it to pass information by reading/writing rpmb storage. So what I'm thinking now is a path in supplicant device driver to mmc driver which allow us to fulfill the read/writes before supplicant context is filled in user space. I can see the whole design is rooted with the idea of having tee-supplicant as the servant, don't think it's worth to flip the whole design just to fill the gap before user space is up. We haven't really come up with a design so will keep you posted.
Judy.
-----Original Message----- From: Sumit Garg sumit.garg@linaro.org Sent: Thursday, July 21, 2022 4:01 PM To: Judy Wang wangjudy@microsoft.com Cc: jens.wiklander@linaro.org; op-tee@lists.trustedfirmware.org; Carl Lamb Carl.Lamb@microsoft.com; Tyler Hicks Tyler.Hicks@microsoft.com Subject: [EXTERNAL] Re: Current design of tee-supplicant can't support ftpm requests during kernel space bootup
[You don't often get email from sumit.garg@linaro.org. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
Hi Judy,
On Wed, 20 Jul 2022 at 18:29, Judy Wang via OP-TEE op-tee@lists.trustedfirmware.org wrote:
Hi Jens,
As we are developing platforms to enable RPMB secure storage + fTPM TA, we realize that the current design of optee-os relying on a user space daemon tee-supplicant to serve requests cannot meet requirements of another open source linux kernel, IMA(Integrity Measurement Architecture). This module will try to collect data from TPM devices, which in our case, is fTPM TA. It has to collect data when kernel space is booting up, so we cannot delay these requests further until user space is up. With RPMB as our secure storage, some requests will be sent back to kernel space, but tee-supplicant context is not yet initialized, which results in IMA detection of TPM devices failed. Therefore, failed on the measurements we need. I am wondering if we have related discussion on how modify the design to serve optee-os requests during kernel bootup. I can't find related topics in LKML archive.
So the requirement here is to have RPMB accesses routed via the TEE kernel driver itself rather than being dependent on user-mode tee-supplicant. That's a valid use-case and there have been efforts in the past to add a RPMB subsystem within the kernel (the most recent one here [1]). Although for this use-case, I don't think we need that entire RPMB subsystem but some kind of forwarding agent within the TEE kernel driver to read/write encrypted RPMB frames to/from MMC/UFS subsystem.
This has been something on my wish list that I wanted to explore earlier but didn't get enough time. So I would be happy to chip in with reviews/suggestions if you have a proposal/RFC to implement this feature.
[1] https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.kerne...
-Sumit
Thank you. Judy.
Cat from /Documentation/ABI/testing/sysfs-bus-optee-devices What: /sys/bus/tee/devices/optee-ta-<uuid>/ Date: May 2020 KernelVersion 5.8 Contact: op-tee@lists.trustedfirmware.orgmailto:op-tee@lists.trustedfirmware.org Description: OP-TEE bus provides reference to registered drivers under this directory. The <uuid> matches Trusted Application (TA) driver and corresponding TA in secure OS. Drivers are free to create needed API under optee-ta-<uuid> directory.
Reference:
fTPM TA: microsoft/MSRSec: Security and Privacy Research at Microsoft (github.com)https://nam06.safelinks.protection.outlook.com/?url=https %3A%2F%2Fgithub.com%2Fmicrosoft%2FMSRSec&data=05%7C01%7Cwangjudy%4 0microsoft.com%7C0aea3957369e432f632a08da6aef23e4%7C72f988bf86f141af91 ab2d7cd011db47%7C1%7C0%7C637939872610700517%7CUnknown%7CTWFpbGZsb3d8ey JWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C300 0%7C%7C%7C&sdata=6u5Naup8ldvDk0bKHy9dbyD5s0HurvQqUNfcaoMI8rE%3D&am p;reserved=0 IMA enabling: https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsour ceforge.net%2Fp%2Flinux-ima%2Fwiki%2FHome%2F%23enabling-ima-measuremen t%3A~%3Atext%3Dsystem%2527s%2520runtime%2520integrity.-%2CEnabling%252 0IMA-measurement%2C-IMA%2520was%2520first&data=05%7C01%7Cwangjudy% 40microsoft.com%7C0aea3957369e432f632a08da6aef23e4%7C72f988bf86f141af9 1ab2d7cd011db47%7C1%7C0%7C637939872610700517%7CUnknown%7CTWFpbGZsb3d8e yJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C30 00%7C%7C%7C&sdata=SfGiiflJH1OKWpklRyqGhIK7AJ%2FMDEyMl3f4ILyGRlI%3D &reserved=0
On Thu, 21 Jul 2022 at 14:41, Judy Wang wangjudy@microsoft.com wrote:
Hi Sumit,
Thanks for the headstart. Is this patch in mainline? I just checked the latest in https://github.com/torvalds/linux or git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git and it's not there.
Yeah it hasn't made it to the mainline and you can see the whole discussion around management of RPMB key. But for OP-TEE use-case that shouldn't be an issue as the RPMB key is managed by OP-TEE and the kernel has to just act as a forwarding agent.
There's definitely worth to borrow the concept to build a solution but as you've figured out, we do not need a whole rpmb driver to manage the request from optee-os. In our platform, optee-os has been booted by firmware so most of the info has been retrieved through rpmb driver in uboot of firmware. When uboot handover control to linux kernel, the requests from IMA are simply registering share memory and use it to pass information by reading/writing rpmb storage. So what I'm thinking now is a path in supplicant device driver to mmc driver which allow us to fulfill the read/writes before supplicant context is filled in user space.
Ack.
I can see the whole design is rooted with the idea of having tee-supplicant as the servant, don't think it's worth to flip the whole design just to fill the gap before user space is up. We haven't really come up with a design so will keep you posted.
You don't need to flip the tee-supplicant design but rather just handle RPMB requests in the kernel itself if it's supported by MMC driver (you need a similar hook in the kernel as we have in u-boot [1]). All other OP-TEE RPC requests unhandled by the kernel can be forwarded to the user-mode tee-supplicant.
[1] https://source.denx.de/u-boot/u-boot/-/commit/4853ad3e13e21462a86e09caee4ea2...
-Sumit
Judy.
-----Original Message----- From: Sumit Garg sumit.garg@linaro.org Sent: Thursday, July 21, 2022 4:01 PM To: Judy Wang wangjudy@microsoft.com Cc: jens.wiklander@linaro.org; op-tee@lists.trustedfirmware.org; Carl Lamb Carl.Lamb@microsoft.com; Tyler Hicks Tyler.Hicks@microsoft.com Subject: [EXTERNAL] Re: Current design of tee-supplicant can't support ftpm requests during kernel space bootup
[You don't often get email from sumit.garg@linaro.org. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
Hi Judy,
On Wed, 20 Jul 2022 at 18:29, Judy Wang via OP-TEE op-tee@lists.trustedfirmware.org wrote:
Hi Jens,
As we are developing platforms to enable RPMB secure storage + fTPM TA, we realize that the current design of optee-os relying on a user space daemon tee-supplicant to serve requests cannot meet requirements of another open source linux kernel, IMA(Integrity Measurement Architecture). This module will try to collect data from TPM devices, which in our case, is fTPM TA. It has to collect data when kernel space is booting up, so we cannot delay these requests further until user space is up. With RPMB as our secure storage, some requests will be sent back to kernel space, but tee-supplicant context is not yet initialized, which results in IMA detection of TPM devices failed. Therefore, failed on the measurements we need. I am wondering if we have related discussion on how modify the design to serve optee-os requests during kernel bootup. I can't find related topics in LKML archive.
So the requirement here is to have RPMB accesses routed via the TEE kernel driver itself rather than being dependent on user-mode tee-supplicant. That's a valid use-case and there have been efforts in the past to add a RPMB subsystem within the kernel (the most recent one here [1]). Although for this use-case, I don't think we need that entire RPMB subsystem but some kind of forwarding agent within the TEE kernel driver to read/write encrypted RPMB frames to/from MMC/UFS subsystem.
This has been something on my wish list that I wanted to explore earlier but didn't get enough time. So I would be happy to chip in with reviews/suggestions if you have a proposal/RFC to implement this feature.
[1] https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.kerne...
-Sumit
Thank you. Judy.
Cat from /Documentation/ABI/testing/sysfs-bus-optee-devices What: /sys/bus/tee/devices/optee-ta-<uuid>/ Date: May 2020 KernelVersion 5.8 Contact: op-tee@lists.trustedfirmware.orgmailto:op-tee@lists.trustedfirmware.org Description: OP-TEE bus provides reference to registered drivers under this directory. The <uuid> matches Trusted Application (TA) driver and corresponding TA in secure OS. Drivers are free to create needed API under optee-ta-<uuid> directory.
Reference:
fTPM TA: microsoft/MSRSec: Security and Privacy Research at Microsoft (github.com)https://nam06.safelinks.protection.outlook.com/?url=https %3A%2F%2Fgithub.com%2Fmicrosoft%2FMSRSec&data=05%7C01%7Cwangjudy%4 0microsoft.com%7C0aea3957369e432f632a08da6aef23e4%7C72f988bf86f141af91 ab2d7cd011db47%7C1%7C0%7C637939872610700517%7CUnknown%7CTWFpbGZsb3d8ey JWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C300 0%7C%7C%7C&sdata=6u5Naup8ldvDk0bKHy9dbyD5s0HurvQqUNfcaoMI8rE%3D&am p;reserved=0 IMA enabling: https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsour ceforge.net%2Fp%2Flinux-ima%2Fwiki%2FHome%2F%23enabling-ima-measuremen t%3A~%3Atext%3Dsystem%2527s%2520runtime%2520integrity.-%2CEnabling%252 0IMA-measurement%2C-IMA%2520was%2520first&data=05%7C01%7Cwangjudy% 40microsoft.com%7C0aea3957369e432f632a08da6aef23e4%7C72f988bf86f141af9 1ab2d7cd011db47%7C1%7C0%7C637939872610700517%7CUnknown%7CTWFpbGZsb3d8e yJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C30 00%7C%7C%7C&sdata=SfGiiflJH1OKWpklRyqGhIK7AJ%2FMDEyMl3f4ILyGRlI%3D &reserved=0
On Thu, Jul 21, 2022 at 11:46 AM Sumit Garg sumit.garg@linaro.org wrote:
On Thu, 21 Jul 2022 at 14:41, Judy Wang wangjudy@microsoft.com wrote:
I can see the whole design is rooted with the idea of having
tee-supplicant as the servant, don't think it's worth to flip the whole design just to fill the gap before user space is up. We haven't really come up with a design so will keep you posted.
You don't need to flip the tee-supplicant design but rather just handle RPMB requests in the kernel itself if it's supported by MMC driver (you need a similar hook in the kernel as we have in u-boot [1]). All other OP-TEE RPC requests unhandled by the kernel can be forwarded to the user-mode tee-supplicant.
Correct but please keep in mind that we have RPMB emulation code inside tee-supplicant, which is quite useful for testing. Therefore any "fast path" to the MMC driver inside the OP-TEE driver should probably be opt-out.
On Mon, 25 Jul 2022 at 19:44, Jérôme Forissier jerome@forissier.org wrote:
On Thu, Jul 21, 2022 at 11:46 AM Sumit Garg sumit.garg@linaro.org wrote:
On Thu, 21 Jul 2022 at 14:41, Judy Wang wangjudy@microsoft.com wrote:
I can see the whole design is rooted with the idea of having tee-supplicant as the servant, don't think it's worth to flip the whole design just to fill the gap before user space is up. We haven't really come up with a design so will keep you posted.
You don't need to flip the tee-supplicant design but rather just handle RPMB requests in the kernel itself if it's supported by MMC driver (you need a similar hook in the kernel as we have in u-boot [1]). All other OP-TEE RPC requests unhandled by the kernel can be forwarded to the user-mode tee-supplicant.
Correct but please keep in mind that we have RPMB emulation code inside tee-supplicant, which is quite useful for testing. Therefore any "fast path" to the MMC driver inside the OP-TEE driver should probably be opt-out.
Agree.
-Sumit
-- Jerome
If a fast path to the MMC driver isn't an option due to concerns of affecting RPMB emulation codes. Any other suggestions we could solve this issue? Thank you.
Judy.
-----Original Message----- From: Sumit Garg sumit.garg@linaro.org Sent: Tuesday, July 26, 2022 12:37 PM To: Jérôme Forissier jerome@forissier.org Cc: Judy Wang wangjudy@microsoft.com; op-tee@lists.trustedfirmware.org; Carl Lamb Carl.Lamb@microsoft.com; Tyler Hicks Tyler.Hicks@microsoft.com Subject: Re: [EXTERNAL] Re: Current design of tee-supplicant can't support ftpm requests during kernel space bootup
[You don't often get email from sumit.garg@linaro.org. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
On Mon, 25 Jul 2022 at 19:44, Jérôme Forissier jerome@forissier.org wrote:
On Thu, Jul 21, 2022 at 11:46 AM Sumit Garg sumit.garg@linaro.org wrote:
On Thu, 21 Jul 2022 at 14:41, Judy Wang wangjudy@microsoft.com wrote:
I can see the whole design is rooted with the idea of having tee-supplicant as the servant, don't think it's worth to flip the whole design just to fill the gap before user space is up. We haven't really come up with a design so will keep you posted.
You don't need to flip the tee-supplicant design but rather just handle RPMB requests in the kernel itself if it's supported by MMC driver (you need a similar hook in the kernel as we have in u-boot [1]). All other OP-TEE RPC requests unhandled by the kernel can be forwarded to the user-mode tee-supplicant.
Correct but please keep in mind that we have RPMB emulation code inside tee-supplicant, which is quite useful for testing. Therefore any "fast path" to the MMC driver inside the OP-TEE driver should probably be opt-out.
Agree.
-Sumit
-- Jerome
On Wed, 27 Jul 2022 at 07:47, Judy Wang wangjudy@microsoft.com wrote:
If a fast path to the MMC driver isn't an option due to concerns of affecting RPMB emulation codes.
RPMB emulation in user-mode supplicant is just there for testing purposes before switching to real RPMB partition. So a fast path to MMC driver for RPMB access should be the default option with an opt-out choice via a config option like CONFIG_OPTEE_RPMB_EMULATION which should be disabled by default.
-Sumit
Any other suggestions we could solve this issue? Thank you.
Judy.
-----Original Message----- From: Sumit Garg sumit.garg@linaro.org Sent: Tuesday, July 26, 2022 12:37 PM To: Jérôme Forissier jerome@forissier.org Cc: Judy Wang wangjudy@microsoft.com; op-tee@lists.trustedfirmware.org; Carl Lamb Carl.Lamb@microsoft.com; Tyler Hicks Tyler.Hicks@microsoft.com Subject: Re: [EXTERNAL] Re: Current design of tee-supplicant can't support ftpm requests during kernel space bootup
[You don't often get email from sumit.garg@linaro.org. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
On Mon, 25 Jul 2022 at 19:44, Jérôme Forissier jerome@forissier.org wrote:
On Thu, Jul 21, 2022 at 11:46 AM Sumit Garg sumit.garg@linaro.org wrote:
On Thu, 21 Jul 2022 at 14:41, Judy Wang wangjudy@microsoft.com wrote:
I can see the whole design is rooted with the idea of having tee-supplicant as the servant, don't think it's worth to flip the whole design just to fill the gap before user space is up. We haven't really come up with a design so will keep you posted.
You don't need to flip the tee-supplicant design but rather just handle RPMB requests in the kernel itself if it's supported by MMC driver (you need a similar hook in the kernel as we have in u-boot [1]). All other OP-TEE RPC requests unhandled by the kernel can be forwarded to the user-mode tee-supplicant.
Correct but please keep in mind that we have RPMB emulation code inside tee-supplicant, which is quite useful for testing. Therefore any "fast path" to the MMC driver inside the OP-TEE driver should probably be opt-out.
Agree.
-Sumit
-- Jerome
Hi,
On Wed, Jul 27, 2022 at 7:28 AM Sumit Garg sumit.garg@linaro.org wrote:
On Wed, 27 Jul 2022 at 07:47, Judy Wang wangjudy@microsoft.com wrote:
If a fast path to the MMC driver isn't an option due to concerns of affecting RPMB emulation codes.
RPMB emulation in user-mode supplicant is just there for testing purposes before switching to real RPMB partition. So a fast path to MMC driver for RPMB access should be the default option with an opt-out choice via a config option like CONFIG_OPTEE_RPMB_EMULATION which should be disabled by default.
I agree, but the name of the config option can be discussed. I'd prefer something that describes what it does from a kernel point of view, perhaps CONFIG_OPTEE_RPMB_FASTPATH.
So far we have considered the problem of selecting the correct RPMB device (out of many) a user space problem, but with the fast-path option, we're moving the problem into kernel space. Tee-supplicant has a --rpmb-cid option as one way of addressing this problem. I'm not sure what's the best approach for the kernel driver.
Cheers, Jens
-Sumit
Any other suggestions we could solve this issue? Thank you.
Judy.
-----Original Message----- From: Sumit Garg sumit.garg@linaro.org Sent: Tuesday, July 26, 2022 12:37 PM To: Jérôme Forissier jerome@forissier.org Cc: Judy Wang wangjudy@microsoft.com; op-tee@lists.trustedfirmware.org; Carl Lamb Carl.Lamb@microsoft.com; Tyler Hicks Tyler.Hicks@microsoft.com Subject: Re: [EXTERNAL] Re: Current design of tee-supplicant can't support ftpm requests during kernel space bootup
[You don't often get email from sumit.garg@linaro.org. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
On Mon, 25 Jul 2022 at 19:44, Jérôme Forissier jerome@forissier.org wrote:
On Thu, Jul 21, 2022 at 11:46 AM Sumit Garg sumit.garg@linaro.org wrote:
On Thu, 21 Jul 2022 at 14:41, Judy Wang wangjudy@microsoft.com wrote:
I can see the whole design is rooted with the idea of having tee-supplicant as the servant, don't think it's worth to flip the whole design just to fill the gap before user space is up. We haven't really come up with a design so will keep you posted.
You don't need to flip the tee-supplicant design but rather just handle RPMB requests in the kernel itself if it's supported by MMC driver (you need a similar hook in the kernel as we have in u-boot [1]). All other OP-TEE RPC requests unhandled by the kernel can be forwarded to the user-mode tee-supplicant.
Correct but please keep in mind that we have RPMB emulation code inside tee-supplicant, which is quite useful for testing. Therefore any "fast path" to the MMC driver inside the OP-TEE driver should probably be opt-out.
Agree.
-Sumit
-- Jerome
On Mon, 8 Aug 2022 at 14:17, Jens Wiklander jens.wiklander@linaro.org wrote:
Hi,
On Wed, Jul 27, 2022 at 7:28 AM Sumit Garg sumit.garg@linaro.org wrote:
On Wed, 27 Jul 2022 at 07:47, Judy Wang wangjudy@microsoft.com wrote:
If a fast path to the MMC driver isn't an option due to concerns of affecting RPMB emulation codes.
RPMB emulation in user-mode supplicant is just there for testing purposes before switching to real RPMB partition. So a fast path to MMC driver for RPMB access should be the default option with an opt-out choice via a config option like CONFIG_OPTEE_RPMB_EMULATION which should be disabled by default.
I agree, but the name of the config option can be discussed. I'd prefer something that describes what it does from a kernel point of view, perhaps CONFIG_OPTEE_RPMB_FASTPATH.
So far we have considered the problem of selecting the correct RPMB device (out of many) a user space problem, but with the fast-path option, we're moving the problem into kernel space. Tee-supplicant has a --rpmb-cid option as one way of addressing this problem. I'm not sure what's the best approach for the kernel driver.
I think a kernel module parameter should suffice the RPMB selection problem. It should tell which RPMB partition is assigned to OP-TEE.
-Sumit
Cheers, Jens
-Sumit
Any other suggestions we could solve this issue? Thank you.
Judy.
-----Original Message----- From: Sumit Garg sumit.garg@linaro.org Sent: Tuesday, July 26, 2022 12:37 PM To: Jérôme Forissier jerome@forissier.org Cc: Judy Wang wangjudy@microsoft.com; op-tee@lists.trustedfirmware.org; Carl Lamb Carl.Lamb@microsoft.com; Tyler Hicks Tyler.Hicks@microsoft.com Subject: Re: [EXTERNAL] Re: Current design of tee-supplicant can't support ftpm requests during kernel space bootup
[You don't often get email from sumit.garg@linaro.org. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
On Mon, 25 Jul 2022 at 19:44, Jérôme Forissier jerome@forissier.org wrote:
On Thu, Jul 21, 2022 at 11:46 AM Sumit Garg sumit.garg@linaro.org wrote:
On Thu, 21 Jul 2022 at 14:41, Judy Wang wangjudy@microsoft.com wrote:
I can see the whole design is rooted with the idea of having tee-supplicant as the servant, don't think it's worth to flip the whole design just to fill the gap before user space is up. We haven't really come up with a design so will keep you posted.
You don't need to flip the tee-supplicant design but rather just handle RPMB requests in the kernel itself if it's supported by MMC driver (you need a similar hook in the kernel as we have in u-boot [1]). All other OP-TEE RPC requests unhandled by the kernel can be forwarded to the user-mode tee-supplicant.
Correct but please keep in mind that we have RPMB emulation code inside tee-supplicant, which is quite useful for testing. Therefore any "fast path" to the MMC driver inside the OP-TEE driver should probably be opt-out.
Agree.
-Sumit
-- Jerome
op-tee@lists.trustedfirmware.org
-
Jens Wiklander -
Judy Wang -
Jérôme Forissier -
Sumit Garg