- OP-TEE - lists.trustedfirmware.org

fragment transmission while retrieving memory

by 梅建强(禹夜)

Hi, Jens, >The first is the descriptor passed with FFA_MEM_RETRIEVE_REQ_32, >this one is not likely to need fragmentation support soon. Could you tell me why? I'm a little unclear. Could you describe the difference between the retrieve process you mean and FFA-spec figure 18.4 in detail? I need to make sure that I really understand what you mean, so that I can implement the missing support for fragmented mem retrieve response as you said. Or do you mean that we just need to implement the action done by optee after it receives FFA_MEM_RETRIEVE_RESP_32? Regards, Yuye. ------------------------------------------------------------------ 发件人：Jens Wiklander <jens.wiklander(a)linaro.org> 发送时间：2023年4月14日(星期五) 14:23 收件人：梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> 抄　送：Olivier Deprez <Olivier.Deprez(a)arm.com>; hafnium <hafnium(a)lists.trustedfirmware.org>; op-tee <op-tee(a)lists.trustedfirmware.org> 主　题：Re: fragment transmission while retrieving memory Hi Yuye, On Fri, Apr 14, 2023 at 4:29 AM 梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> wrote: > > > Hi, Jens, Olivier, > > If I understand properly, for this specific issue both optee and hafnium need to do further fix. > The following discussion and questions are based on figure 18.4 in the FFA spec. > > As I saw in the optee code, the retrieve mechanism would start with this code: > retrieve_desc = spmc_retrieve_req(cookie); > And in the function spmc_retrieve_req, > optee sets the total length to the same size as fragment0 length before sending FFA_MEM_FRAG_REQ to hafnium, > which means hafnium will only retrieve the fragment0 memory region. > > In the example process, > optee will determines the number of TX sized fragments of descriptor before sending FFA_MEM_FRAG_REQ to hafnium. > I have a question here. > How should optee calculate this quantity? > > Hafnium then receives the FFA_MEM_FRAG_REQ. > As I saw in the hafnium code, hafnium blocks the case that total length>fragment length. > if (fragment_length != length) { > dlog_verbose("Fragmentation not yet supported.\n"); > return ffa_error(FFA_INVALID_PARAMETERS); > } > Obviously it is not what we expected. > Then following the example process, hafnium should allocate handle and use it to associate fragments. > I didn't find the corresponding implementation in hafnium code for this step. > And I want to know how to implement the associate action here. > > After that, optee lacks the implementation of FFA_MEM_FRAG_RX and FFA_MEM_FRAG_TX ABI in CFG_CORE_SEL2_SPMC enable case. > Is there any support plan for the implementation of fragmented memory retrieve in the optee community? > Does the hafnium community have a plan to implement it cooperatively? If I've understood this correctly we have two different cases of eventual fragmentation of descriptors. The first is the descriptor passed with FFA_MEM_RETRIEVE_REQ_32, this one is not likely to need fragmentation support soon. The other is the descriptor received with FFA_MEM_RETRIEVE_RESP, I believe this is where you've run into trouble. From OP-TEE point of view, it would make sense if you took lead on implementing this. I can help with review etc. Thanks, Jens > > Thanks a lot for your support. > > Regards, > Yuye. > > > > > > ------------------------------------------------------------------ > 发件人：Olivier Deprez <Olivier.Deprez(a)arm.com> > 发送时间：2023年4月13日(星期四) 15:52 > 收件人：梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> > 抄送：hafnium <hafnium(a)lists.trustedfirmware.org>; Jens Wiklander <jens.wiklander(a)linaro.org> > 主题：Re: fragment transmission while retrieving memory > > Hi Yuye, Jens, > > For the record, and If I understand properly the last comment in the github issue: > OP-TEE is missing the implementation for receipt of a fragmented retrieve response > There is no further fix to be done in Hafnium for this specific issue at this moment, please let me know otherwise. > > Thanks, Olivier. > > > ________________________________ > From: 梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> > Sent: 12 April 2023 09:27 > To: Olivier Deprez <Olivier.Deprez(a)arm.com> > Cc: hafnium <hafnium(a)lists.trustedfirmware.org>; Jens Wiklander <jens.wiklander(a)linaro.org> > Subject: Re: fragment transmission while retrieving memory > > > > > Hi, Olivier, > > In our setup, > Hafnium commit: 997476a74571aec4f1a23590d45edf516f3934f4 > optee version: 3.20.0 > Thanks. > > Regards, > Yuye. > > ------------------------------------------------------------------ > 发件人：Olivier Deprez <Olivier.Deprez(a)arm.com> > 发送时间：2023年4月12日(星期三) 15:22 > 收件人：梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> > 抄送：hafnium <hafnium(a)lists.trustedfirmware.org>; Jens Wiklander <jens.wiklander(a)linaro.org> > 主题：Re: fragment transmission while retrieving memory > > Hi Yuye, > > AFAIK concerning Hafnium, fragmented mem sharing is supported for FFA_MEM_SHARE/LEND/DONATE and FFA_MEM_RETRIEVE_RESP. > (For the sake of clarity, this isn't supported for FFA_MEM_RETRIEVE_REQ but this shouldn't be a concern as this limitation only exists in the case of mem sharing to multiple borrowers. In your case of a single borrower the mem retrieve req. shouldn't have to be fragmented). > > Can you tell which hafnium commit hash is used in your setup? > > At the moment, I cannot tell if the issue described concern a miss in Hafnium or OP-TEE. > I need to dig a bit further into both implementations and I'll let you know. > > Regards, > Olivier. > > > ________________________________ > From: 梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> > Sent: 12 April 2023 08:21 > To: Olivier Deprez <Olivier.Deprez(a)arm.com> > Cc: hafnium <hafnium(a)lists.trustedfirmware.org>; Jens Wiklander <jens.wiklander(a)linaro.org> > Subject: fragment transmission while retrieving memory > > > > > Hi, Olivier, > > Recently, I've been working on this issue. > https://github.com/OP-TEE/optee_os/issues/5943 <https://github.com/OP-TEE/optee_os/issues/5943 > > Do you know any differences between hafnium's current implementation of fragment transmission while retrieving memory and the example process described in FF-A 1.1 Figure 18.4? > > Regards, > Yuye. > >

2 years, 9 months

2
1
0 0

fragment transmission while retrieving memory

by 梅建强(禹夜)

Hi, Jens, Olivier, update for optee: https://github.com/OP-TEE/optee_os/pull/5966 <https://github.com/OP-TEE/optee_os/pull/5966 > update for hafnium: diff --git a/src/api.c b/src/api.c index 5f699478..7e43e305 100644 --- a/src/api.c +++ b/src/api.c @@ -3191,7 +3191,8 @@ struct ffa_value api_ffa_mem_frag_rx(ffa_memory_handle_t handle, return ffa_error(FFA_INVALID_PARAMETERS); } } - + if (to->id==0x8001 && to->mailbox.state != MAILBOX_STATE_EMPTY) + to->mailbox.state = MAILBOX_STATE_EMPTY; to_locked = vm_lock(to); if (vm_is_mailbox_busy(to_locked)) { diff --git a/src/ffa_memory.c b/src/ffa_memory.c index 3e978d23..59e71ff3 100644 --- a/src/ffa_memory.c +++ b/src/ffa_memory.c @@ -2385,7 +2385,7 @@ struct ffa_value ffa_memory_retrieve_continue(struct vm_locked to_locked, &fragment_length); CHECK(remaining_constituent_count == 0); to_locked.vm->mailbox.recv_size = fragment_length; - to_locked.vm->mailbox.recv_sender = HF_HYPERVISOR_VM_ID; + to_locked.vm->mailbox.recv_sender = to_locked.vm->id; to_locked.vm->mailbox.recv_func = FFA_MEM_FRAG_TX_32; to_locked.vm->mailbox.state = MAILBOX_STATE_FULL; It seems that to->mailbox.state needs to be set to MAILBOX_STATE_EMPTY firstly. I have not figured out why, but large TA could be loaded successfully with above fix now. Regards, Yuye. ------------------------------------------------------------------ 发件人：梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> 发送时间：2023年4月17日(星期一) 02:16 收件人：Jens Wiklander <jens.wiklander(a)linaro.org> 抄　送：Olivier Deprez <Olivier.Deprez(a)arm.com>; hafnium <hafnium(a)lists.trustedfirmware.org>; op-tee <op-tee(a)lists.trustedfirmware.org> 主　题：fragment transmission while retrieving memory Hi, Jens, I have implement the missing support for fragmented mem retrieve response as you suggested. I will push fix into the community code soon and please help review it later. Thanks. Regards, Yuye. ------------------------------------------------------------------ 发件人：Jens Wiklander <jens.wiklander(a)linaro.org> 发送时间：2023年4月14日(星期五) 14:23 收件人：梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> 抄　送：Olivier Deprez <Olivier.Deprez(a)arm.com>; hafnium <hafnium(a)lists.trustedfirmware.org>; op-tee <op-tee(a)lists.trustedfirmware.org> 主　题：Re: fragment transmission while retrieving memory Hi Yuye, On Fri, Apr 14, 2023 at 4:29 AM 梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> wrote: > > > Hi, Jens, Olivier, > > If I understand properly, for this specific issue both optee and hafnium need to do further fix. > The following discussion and questions are based on figure 18.4 in the FFA spec. > > As I saw in the optee code, the retrieve mechanism would start with this code: > retrieve_desc = spmc_retrieve_req(cookie); > And in the function spmc_retrieve_req, > optee sets the total length to the same size as fragment0 length before sending FFA_MEM_FRAG_REQ to hafnium, > which means hafnium will only retrieve the fragment0 memory region. > > In the example process, > optee will determines the number of TX sized fragments of descriptor before sending FFA_MEM_FRAG_REQ to hafnium. > I have a question here. > How should optee calculate this quantity? > > Hafnium then receives the FFA_MEM_FRAG_REQ. > As I saw in the hafnium code, hafnium blocks the case that total length>fragment length. > if (fragment_length != length) { > dlog_verbose("Fragmentation not yet supported.\n"); > return ffa_error(FFA_INVALID_PARAMETERS); > } > Obviously it is not what we expected. > Then following the example process, hafnium should allocate handle and use it to associate fragments. > I didn't find the corresponding implementation in hafnium code for this step. > And I want to know how to implement the associate action here. > > After that, optee lacks the implementation of FFA_MEM_FRAG_RX and FFA_MEM_FRAG_TX ABI in CFG_CORE_SEL2_SPMC enable case. > Is there any support plan for the implementation of fragmented memory retrieve in the optee community? > Does the hafnium community have a plan to implement it cooperatively? If I've understood this correctly we have two different cases of eventual fragmentation of descriptors. The first is the descriptor passed with FFA_MEM_RETRIEVE_REQ_32, this one is not likely to need fragmentation support soon. The other is the descriptor received with FFA_MEM_RETRIEVE_RESP, I believe this is where you've run into trouble. From OP-TEE point of view, it would make sense if you took lead on implementing this. I can help with review etc. Thanks, Jens > > Thanks a lot for your support. > > Regards, > Yuye. > > > > > > ------------------------------------------------------------------ > 发件人：Olivier Deprez <Olivier.Deprez(a)arm.com> > 发送时间：2023年4月13日(星期四) 15:52 > 收件人：梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> > 抄送：hafnium <hafnium(a)lists.trustedfirmware.org>; Jens Wiklander <jens.wiklander(a)linaro.org> > 主题：Re: fragment transmission while retrieving memory > > Hi Yuye, Jens, > > For the record, and If I understand properly the last comment in the github issue: > OP-TEE is missing the implementation for receipt of a fragmented retrieve response > There is no further fix to be done in Hafnium for this specific issue at this moment, please let me know otherwise. > > Thanks, Olivier. > > > ________________________________ > From: 梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> > Sent: 12 April 2023 09:27 > To: Olivier Deprez <Olivier.Deprez(a)arm.com> > Cc: hafnium <hafnium(a)lists.trustedfirmware.org>; Jens Wiklander <jens.wiklander(a)linaro.org> > Subject: Re: fragment transmission while retrieving memory > > > > > Hi, Olivier, > > In our setup, > Hafnium commit: 997476a74571aec4f1a23590d45edf516f3934f4 > optee version: 3.20.0 > Thanks. > > Regards, > Yuye. > > ------------------------------------------------------------------ > 发件人：Olivier Deprez <Olivier.Deprez(a)arm.com> > 发送时间：2023年4月12日(星期三) 15:22 > 收件人：梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> > 抄送：hafnium <hafnium(a)lists.trustedfirmware.org>; Jens Wiklander <jens.wiklander(a)linaro.org> > 主题：Re: fragment transmission while retrieving memory > > Hi Yuye, > > AFAIK concerning Hafnium, fragmented mem sharing is supported for FFA_MEM_SHARE/LEND/DONATE and FFA_MEM_RETRIEVE_RESP. > (For the sake of clarity, this isn't supported for FFA_MEM_RETRIEVE_REQ but this shouldn't be a concern as this limitation only exists in the case of mem sharing to multiple borrowers. In your case of a single borrower the mem retrieve req. shouldn't have to be fragmented). > > Can you tell which hafnium commit hash is used in your setup? > > At the moment, I cannot tell if the issue described concern a miss in Hafnium or OP-TEE. > I need to dig a bit further into both implementations and I'll let you know. > > Regards, > Olivier. > > > ________________________________ > From: 梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> > Sent: 12 April 2023 08:21 > To: Olivier Deprez <Olivier.Deprez(a)arm.com> > Cc: hafnium <hafnium(a)lists.trustedfirmware.org>; Jens Wiklander <jens.wiklander(a)linaro.org> > Subject: fragment transmission while retrieving memory > > > > > Hi, Olivier, > > Recently, I've been working on this issue. > https://github.com/OP-TEE/optee_os/issues/5943 <https://github.com/OP-TEE/optee_os/issues/5943 > > Do you know any differences between hafnium's current implementation of fragment transmission while retrieving memory and the example process described in FF-A 1.1 Figure 18.4? > > Regards, > Yuye. > >

2 years, 9 months

1
0
0 0

fragment transmission while retrieving memory

by 梅建强(禹夜)

Hi, Jens, I have implement the missing support for fragmented mem retrieve response as you suggested. I will push fix into the community code soon and please help review it later. Thanks. Regards, Yuye. ------------------------------------------------------------------ 发件人：Jens Wiklander <jens.wiklander(a)linaro.org> 发送时间：2023年4月14日(星期五) 14:23 收件人：梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> 抄　送：Olivier Deprez <Olivier.Deprez(a)arm.com>; hafnium <hafnium(a)lists.trustedfirmware.org>; op-tee <op-tee(a)lists.trustedfirmware.org> 主　题：Re: fragment transmission while retrieving memory Hi Yuye, On Fri, Apr 14, 2023 at 4:29 AM 梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> wrote: > > > Hi, Jens, Olivier, > > If I understand properly, for this specific issue both optee and hafnium need to do further fix. > The following discussion and questions are based on figure 18.4 in the FFA spec. > > As I saw in the optee code, the retrieve mechanism would start with this code: > retrieve_desc = spmc_retrieve_req(cookie); > And in the function spmc_retrieve_req, > optee sets the total length to the same size as fragment0 length before sending FFA_MEM_FRAG_REQ to hafnium, > which means hafnium will only retrieve the fragment0 memory region. > > In the example process, > optee will determines the number of TX sized fragments of descriptor before sending FFA_MEM_FRAG_REQ to hafnium. > I have a question here. > How should optee calculate this quantity? > > Hafnium then receives the FFA_MEM_FRAG_REQ. > As I saw in the hafnium code, hafnium blocks the case that total length>fragment length. > if (fragment_length != length) { > dlog_verbose("Fragmentation not yet supported.\n"); > return ffa_error(FFA_INVALID_PARAMETERS); > } > Obviously it is not what we expected. > Then following the example process, hafnium should allocate handle and use it to associate fragments. > I didn't find the corresponding implementation in hafnium code for this step. > And I want to know how to implement the associate action here. > > After that, optee lacks the implementation of FFA_MEM_FRAG_RX and FFA_MEM_FRAG_TX ABI in CFG_CORE_SEL2_SPMC enable case. > Is there any support plan for the implementation of fragmented memory retrieve in the optee community? > Does the hafnium community have a plan to implement it cooperatively? If I've understood this correctly we have two different cases of eventual fragmentation of descriptors. The first is the descriptor passed with FFA_MEM_RETRIEVE_REQ_32, this one is not likely to need fragmentation support soon. The other is the descriptor received with FFA_MEM_RETRIEVE_RESP, I believe this is where you've run into trouble. From OP-TEE point of view, it would make sense if you took lead on implementing this. I can help with review etc. Thanks, Jens > > Thanks a lot for your support. > > Regards, > Yuye. > > > > > > ------------------------------------------------------------------ > 发件人：Olivier Deprez <Olivier.Deprez(a)arm.com> > 发送时间：2023年4月13日(星期四) 15:52 > 收件人：梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> > 抄送：hafnium <hafnium(a)lists.trustedfirmware.org>; Jens Wiklander <jens.wiklander(a)linaro.org> > 主题：Re: fragment transmission while retrieving memory > > Hi Yuye, Jens, > > For the record, and If I understand properly the last comment in the github issue: > OP-TEE is missing the implementation for receipt of a fragmented retrieve response > There is no further fix to be done in Hafnium for this specific issue at this moment, please let me know otherwise. > > Thanks, Olivier. > > > ________________________________ > From: 梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> > Sent: 12 April 2023 09:27 > To: Olivier Deprez <Olivier.Deprez(a)arm.com> > Cc: hafnium <hafnium(a)lists.trustedfirmware.org>; Jens Wiklander <jens.wiklander(a)linaro.org> > Subject: Re: fragment transmission while retrieving memory > > > > > Hi, Olivier, > > In our setup, > Hafnium commit: 997476a74571aec4f1a23590d45edf516f3934f4 > optee version: 3.20.0 > Thanks. > > Regards, > Yuye. > > ------------------------------------------------------------------ > 发件人：Olivier Deprez <Olivier.Deprez(a)arm.com> > 发送时间：2023年4月12日(星期三) 15:22 > 收件人：梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> > 抄送：hafnium <hafnium(a)lists.trustedfirmware.org>; Jens Wiklander <jens.wiklander(a)linaro.org> > 主题：Re: fragment transmission while retrieving memory > > Hi Yuye, > > AFAIK concerning Hafnium, fragmented mem sharing is supported for FFA_MEM_SHARE/LEND/DONATE and FFA_MEM_RETRIEVE_RESP. > (For the sake of clarity, this isn't supported for FFA_MEM_RETRIEVE_REQ but this shouldn't be a concern as this limitation only exists in the case of mem sharing to multiple borrowers. In your case of a single borrower the mem retrieve req. shouldn't have to be fragmented). > > Can you tell which hafnium commit hash is used in your setup? > > At the moment, I cannot tell if the issue described concern a miss in Hafnium or OP-TEE. > I need to dig a bit further into both implementations and I'll let you know. > > Regards, > Olivier. > > > ________________________________ > From: 梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> > Sent: 12 April 2023 08:21 > To: Olivier Deprez <Olivier.Deprez(a)arm.com> > Cc: hafnium <hafnium(a)lists.trustedfirmware.org>; Jens Wiklander <jens.wiklander(a)linaro.org> > Subject: fragment transmission while retrieving memory > > > > > Hi, Olivier, > > Recently, I've been working on this issue. > https://github.com/OP-TEE/optee_os/issues/5943 <https://github.com/OP-TEE/optee_os/issues/5943 > > Do you know any differences between hafnium's current implementation of fragment transmission while retrieving memory and the example process described in FF-A 1.1 Figure 18.4? > > Regards, > Yuye. > >

