- TF-M - lists.trustedfirmware.org

Re: [TF-M] IRQ handling by Secure Partitions proposal

by DeMars, Alan

Miklos, Thank you for those clarifications. Sorry it's taken so long to reply. I think I now have a basic grasp of how interrupts owned by SPs are managed. Regarding item 4) below, what is the proposal for informing a calling NS thread that a service request can't complete until some future asynchronous event (ie a peripheral interrupt) occurs? Will this be in the form of special psa_call() return codes or is the SP expected to use outvecs to convey that information? How will the calling thread know when the service request can be completed? The idea of a dedicated non-secure interrupt that the SP/SPM triggers has been mentioned several times. Some kind of asynchronous callback dispatcher as hinted at in the "Concurrent secure service requests" paragraph here: https://developer.trustedfirmware.org/w/tf_m/design/ns_client_management/ Is this mechanism being designed by TFM or is this functionality going to be left to the various users of the reference PSA implementation? Should I begin designing this myself? I guess the overarching question is, does the PSA proposal support secure peripheral drivers, and if so, how? Alan -----Original Message----- From: TF-M [mailto:tf-m-bounces@lists.trustedfirmware.org] On Behalf Of Miklos Balint via TF-M Sent: Tuesday, February 05, 2019 8:02 AM To: tf-m(a)lists.trustedfirmware.org Cc: nd Subject: [EXTERNAL] Re: [TF-M] IRQ handling by Secure Partitions proposal Hi Alan, 0, One thing to point out is that my proposal only covers the "Library" or function-call-based model that was the only one implemented on TF-M master branch at the time of writing. PSA Firmware Framework v1.0 with its IPC mechanism has its own design of how interrupts are supposed to be handled by secure threads - my proposal intends to complement that with the same functionality for the other operating model. This clarification addresses point 5 as well, I believe. 1, SPM "Acknowledges the interrupt": this is not the best wording. Actually this is very bad wording. What I meant to say is that SPM's own interrupt handler is started - which is a hardware action, not one by SPM - and SPM ISR in turn masks the interrupt line in NVIC. As you rightly point out, the peripheral itself is of no concern to SPM, that's the business for partition code, either in its own Partition ISR, or a service function. 2. This means that secure PSP is saved for the pre-empted context, set to the stack of the partition that's the owner of the interrupt line, and any additional housekeeping associated with a context switch (PSPLIM setup, isolation re-configuration, privilege setting - all according to the properties of the partition that is to be activated). Lastly, a mock context is created on the partition stack so that the Partition ISR can be activated with an exception return from the SPM ISR. 3a. The Partition ISR is activated by SPM ISR by doing an exception return to the start address of e.g. UART1_ISR() function. In order for this TF-M first needs to create the mock context mentioned in my point 2. The discussion of the stack frame in the text is meant to clarify that there are two possibilities that need to be considered: if the partition is idle, i.e. there are no ongoing service requests in its context, its stack pointer is either at a default value or - potentially - there's no stack associated with the partition. In that case a stack frame needs to be initialized and the mock context set up there. If the partition is handling a request, its original stack pointer needs to be used as the start address for the mock context used for exception return. 3b. After execution of the Partition ISR, execution is returned to the SPM ISR. At this point, SPM can decide to either re-activate the original context that had been pre-empted by the interrupt, or, can take a scheduling decision to activate a different context, e.g. the partition that had called psa_wait(). 4. The current implementation does not allow for the pre-emption of a secure context by non-secure scheduling events, but that is a limitation that could likely be lifted depending on some basic policies that have to be set up by the system integrator. In such a case the NS thread would be blocked waiting on the completion of the secure service, but a pre-emptive NS OS could schedule a different thread if the time slice of the caller thread runs out. Other options are subject to investigation at this point. ... Please let me know if any of the points I've addressed provide clarity instead of making the design more obscure, in which case I would update the design proposal with the extra information. :) And of course let me know if you have further questions. Regards Miklos -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of DeMars, Alan via TF-M Sent: 02 February 2019 04:29 To: tf-m(a)lists.trustedfirmware.org Subject: [Tf-m] IRQ handling by Secure Partitions proposal Regarding the "SPM behavior" discussion in the "Secure Partition Interrupt Handling" proposal: 1) What is meant by the SPM "Acknowledges the interrupt"? I understand "masks the hardware interrupt line" but I don't see how the SPM can know how to acknowledge a particular peripheral's interrupt. I think acknowledging the interrupt should be done by the "Partition ISR" dedicated to the interrupt, or within the corresponding SP's main loop upon return from psa_wait(). 2) What does "Sets up execution environment for the secure partition" mean, precisely? 3) Can you expand on the "Execute Partition ISR" paragraph a little? I assume you mean that, for instance, the registered UART1_isr() function is called. The discussion of the ISR stack frame I don't really follow. And from the description, I'm not sure when the SP is scheduled to run again to deal with the ISR it was waiting for. 4) A secure partition that depends on an interrupt begs the question of what happens to the NS thread that has called into the SP requesting some service that depends on a subsequent asynchronous event (ISR) to complete the request. The psa_call() function as currently implemented doesn't "block" in the traditional OS sense (ie the thread's context and state are not saved in a manner that allows another task thread to run while the psa_call() is stalled in the SPM waiting for an ISR. 5) The details of SP thread pre-emption and re-entrancy need to be described. Alan -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 2 months

