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