2 years, 9 months

1
0
0 0

OP-TEE 3.21.0 has been released

by Jérôme Forissier

Hi, I'm pleased to announce that OP-TEE version 3.21.0 is now available. The list of changes can be found in the changelog [1]. A blog post will be published soon on trustedfirmware.org [2]. A big thank you to everyone who participated with contributions and helping out with testing the release [3]. [1] https://github.com/OP-TEE/optee_os/blob/master/CHANGELOG.md [2] https://www.trustedfirmware.org/blog/ [3] https://github.com/OP-TEE/optee_os/commit/e8abbcfbdf63437a640d5fd87b7e191ca… Regards, -- Jerome

2 years, 9 months

1
0
0 0

fragment transmission while retrieving memory

by 梅建强(禹夜)

Hi, Jens, Olivier, Is it possible to solve this problem by increasing the buffer size such as 64k? We plan to adopt this temporary scheme first and then implement the standard retrieve process later. If this scheme is feasible, I have a few questions. 1. Should the RXTX buffer between tee driver and hafnium the same as the one between hafnium and optee? 2. Which FFA instance is currently allocating these buffers? 3. For Hafnium, I want to increase the HF_MAILBOX_SIZE in Hafnium, but there seem to be two restrictions: static_assert(HF_MAILBOX_SIZE == PAGE_SIZE, "Currently, a page is mapped for the send and receive buffers so " "the maximum request is the size of a page."); static_assert(MM_PPOOL_ENTRY_SIZE >= HF_MAILBOX_SIZE, "The page pool entry size must be at least as big as the mailbox " "size, so that memory region descriptors can be copied from the " "mailbox for memory sharing."); I tried to increase the MM_PPOOL_ENTRY_SIZE, but optee doesn't seem to be booted properly. Do you know how to avoid the impact of these restrictions? Regards, Yuye. ------------------------------------------------------------------ 发件人：Jens Wiklander via Hafnium <hafnium(a)lists.trustedfirmware.org> 发送时间：2023年4月14日(星期五) 14:23 收件人：梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> 抄　送：Olivier Deprez <Olivier.Deprez(a)arm.com>; hafnium <hafnium(a)lists.trustedfirmware.org>; op-tee <op-tee(a)lists.trustedfirmware.org> 主　题：[Hafnium] Re: fragment transmission while retrieving memory Hi Yuye, On Fri, Apr 14, 2023 at 4:29 AM 梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> wrote: > > > Hi, Jens, Olivier, > > If I understand properly, for this specific issue both optee and hafnium need to do further fix. > The following discussion and questions are based on figure 18.4 in the FFA spec. > > As I saw in the optee code, the retrieve mechanism would start with this code: > retrieve_desc = spmc_retrieve_req(cookie); > And in the function spmc_retrieve_req, > optee sets the total length to the same size as fragment0 length before sending FFA_MEM_FRAG_REQ to hafnium, > which means hafnium will only retrieve the fragment0 memory region. > > In the example process, > optee will determines the number of TX sized fragments of descriptor before sending FFA_MEM_FRAG_REQ to hafnium. > I have a question here. > How should optee calculate this quantity? > > Hafnium then receives the FFA_MEM_FRAG_REQ. > As I saw in the hafnium code, hafnium blocks the case that total length>fragment length. > if (fragment_length != length) { > dlog_verbose("Fragmentation not yet supported.\n"); > return ffa_error(FFA_INVALID_PARAMETERS); > } > Obviously it is not what we expected. > Then following the example process, hafnium should allocate handle and use it to associate fragments. > I didn't find the corresponding implementation in hafnium code for this step. > And I want to know how to implement the associate action here. > > After that, optee lacks the implementation of FFA_MEM_FRAG_RX and FFA_MEM_FRAG_TX ABI in CFG_CORE_SEL2_SPMC enable case. > Is there any support plan for the implementation of fragmented memory retrieve in the optee community? > Does the hafnium community have a plan to implement it cooperatively? If I've understood this correctly we have two different cases of eventual fragmentation of descriptors. The first is the descriptor passed with FFA_MEM_RETRIEVE_REQ_32, this one is not likely to need fragmentation support soon. The other is the descriptor received with FFA_MEM_RETRIEVE_RESP, I believe this is where you've run into trouble. From OP-TEE point of view, it would make sense if you took lead on implementing this. I can help with review etc. Thanks, Jens > > Thanks a lot for your support. > > Regards, > Yuye. > > > > > > ------------------------------------------------------------------ > 发件人：Olivier Deprez <Olivier.Deprez(a)arm.com> > 发送时间：2023年4月13日(星期四) 15:52 > 收件人：梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> > 抄送：hafnium <hafnium(a)lists.trustedfirmware.org>; Jens Wiklander <jens.wiklander(a)linaro.org> > 主题：Re: fragment transmission while retrieving memory > > Hi Yuye, Jens, > > For the record, and If I understand properly the last comment in the github issue: > OP-TEE is missing the implementation for receipt of a fragmented retrieve response > There is no further fix to be done in Hafnium for this specific issue at this moment, please let me know otherwise. > > Thanks, Olivier. > > > ________________________________ > From: 梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> > Sent: 12 April 2023 09:27 > To: Olivier Deprez <Olivier.Deprez(a)arm.com> > Cc: hafnium <hafnium(a)lists.trustedfirmware.org>; Jens Wiklander <jens.wiklander(a)linaro.org> > Subject: Re: fragment transmission while retrieving memory > > > > > Hi, Olivier, > > In our setup, > Hafnium commit: 997476a74571aec4f1a23590d45edf516f3934f4 > optee version: 3.20.0 > Thanks. > > Regards, > Yuye. > > ------------------------------------------------------------------ > 发件人：Olivier Deprez <Olivier.Deprez(a)arm.com> > 发送时间：2023年4月12日(星期三) 15:22 > 收件人：梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> > 抄送：hafnium <hafnium(a)lists.trustedfirmware.org>; Jens Wiklander <jens.wiklander(a)linaro.org> > 主题：Re: fragment transmission while retrieving memory > > Hi Yuye, > > AFAIK concerning Hafnium, fragmented mem sharing is supported for FFA_MEM_SHARE/LEND/DONATE and FFA_MEM_RETRIEVE_RESP. > (For the sake of clarity, this isn't supported for FFA_MEM_RETRIEVE_REQ but this shouldn't be a concern as this limitation only exists in the case of mem sharing to multiple borrowers. In your case of a single borrower the mem retrieve req. shouldn't have to be fragmented). > > Can you tell which hafnium commit hash is used in your setup? > > At the moment, I cannot tell if the issue described concern a miss in Hafnium or OP-TEE. > I need to dig a bit further into both implementations and I'll let you know. > > Regards, > Olivier. > > > ________________________________ > From: 梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> > Sent: 12 April 2023 08:21 > To: Olivier Deprez <Olivier.Deprez(a)arm.com> > Cc: hafnium <hafnium(a)lists.trustedfirmware.org>; Jens Wiklander <jens.wiklander(a)linaro.org> > Subject: fragment transmission while retrieving memory > > > > > Hi, Olivier, > > Recently, I've been working on this issue. > https://github.com/OP-TEE/optee_os/issues/5943 <https://github.com/OP-TEE/optee_os/issues/5943 > > Do you know any differences between hafnium's current implementation of fragment transmission while retrieving memory and the example process described in FF-A 1.1 Figure 18.4? > > Regards, > Yuye. > > -- Hafnium mailing list -- hafnium(a)lists.trustedfirmware.org To unsubscribe send an email to hafnium-leave(a)lists.trustedfirmware.org

2 years, 9 months

2
1
0 0

Re: fragment transmission while retrieving memory

by 梅建强(禹夜)

Hi, Jens, Olivier, If I understand properly, for this specific issue both optee and hafnium need to do further fix. The following discussion and questions are based on figure 18.4 in the FFA spec. As I saw in the optee code, the retrieve mechanism would start with this code: retrieve_desc = spmc_retrieve_req(cookie); And in the function spmc_retrieve_req, optee sets the total length to the same size as fragment0 length before sending FFA_MEM_FRAG_REQ to hafnium, which means hafnium will only retrieve the fragment0 memory region. In the example process, optee will determines the number of TX sized fragments of descriptor before sending FFA_MEM_FRAG_REQ to hafnium. I have a question here. How should optee calculate this quantity? Hafnium then receives the FFA_MEM_FRAG_REQ. As I saw in the hafnium code, hafnium blocks the case that total length>fragment length. if (fragment_length != length) { dlog_verbose("Fragmentation not yet supported.\n"); return ffa_error(FFA_INVALID_PARAMETERS); } Obviously it is not what we expected. Then following the example process, hafnium should allocate handle and use it to associate fragments. I didn't find the corresponding implementation in hafnium code for this step. And I want to know how to implement the associate action here. After that, optee lacks the implementation of FFA_MEM_FRAG_RX and FFA_MEM_FRAG_TX ABI in CFG_CORE_SEL2_SPMC enable case. Is there any support plan for the implementation of fragmented memory retrieve in the optee community? Does the hafnium community have a plan to implement it cooperatively? Thanks a lot for your support. Regards, Yuye. ------------------------------------------------------------------ 发件人：Olivier Deprez <Olivier.Deprez(a)arm.com> 发送时间：2023年4月13日(星期四) 15:52 收件人：梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> 抄　送：hafnium <hafnium(a)lists.trustedfirmware.org>; Jens Wiklander <jens.wiklander(a)linaro.org> 主　题：Re: fragment transmission while retrieving memory Hi Yuye, Jens, For the record, and If I understand properly the last comment in the github issue: OP-TEE is missing the implementation for receipt of a fragmented retrieve response There is no further fix to be done in Hafnium for this specific issue at this moment, please let me know otherwise. Thanks, Olivier. From: 梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> Sent: 12 April 2023 09:27 To: Olivier Deprez <Olivier.Deprez(a)arm.com> Cc: hafnium <hafnium(a)lists.trustedfirmware.org>; Jens Wiklander <jens.wiklander(a)linaro.org> Subject: Re: fragment transmission while retrieving memory Hi, Olivier, In our setup, Hafnium commit: 997476a74571aec4f1a23590d45edf516f3934f4 optee version: 3.20.0 Thanks. Regards, Yuye. ------------------------------------------------------------------ 发件人：Olivier Deprez <Olivier.Deprez(a)arm.com> 发送时间：2023年4月12日(星期三) 15:22 收件人：梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> 抄　送：hafnium <hafnium(a)lists.trustedfirmware.org>; Jens Wiklander <jens.wiklander(a)linaro.org> 主　题：Re: fragment transmission while retrieving memory Hi Yuye, AFAIK concerning Hafnium, fragmented mem sharing is supported for FFA_MEM_SHARE/LEND/DONATE and FFA_MEM_RETRIEVE_RESP. (For the sake of clarity, this isn't supported for FFA_MEM_RETRIEVE_REQ but this shouldn't be a concern as this limitation only exists in the case of mem sharing to multiple borrowers. In your case of a single borrower the mem retrieve req. shouldn't have to be fragmented). Can you tell which hafnium commit hash is used in your setup? At the moment, I cannot tell if the issue described concern a miss in Hafnium or OP-TEE. I need to dig a bit further into both implementations and I'll let you know. Regards, Olivier. From: 梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> Sent: 12 April 2023 08:21 To: Olivier Deprez <Olivier.Deprez(a)arm.com> Cc: hafnium <hafnium(a)lists.trustedfirmware.org>; Jens Wiklander <jens.wiklander(a)linaro.org> Subject: fragment transmission while retrieving memory Hi, Olivier, Recently, I've been working on this issue. https://github.com/OP-TEE/optee_os/issues/5943 <https://github.com/OP-TEE/optee_os/issues/5943 > Do you know any differences between hafnium's current implementation of fragment transmission while retrieving memory and the example process described in FF-A 1.1 Figure 18.4? Regards, Yuye.