1
0
0 0

interrupts not supported on feature-ipc branch?

by DeMars, Alan

I guess interrupts are only supported on the master branch. When will the master branch support PSA IPC? Or, when will the feature-ipc branch support interrupts? Alan

5 years, 2 months

1
0
0 0

SYSTICK ownership

by DeMars, Alan

If not used anywhere else, can a Secure Partition own the secure SYSTICK timer and its interrupt? If so, how is it specified in the SP manifest? Alan

5 years, 2 months

1
0
0 0

Musca-A SAU setup issues

by Thomas Törnblom

I am working on porting TF-M to the IAR Embedded Workbench for ARM (EWARM) toolchain and I'm having some issues getting it to start properly. I started out using the ARM.TFM.1.1.0, ARM.Musca_A1_BSP.2.0.0, ARM.mbedTLS.1.3.1 and ARM.CMSIS.5.5.0-dev2 CMSIS packs and I've had to fix things in all of the packs to make the project build with our compiler, some things just to add our tools, some things that were just gcc:isms that are non standard-C. The TF-M code is based on a snapshot of https://git.trustedfirmware.org/trusted-firmware-m.git repository of the following hash: 5c1756fbab6097f5688583d11dea5d1271d2d774 I know that some of these packs are old and I'm also working on a port of the bits on trustedfirmware.org, but I would like to bring the old version up first. The (current) issue I have is that the NS code region becomes inaccessible from the secure part after setting the SAU up and I assume I am missing something. in tfm_core_init() there are calls to: --- tfm_spm_hal_init_isolation_hw(); configure_ns_code(); --- tfm_spm_hal_init_isolation_hw() calls sau_and_idau_cfg(), which sets up: --- /* Configures SAU regions to be non-secure */ SAU->RNR = TFM_NS_REGION_CODE; SAU->RBAR = (memory_regions.non_secure_partition_base & SAU_RBAR_BADDR_Msk); SAU->RLAR = (memory_regions.non_secure_partition_limit & SAU_RLAR_LADDR_Msk) | SAU_RLAR_ENABLE_Msk; --- After this piece is run, the NS vector table becomes all zeros when viewed from secure mode. This causes the configure_ns_code() call above to fail to pick up the ns_msp and ns_entry addresses, they become 0. If I swap the calls around so they become: --- configure_ns_code(); tfm_spm_hal_init_isolation_hw(); --- then ns_msp and ns_entry are picked up OK. How is this supposed to work? When the SAU is setup I get RAZ/WI when accessing NS memory from S mode, the other way around results is a security violation, which is properly handled by the SecureFault_Handler(). What am I missing? I run into other problems later, but that may very well a consequence of earlier issues. Thanks, /Thomas -- *Thomas Törnblom*, /Product Engineer/ IAR Systems AB Box 23051, Strandbodgatan 1 SE-750 23 Uppsala, SWEDEN Mobile: +46 76 180 17 80 Fax: +46 18 16 78 01 E-mail: thomas.tornblom(a)iar.com <mailto:thomas.tornblom@iar.com> Website: www.iar.com <http://www.iar.com> Twitter: www.twitter.com/iarsystems <http://www.twitter.com/iarsystems>