2 years, 9 months

2
1
0 0

Preparing for OP-TEE 3.21.0

by Jérôme Forissier

[BCC all OP-TEE maintainers] Hi OP-TEE maintainers & contributors, OP-TEE v3.21.0 is scheduled to be released on 2023-04-14. So, now is a good time to start testing the master branch on the various platforms and report/fix any bugs. The GitHub pull request for collecting Tested-by tags or any other comments is https://github.com/OP-TEE/optee_os/pull/5908 As usual, we will create a release candidate tag one week before the release date for final testing. In addition to that you can find some additional information related to releases here: https://optee.readthedocs.io/en/latest/general/releases.html Thanks, -- Jerome

2 years, 10 months

1
1
0 0

Linaro OP-TEE Contribution (LOC) monthly meeting in April is cancelled

by Joakim Bech

Hi, April's LOC meeting overlaps with Linaro Connect [1], hence we're unable to run the meeting and therefore the meeting will be cancelled. For people attending Linaro Connect. Jens, Jerome and myself will host an OP-TEE Open Hour where we encourage anyone who would like to discuss OP-TEE to show up in person. The OP-TEE Open Hour takes place Thursday 27th, 12.00-1:00 UK time in meeting room 2. [1] https://www.linaro.org/connect -- Regards, Joakim on behalf of the OP-TEE team

2 years, 10 months

1
0
0 0

[GIT PULL] OP-TEE load for v6.4

by Jens Wiklander

Hello arm-soc maintainers, Please pull this patch to enable loading of OP-TEE by the kernel. This feature is by default disabled and should probably always be so since it requires a quite specific security model to be secure. Thanks, Jens The following changes since commit eeac8ede17557680855031c6f305ece2378af326: Linux 6.3-rc2 (2023-03-12 16:36:44 -0700) are available in the Git repository at: https://git.linaro.org/people/jens.wiklander/linux-tee.git tags/optee-load-for-v6.4 for you to fetch changes up to f3040daab8104ac68e2b241bc93288f63b88a3c7: tee: optee: Add SMC for loading OP-TEE image (2023-04-03 08:57:49 +0200) ---------------------------------------------------------------- Add SMC for OP-TEE image loading Adds an SMC call for loading OP-TEE by the kernel. ---------------------------------------------------------------- Jeffrey Kardatzke (1): tee: optee: Add SMC for loading OP-TEE image Documentation/staging/tee.rst | 53 ++++++++++++++++ drivers/tee/optee/Kconfig | 17 ++++++ drivers/tee/optee/optee_msg.h | 12 ++++ drivers/tee/optee/optee_smc.h | 24 ++++++++ drivers/tee/optee/smc_abi.c | 137 ++++++++++++++++++++++++++++++++++++++++++ 5 files changed, 243 insertions(+)