5 years, 2 months

1
0
0 0

Re: [TF-M] SPM crashes when built with any non zero optimization level

by Gyorgy Szing

Hi Alan, Please check this ticket https://developer.trustedfirmware.org/T234 Is it possible you are affected by the same issue? /George -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of DeMars, Alan via TF-M Sent: 14 February 2019 06:59 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] SPM crashes when built with any non zero optimization level Is anyone else having the problem that enabling optimizations when building the secure image causes the secure partition manager to crash when entered through any of the psa_xxx() IPC veneers? Using GCC -O1, -O2, or -O3 compile options, something seems to go wrong with the SVC context. Everything behaves correctly when built with no optimizations. Alan -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

5 years, 2 months

1
0
0 0

SPM crashes when built with any non zero optimization level

by DeMars, Alan

Is anyone else having the problem that enabling optimizations when building the secure image causes the secure partition manager to crash when entered through any of the psa_xxx() IPC veneers? Using GCC -O1, -O2, or -O3 compile options, something seems to go wrong with the SVC context. Everything behaves correctly when built with no optimizations. Alan

5 years, 2 months

1
0
0 0

Re: [TF-M] [EXTERNAL] Re: Clarification of pre-existing TFM secure service alignment with PSA APIs

by DeMars, Alan

Ken, Thank you confirming my understanding. The new NS interface code in those commits clearly demonstrate the underlying calls to psa_connect(), psa_call(), and psa_close(). Alan > On Feb 11, 2019, at 6:38 PM, Ken Liu (Arm Technology China) via TF-M <tf-m(a)lists.trustedfirmware.org> wrote: > > Hi Alan, > After PSA IPC model takes place, existing services need to be modified to support it. > The action is not a re-implement actually. The basic idea is creating an IPC SP body > and calls existing secure service functions. There are also some commits for reference: > https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/473/ > https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/474/ > > There are IPC compatible items in roadmap reflects the plan: > https://developer.trustedfirmware.org/w/tf_m/planning/ > > Thanks > > -Ken > >> -----Original Message----- >> From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of DeMars, >> Alan via TF-M >> Sent: Tuesday, February 12, 2019 9:39 AM >> To: tf-m(a)lists.trustedfirmware.org >> Subject: [TF-M] Clarification of pre-existing TFM secure service alignment with >> PSA APIs >> >> Is my understanding correct that the existing set of secure services (audit, crypto, >> sst, etc) that use the "Library" or function-call-based-model to enter the SPE are >> being redesigned to conform to the PSA IPC model, meaning that each service >> will be re-implemented as a SP with a forever loop? >> >> If so, does this mean that the existing set of NS-facing APIs associated with each >> secure service will be re-implemented as libraries that funnel all of their calls >> into the SPE through the 3 PSA IPC calls (psa_connect(), psa_call(), and >> psa_close())? >> >> Alan >> -- >> TF-M mailing list >> TF-M(a)lists.trustedfirmware.org >> https://lists.trustedfirmware.org/mailman/listinfo/tf-m > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 2 months

1
0
0 0

Re: [TF-M] tz_context APIs

by DeMars, Alan

I'm thinking that the real concern is that the caller should be in 'privileged mode' rather than specifically in handler mode. Is this correct? If so, perhaps the caller's mode check can be converted to affirm 'privileged mode' rather than handler mode. If not, I don't understand what additional security is gained by being in handler mode. Alan -----Original Message----- From: TF-M [mailto:tf-m-bounces@lists.trustedfirmware.org] On Behalf Of Miklos Balint via TF-M Sent: Wednesday, February 13, 2019 6:47 AM To: tf-m(a)lists.trustedfirmware.org Cc: nd Subject: [EXTERNAL] Re: [TF-M] tz_context APIs One fundamental reason for driving context changes from handler mode is to have privilege and isolation control when switching contexts. So it all boils down to the requirements of a particular deployment. If there is no compartmentalization and privilege control in NSPE, i.e. all NS threads and the OS have identical access policies to secure assets, it should be possible to lift this requirement and accept NSPE context change notifications that transition from NSPE to SPE in thread mode. This, however, only results in a performance improvement if SPE also bypasses handler mode for this operation, requiring slightly more than skin-deep modifications in TF-M to handle all possible (ab)uses of the secure context management feature. I think this can be a valid choice for a specific implementation, but support for this as a configuration switch in the upstream and threat modelling the alternate setting would be a stretch in our team's current roadmap. /M -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of DeMars, Alan via TF-M Sent: 13 February 2019 05:11 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] tz_context APIs Why do all the APIs declared in tz_context.h need to be called from NS Handler mode? Is this a hard requirement or can it be configured 'OFF'? For performance reasons, our OS doesn't trap into handler mode to perform thread management like creation, scheduling, and context switching. Having to switch to handler mode without a very compelling reason seems like unnecessary overhead in performance-critical code. Alan -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 2 months

1
0
0 0

Re: [TF-M] [Tf-m] [EXTERNAL] Re: Non-secure Client Management

by DeMars, Alan

Hi Miklos, Thank you for the roadmap info. I’ll check this out and provide feedback in a separate email. Yes, my concern is regarding the few dozen cycles of overhead. No, this is not a major limitation but it does seem needlessly wasteful to me. I think your proposal to alter the behavior of TZ_LoadContext_S as you suggest is an excellent idea. My understanding of the TZ_LoadContext_S semantics is “until the next TZ_LoadContext_S call, all calls into the SPM will be from this context”. If that is a correct understanding, then assuming the previously active MemoryId should be stored seems like a safe and always true inference. Alan > On Feb 7, 2019, at 2:42 AM, Miklos Balint via TF-M <tf-m(a)lists.trustedfirmware.org> wrote: > > Hi Alan, > > https://developer.trustedfirmware.org/w/tf_m/planning/ has a roadmap of planned feature support by calendar quarter. NSPM for the thread-based design is not explicitly highlighted but I would expect it to be implemented as part of the Q2 SPM work or Q3 Scheduler work the latest. > Any feedback on that or any other aspect of the roadmap is very welcome so we can take that into account when updating the plans. > > For the TZ functions, please note that these are not proprietary to TF-M but form a standard CMSIS API, a generic RTOS feature for TrustZone-enabled devices: > https://www.keil.com/pack/doc/CMSIS/Core/html/group__context__trustzone__fu… > > Since these calls are direct function calls between NSPE and SPE, the overhead should be in the order of a few dozen clock cycles each, not much more than regular RTOS context switch hooks that would be available in several RTOSes. > Are you concerned that this overhead is a major limitation? > > If so, one enhancement TF-M could provide to support a simplified non-CMSIS-compliant NSPE RTOS implementation is for TZ_LoadContext_S to implement the functionality you described for "SwitchContext", taking only the new MemoryId as argument - the old id is stored in the NSPM database anyway, so the context to be Stored in this case can be inferred by TF-M. If the new context is not secure-accessing, FreeContext can be used as defined by CMSIS. > This way TF-M does not introduce proprietary new functions for functionality already defined by the standard. > Please note that this solution would still need to be analysed for security implications as TF-M would be making additional assumptions on NSPE state - although I don't see a reason for concern at this point. > > /M > > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of DeMars, Alan via TF-M > Sent: 03 February 2019 15:18 > To: Ken Liu (Arm Technology China) <Ken.Liu(a)arm.com> > Cc: nd <nd(a)arm.com>; tf-m(a)lists.trustedfirmware.org > Subject: Re: [Tf-m] [EXTERNAL] Re: Non-secure Client Management > > Ken, > > Thank you for your prompt response. Please see my replies below. > > Alan > >> Hi Alan, >> The proposed APIs are implemented for library mode. It will not work under IPC mode in 'feature-ipc' branch. The support of NSPM for IPC will come later. > > Is their a feature rollout schedule that I can follow? > >> The TZ_LoadContext_S() and TZ_StoreContext_S() need to be called every time while secure service accessed NS thread get entering/leaving. It is not combined into one function, because not all NS threads need to access secure service. For those NS threads which do not need to access secure service, these TZ_ APIs are unnecessary to be called. For example, if NS scheduler switches from one secure service accessed thread into the other generic thread, only TZ_StoreContext_S() needs to be called before context switching. > > To avoid the rather burdensome overhead of calling into the SPM twice on those NS context switches in which either the leaving or entering contexts are secure accessing threads, I propose that a NULL TZ_MemoryId_t be defined so that a single TZ_SwitchContext_S() function with two TZ_MemoryId_t arguments can be called. The NULL TZ_MemoryId_t would be passed to identify an entering or leaving context that is not secure accessing. > >> The method of blocking the caller client is based on scenarios. If there are some 'wait' is necessary while secure service is working (waiting for secure hardware IRQ as an example), the method you mentioned may be involved (special return value with an NS IRQ notification). This functionality is not in place right now. >> >> -Ken >> >>> -----Original Message----- >>> From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of >>> DeMars, Alan via TF-M >>> Sent: Sunday, February 3, 2019 9:17 AM >>> To: tf-m(a)lists.trustedfirmware.org >>> Subject: [Tf-m] Non-secure Client Management >>> >>> Regarding the Non-secure Client Management proposal: >>> >>> >>> https://developer.trustedfirmware.org/w/tf_m/design/ns_client_managem >>> ent/ >>> >>> I notice that the veneers for the proposed APIs are in s_veneers.o. >>> Does this mean that the proposal has been adopted and implemented? Is >>> it functional in the current feature-ipc branch? >>> >>> I have a question about the TZ_LoadContext_S() and TZ_StoreContext_S() APIs: >>> Is it expected that each context switch in the NS world will be >>> signaled by calls to each of these APIs indicating the "entering" >>> context and "leaving" context respectively? If so, then why not >>> collapse these two APIs into one called >>> TZ_SwitchContext__S() and pass both the "entering" and "leaving" >>> TZ_MemoryId_t's as arguments? >>> >>> Or is TZ_StoreContext_S() only to be called when a NS context will >>> never call into the SPM again? If that is the case, why isn't >>> TZ_FreeModuleContext_S() sufficient? >>> >>> Regarding the "Concurrent secure service requests" discussion, what >>> does "a non-secure client is blocked on an asynchronous secure service completion"? >>> Would this be achieved by a special return status from psa_call() >>> indicating that the current service request is in process and will >>> complete later on? The psa_call() calling thread would then block on >>> a semaphore that would be released by a dedicated NS IRQ interrupt? Is any of this functionality in place yet? >>> >>> Alan > > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 2 months