2 years, 10 months

1
0
0 0

[PATCH v13] tee: optee: Add SMC for loading OP-TEE image

by Jeffrey Kardatzke

Adds an SMC call that will pass an OP-TEE binary image to EL3 and instruct it to load it as the BL32 payload. This works in conjunction with a feature added to Trusted Firmware for ARMv8 and above architectures that supports this. The main purpose of this change is to facilitate updating the OP-TEE component on devices via a rootfs change rather than having to do a firmware update. Further details are linked to in the Kconfig file. Signed-off-by: Jeffrey Kardatzke <jkardatzke(a)chromium.org> Reviewed-by: Sumit Garg <sumit.garg(a)linaro.org> Signed-off-by: Jeffrey Kardatzke <jkardatzke(a)google.com> --- Changes in v13: - Documentation formatting changes Changes in v12: - Fixed checkpatch strict issues Changes in v11: - Fixed typo in tee.rst documentation Changes in v10: - Fixed tee.rst documentation formatting Changes in v9: - Add CPU hotplug callback to init on all cores at startup Changes in v8: - Renamed params and fixed alignment issue Changes in v7: - Added documentation to Documentation/staging/tee.rst Changes in v6: - Expanded Kconfig documentation Changes in v5: - Renamed config option - Added runtime warning when config is used Changes in v4: - Update commit message - Added more documentation - Renamed config option, added ARM64 dependency Changes in v3: - Removed state tracking for driver reload - Check UID of service to verify it needs image load Changes in v2: - Fixed compile issue when feature is disabled - Addressed minor comments - Added state tracking for driver reload Documentation/staging/tee.rst | 53 +++++++++++++ drivers/tee/optee/Kconfig | 17 +++++ drivers/tee/optee/optee_msg.h | 12 +++ drivers/tee/optee/optee_smc.h | 24 ++++++ drivers/tee/optee/smc_abi.c | 137 ++++++++++++++++++++++++++++++++++ 5 files changed, 243 insertions(+) diff --git a/Documentation/staging/tee.rst b/Documentation/staging/tee.rst index 498343c7ab08..22baa077a3b9 100644 --- a/Documentation/staging/tee.rst +++ b/Documentation/staging/tee.rst @@ -214,6 +214,57 @@ call is done from the thread assisting the interrupt handler. This is a building block for OP-TEE OS in secure world to implement the top half and bottom half style of device drivers. +OPTEE_INSECURE_LOAD_IMAGE Kconfig option +---------------------------------------- + +The OPTEE_INSECURE_LOAD_IMAGE Kconfig option enables the ability to load the +BL32 OP-TEE image from the kernel after the kernel boots, rather than loading +it from the firmware before the kernel boots. This also requires enabling the +corresponding option in Trusted Firmware for Arm. The Trusted Firmware for Arm +documentation [8] explains the security threat associated with enabling this as +well as mitigations at the firmware and platform level. + +There are additional attack vectors/mitigations for the kernel that should be +addressed when using this option. + +1. Boot chain security. + + * Attack vector: Replace the OP-TEE OS image in the rootfs to gain control of + the system. + + * Mitigation: There must be boot chain security that verifies the kernel and + rootfs, otherwise an attacker can modify the loaded OP-TEE binary by + modifying it in the rootfs. + +2. Alternate boot modes. + + * Attack vector: Using an alternate boot mode (i.e. recovery mode), the + OP-TEE driver isn't loaded, leaving the SMC hole open. + + * Mitigation: If there are alternate methods of booting the device, such as a + recovery mode, it should be ensured that the same mitigations are applied + in that mode. + +3. Attacks prior to SMC invocation. + + * Attack vector: Code that is executed prior to issuing the SMC call to load + OP-TEE can be exploited to then load an alternate OS image. + + * Mitigation: The OP-TEE driver must be loaded before any potential attack + vectors are opened up. This should include mounting of any modifiable + filesystems, opening of network ports or communicating with external + devices (e.g. USB). + +4. Blocking SMC call to load OP-TEE. + + * Attack vector: Prevent the driver from being probed, so the SMC call to + load OP-TEE isn't executed when desired, leaving it open to being executed + later and loading a modified OS. + + * Mitigation: It is recommended to build the OP-TEE driver as builtin driver + rather than as a module to prevent exploits that may cause the module to + not be loaded. + AMD-TEE driver ============== @@ -309,3 +360,5 @@ References [6] include/linux/psp-tee.h [7] drivers/tee/amdtee/amdtee_if.h + +[8] https://trustedfirmware-a.readthedocs.io/en/latest/threat_model/threat_mode… diff --git a/drivers/tee/optee/Kconfig b/drivers/tee/optee/Kconfig index f121c224e682..70898bbd5809 100644 --- a/drivers/tee/optee/Kconfig +++ b/drivers/tee/optee/Kconfig @@ -7,3 +7,20 @@ config OPTEE help This implements the OP-TEE Trusted Execution Environment (TEE) driver. + +config OPTEE_INSECURE_LOAD_IMAGE + bool "Load OP-TEE image as firmware" + default n + depends on OPTEE && ARM64 + help + This loads the BL32 image for OP-TEE as firmware when the driver is + probed. This returns -EPROBE_DEFER until the firmware is loadable from + the filesystem which is determined by checking the system_state until + it is in SYSTEM_RUNNING. This also requires enabling the corresponding + option in Trusted Firmware for Arm. The documentation there explains + the security threat associated with enabling this as well as + mitigations at the firmware and platform level. + https://trustedfirmware-a.readthedocs.io/en/latest/threat_model/threat_mode… + + Additional documentation on kernel security risks are at + Documentation/staging/tee.rst. diff --git a/drivers/tee/optee/optee_msg.h b/drivers/tee/optee/optee_msg.h index 70e9cc2ee96b..e8840a82b983 100644 --- a/drivers/tee/optee/optee_msg.h +++ b/drivers/tee/optee/optee_msg.h @@ -241,11 +241,23 @@ struct optee_msg_arg { * 384fb3e0-e7f8-11e3-af63-0002a5d5c51b. * Represented in 4 32-bit words in OPTEE_MSG_UID_0, OPTEE_MSG_UID_1, * OPTEE_MSG_UID_2, OPTEE_MSG_UID_3. + * + * In the case where the OP-TEE image is loaded by the kernel, this will + * initially return an alternate UID to reflect that we are communicating with + * the TF-A image loading service at that time instead of OP-TEE. That UID is: + * a3fbeab1-1246-315d-c7c4-06b9c03cbea4. + * Represented in 4 32-bit words in OPTEE_MSG_IMAGE_LOAD_UID_0, + * OPTEE_MSG_IMAGE_LOAD_UID_1, OPTEE_MSG_IMAGE_LOAD_UID_2, + * OPTEE_MSG_IMAGE_LOAD_UID_3. */ #define OPTEE_MSG_UID_0 0x384fb3e0 #define OPTEE_MSG_UID_1 0xe7f811e3 #define OPTEE_MSG_UID_2 0xaf630002 #define OPTEE_MSG_UID_3 0xa5d5c51b +#define OPTEE_MSG_IMAGE_LOAD_UID_0 0xa3fbeab1 +#define OPTEE_MSG_IMAGE_LOAD_UID_1 0x1246315d +#define OPTEE_MSG_IMAGE_LOAD_UID_2 0xc7c406b9 +#define OPTEE_MSG_IMAGE_LOAD_UID_3 0xc03cbea4 #define OPTEE_MSG_FUNCID_CALLS_UID 0xFF01 /* diff --git a/drivers/tee/optee/optee_smc.h b/drivers/tee/optee/optee_smc.h index 73b5e7760d10..7d9fa426505b 100644 --- a/drivers/tee/optee/optee_smc.h +++ b/drivers/tee/optee/optee_smc.h @@ -104,6 +104,30 @@ struct optee_smc_call_get_os_revision_result { unsigned long reserved1; }; +/* + * Load Trusted OS from optee/tee.bin in the Linux firmware. + * + * WARNING: Use this cautiously as it could lead to insecure loading of the + * Trusted OS. + * This SMC instructs EL3 to load a binary and execute it as the Trusted OS. + * + * Call register usage: + * a0 SMC Function ID, OPTEE_SMC_CALL_LOAD_IMAGE + * a1 Upper 32bit of a 64bit size for the payload + * a2 Lower 32bit of a 64bit size for the payload + * a3 Upper 32bit of the physical address for the payload + * a4 Lower 32bit of the physical address for the payload + * + * The payload is in the OP-TEE image format. + * + * Returns result in a0, 0 on success and an error code otherwise. + */ +#define OPTEE_SMC_FUNCID_LOAD_IMAGE 2 +#define OPTEE_SMC_CALL_LOAD_IMAGE \ + ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, ARM_SMCCC_SMC_32, \ + ARM_SMCCC_OWNER_TRUSTED_OS_END, \ + OPTEE_SMC_FUNCID_LOAD_IMAGE) + /* * Call with struct optee_msg_arg as argument * diff --git a/drivers/tee/optee/smc_abi.c b/drivers/tee/optee/smc_abi.c index a1c1fa1a9c28..6e1f023d50c6 100644 --- a/drivers/tee/optee/smc_abi.c +++ b/drivers/tee/optee/smc_abi.c @@ -7,10 +7,13 @@ #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt #include <linux/arm-smccc.h> +#include <linux/cpuhotplug.h> #include <linux/errno.h> +#include <linux/firmware.h> #include <linux/interrupt.h> #include <linux/io.h> #include <linux/irqdomain.h> +#include <linux/kernel.h> #include <linux/mm.h> #include <linux/module.h> #include <linux/of.h> @@ -1149,6 +1152,22 @@ static bool optee_msg_api_uid_is_optee_api(optee_invoke_fn *invoke_fn) return false; } +#ifdef CONFIG_OPTEE_INSECURE_LOAD_IMAGE +static bool optee_msg_api_uid_is_optee_image_load(optee_invoke_fn *invoke_fn) +{ + struct arm_smccc_res res; + + invoke_fn(OPTEE_SMC_CALLS_UID, 0, 0, 0, 0, 0, 0, 0, &res); + + if (res.a0 == OPTEE_MSG_IMAGE_LOAD_UID_0 && + res.a1 == OPTEE_MSG_IMAGE_LOAD_UID_1 && + res.a2 == OPTEE_MSG_IMAGE_LOAD_UID_2 && + res.a3 == OPTEE_MSG_IMAGE_LOAD_UID_3) + return true; + return false; +} +#endif + static void optee_msg_get_os_revision(optee_invoke_fn *invoke_fn) { union { @@ -1354,6 +1373,120 @@ static void optee_shutdown(struct platform_device *pdev) optee_disable_shm_cache(optee); } +#ifdef CONFIG_OPTEE_INSECURE_LOAD_IMAGE + +#define OPTEE_FW_IMAGE "optee/tee.bin" + +static optee_invoke_fn *cpuhp_invoke_fn; + +static int optee_cpuhp_probe(unsigned int cpu) +{ + /* + * Invoking a call on a CPU will cause OP-TEE to perform the required + * setup for that CPU. Just invoke the call to get the UID since that + * has no side effects. + */ + if (optee_msg_api_uid_is_optee_api(cpuhp_invoke_fn)) + return 0; + else + return -EINVAL; +} + +static int optee_load_fw(struct platform_device *pdev, + optee_invoke_fn *invoke_fn) +{ + const struct firmware *fw = NULL; + struct arm_smccc_res res; + phys_addr_t data_pa; + u8 *data_buf = NULL; + u64 data_size; + u32 data_pa_high, data_pa_low; + u32 data_size_high, data_size_low; + int rc; + int hp_state; + + if (!optee_msg_api_uid_is_optee_image_load(invoke_fn)) + return 0; + + rc = request_firmware(&fw, OPTEE_FW_IMAGE, &pdev->dev); + if (rc) { + /* + * The firmware in the rootfs will not be accessible until we + * are in the SYSTEM_RUNNING state, so return EPROBE_DEFER until + * that point. + */ + if (system_state < SYSTEM_RUNNING) + return -EPROBE_DEFER; + goto fw_err; + } + + data_size = fw->size; + /* + * This uses the GFP_DMA flag to ensure we are allocated memory in the + * 32-bit space since TF-A cannot map memory beyond the 32-bit boundary. + */ + data_buf = kmalloc(fw->size, GFP_KERNEL | GFP_DMA); + if (!data_buf) { + rc = -ENOMEM; + goto fw_err; + } + memcpy(data_buf, fw->data, fw->size); + data_pa = virt_to_phys(data_buf); + reg_pair_from_64(&data_pa_high, &data_pa_low, data_pa); + reg_pair_from_64(&data_size_high, &data_size_low, data_size); + goto fw_load; + +fw_err: + pr_warn("image loading failed\n"); + data_pa_high = 0; + data_pa_low = 0; + data_size_high = 0; + data_size_low = 0; + +fw_load: + /* + * Always invoke the SMC, even if loading the image fails, to indicate + * to EL3 that we have passed the point where it should allow invoking + * this SMC. + */ + pr_warn("OP-TEE image loaded from kernel, this can be insecure"); + invoke_fn(OPTEE_SMC_CALL_LOAD_IMAGE, data_size_high, data_size_low, + data_pa_high, data_pa_low, 0, 0, 0, &res); + if (!rc) + rc = res.a0; + if (fw) + release_firmware(fw); + kfree(data_buf); + + if (!rc) { + /* + * We need to initialize OP-TEE on all other running cores as + * well. Any cores that aren't running yet will get initialized + * when they are brought up by the power management functions in + * TF-A which are registered by the OP-TEE SPD. Due to that we + * can un-register the callback right after registering it. + */ + cpuhp_invoke_fn = invoke_fn; + hp_state = cpuhp_setup_state(CPUHP_AP_ONLINE_DYN, "optee:probe", + optee_cpuhp_probe, NULL); + if (hp_state < 0) { + pr_warn("Failed with CPU hotplug setup for OP-TEE"); + return -EINVAL; + } + cpuhp_remove_state(hp_state); + cpuhp_invoke_fn = NULL; + } + + return rc; +} +#else +static inline int optee_load_fw(struct platform_device *pdev, + optee_invoke_fn *invoke_fn) +{ + return 0; +} +#endif + static int optee_probe(struct platform_device *pdev) { optee_invoke_fn *invoke_fn; @@ -1372,6 +1505,10 @@ static int optee_probe(struct platform_device *pdev) if (IS_ERR(invoke_fn)) return PTR_ERR(invoke_fn); + rc = optee_load_fw(pdev, invoke_fn); + if (rc) + return rc; + if (!optee_msg_api_uid_is_optee_api(invoke_fn)) { pr_warn("api uid mismatch\n"); return -EINVAL; -- 2.40.0.348.gf938b09366-goog

2 years, 10 months

3
2
0 0

2026

2025

2024

2023

2022

2021

2020

OP-TEE