2
1
0 0

Re: [TF-M] [Tf-m] [EXTERNAL] Re: Non-secure Client Management

by DeMars, Alan

Miklos, In regards to the roadmap, just to confirm my understanding, does the "[TF-M Core] Interrupt Handling Enhancements" bullet due in Q1`19 refer to the interrupt support as described in section 3.4 "Secure peripheral drivers" of the PSA Firmware Framework document? When will SP pre-emption and blocking be supported? A secure peripheral driver that doesn't allow the NS thread to block while waiting for something to complete is a non-starter for us. As well, a SP thread that can't be pre-empted by a higher priority NS thread is almost as unpalatable for us. Alan -----Original Message----- From: TF-M [mailto:tf-m-bounces@lists.trustedfirmware.org] On Behalf Of Miklos Balint via TF-M Sent: Thursday, February 07, 2019 2:43 AM To: tf-m(a)lists.trustedfirmware.org Cc: nd Subject: Re: [TF-M] [Tf-m] [EXTERNAL] Re: Non-secure Client Management Hi Alan, https://developer.trustedfirmware.org/w/tf_m/planning/ has a roadmap of planned feature support by calendar quarter. NSPM for the thread-based design is not explicitly highlighted but I would expect it to be implemented as part of the Q2 SPM work or Q3 Scheduler work the latest. Any feedback on that or any other aspect of the roadmap is very welcome so we can take that into account when updating the plans. For the TZ functions, please note that these are not proprietary to TF-M but form a standard CMSIS API, a generic RTOS feature for TrustZone-enabled devices: https://www.keil.com/pack/doc/CMSIS/Core/html/group__context__trustzone__fu… Since these calls are direct function calls between NSPE and SPE, the overhead should be in the order of a few dozen clock cycles each, not much more than regular RTOS context switch hooks that would be available in several RTOSes. Are you concerned that this overhead is a major limitation? If so, one enhancement TF-M could provide to support a simplified non-CMSIS-compliant NSPE RTOS implementation is for TZ_LoadContext_S to implement the functionality you described for "SwitchContext", taking only the new MemoryId as argument - the old id is stored in the NSPM database anyway, so the context to be Stored in this case can be inferred by TF-M. If the new context is not secure-accessing, FreeContext can be used as defined by CMSIS. This way TF-M does not introduce proprietary new functions for functionality already defined by the standard. Please note that this solution would still need to be analysed for security implications as TF-M would be making additional assumptions on NSPE state - although I don't see a reason for concern at this point. /M -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of DeMars, Alan via TF-M Sent: 03 February 2019 15:18 To: Ken Liu (Arm Technology China) <Ken.Liu(a)arm.com> Cc: nd <nd(a)arm.com>; tf-m(a)lists.trustedfirmware.org Subject: Re: [Tf-m] [EXTERNAL] Re: Non-secure Client Management Ken, Thank you for your prompt response. Please see my replies below. Alan > Hi Alan, > The proposed APIs are implemented for library mode. It will not work under IPC mode in 'feature-ipc' branch. The support of NSPM for IPC will come later. Is their a feature rollout schedule that I can follow? > The TZ_LoadContext_S() and TZ_StoreContext_S() need to be called every time while secure service accessed NS thread get entering/leaving. It is not combined into one function, because not all NS threads need to access secure service. For those NS threads which do not need to access secure service, these TZ_ APIs are unnecessary to be called. For example, if NS scheduler switches from one secure service accessed thread into the other generic thread, only TZ_StoreContext_S() needs to be called before context switching. To avoid the rather burdensome overhead of calling into the SPM twice on those NS context switches in which either the leaving or entering contexts are secure accessing threads, I propose that a NULL TZ_MemoryId_t be defined so that a single TZ_SwitchContext_S() function with two TZ_MemoryId_t arguments can be called. The NULL TZ_MemoryId_t would be passed to identify an entering or leaving context that is not secure accessing. > The method of blocking the caller client is based on scenarios. If there are some 'wait' is necessary while secure service is working (waiting for secure hardware IRQ as an example), the method you mentioned may be involved (special return value with an NS IRQ notification). This functionality is not in place right now. > > -Ken > >> -----Original Message----- >> From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of >> DeMars, Alan via TF-M >> Sent: Sunday, February 3, 2019 9:17 AM >> To: tf-m(a)lists.trustedfirmware.org >> Subject: [Tf-m] Non-secure Client Management >> >> Regarding the Non-secure Client Management proposal: >> >> >> https://developer.trustedfirmware.org/w/tf_m/design/ns_client_managem >> ent/ >> >> I notice that the veneers for the proposed APIs are in s_veneers.o. >> Does this mean that the proposal has been adopted and implemented? Is >> it functional in the current feature-ipc branch? >> >> I have a question about the TZ_LoadContext_S() and TZ_StoreContext_S() APIs: >> Is it expected that each context switch in the NS world will be >> signaled by calls to each of these APIs indicating the "entering" >> context and "leaving" context respectively? If so, then why not >> collapse these two APIs into one called >> TZ_SwitchContext__S() and pass both the "entering" and "leaving" >> TZ_MemoryId_t's as arguments? >> >> Or is TZ_StoreContext_S() only to be called when a NS context will >> never call into the SPM again? If that is the case, why isn't >> TZ_FreeModuleContext_S() sufficient? >> >> Regarding the "Concurrent secure service requests" discussion, what >> does "a non-secure client is blocked on an asynchronous secure service completion"? >> Would this be achieved by a special return status from psa_call() >> indicating that the current service request is in process and will >> complete later on? The psa_call() calling thread would then block on >> a semaphore that would be released by a dedicated NS IRQ interrupt? Is any of this functionality in place yet? >> >> Alan -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 2 months

2
1
0 0

2024

2023

2022

2021

2020

2019

2018

TF-M