- TF-M - lists.trustedfirmware.org

[twin-cpu]Dual core communication design document for review

by David Hu (Arm Technology China)

Hi all, I've posted a design document for dual core communication in twin cpu project. Could you please review it at https://developer.trustedfirmware.org/w/tf_m/design/twin-cpu/communication_… Any comment is welcome. Thank you. Best regards, Hu Ziji

7 years, 3 months

2
4
0 0

[RFC] Isolation level 2 patches

by Ken Liu (Arm Technology China)

Hi, The isolation level 2 patches are pushed for reviewing; you can find all of them under the issue: https://developer.trustedfirmware.org/T294 The design document was put at: https://developer.trustedfirmware.org/w/tf_m/design/trusted_firmware-m_isol… The first group of patches are working on AN521 with ARMCLANG build. Rest options supporting would come later. With higher isolation level, some functions may not work such as CLIB (malloc/free e.g.). These features need to be supported after dedicated implementation is done. You can check the [RFC] discussion sent in mailing list of the isolation level 2 for details. Isolation level 2 use dedicated config file: "ConfigCoreIPCTfmLevel2.cmake" so the IPC on isolation level 1 is not affected by this change. Please help to comment in documents and patches - current the document has no comment area so you can put comments under the issue link, or just reply in mailing list. Creating issues is another valid options ; ) Thanks! -Ken

7 years, 3 months

1
0
0 0

Re: [TF-M] [EXTERNAL] Re: Please explain tfm_register_client_id() use case

by DeMars, Alan

Yes, that idea would resolve the problem. I’m not sure I understand the use case for multiple updates to a context’s client Id. What is the thought behind that? Alan > On Mar 28, 2019, at 2:23 AM, Miklos Balint via TF-M <tf-m(a)lists.trustedfirmware.org> wrote: > > Alan, > > You are absolutely right that registering client ID should normally be done once, preferably right after AllocModule. > > The current design allows multiple updates to be made, and for this to be possible, we identify the one to be updated by it being the active one. > > I do see an opportunity to extend this so that the last NS context to be Allocated can also be assumed to be the target of a registration in lieu of the active context if there isn't one. > This way we keep the option to update ID when a context is active while also allow an easy and low overhead registration for the context that's latest to have been Allocated. > > Is this an acceptable amendment? > > Regards > Miklos > > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of DeMars, Alan via TF-M > Sent: 26 March 2019 00:00 > To: tf-m(a)lists.trustedfirmware.org > Subject: [TF-M] Please explain tfm_register_client_id() use case > > As currently specified, I don't see a simple way to invoke the tfm_register_client_id() API ONLY ONCE for each NS client thread. > > It appears that tfm_register_client_id() must be called after TZ_LoadContext_S() because the clientId provided by tfm_register_client_id() is always associated with the CURRENT NS MemoryId. > > However, TZ_LoadContext_S() is designed to be called only when the NS OS actually switches to a new NS thread. This creates pressure for tfm_register_client_id() to be called during a NS thread switch. However, calling tfm_register_client_id() on EVERY NS context switch is redundant and CPU wasteful. Adding code to test whether tfm_register_client_id() has already been called for a particular NS thread also seems wasteful. > > What seems natural to me is to add a MemoryId argument to tfm_register_client_id() so that the clientID can be mapped to the MemoryId provided by TZ_AllocModuleContext_S() right after TZ_AllocModuleContext_S() is called (ie only once). > > Please correct my understanding of how tfm_register_client_id() is intended to be used if the above analysis is off base. > > 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

7 years, 3 months

2
1
0 0

Re: [TF-M] [RFC] twin cpu bootloader design document

by David Hu (Arm Technology China)

Hi Chris, Sorry for the delayed reply. Please check my comments in below. Just about small details. Please correct me if I misunderstand anything. 1. In my own opinion, it can be possible to use IPC to synchronize mailbox services between two cores, during initialization. The synchronization is only trigged when the mailbox mechanism is ready on mailbox server or client. It means that the IPC module should be also configured. Based on the above assumption, using IPC to synchronize the two cores is more generic and convenient than accessing shared memory. If using shared memory to pass status flag, it can be necessary to adjust the address of the shared memory occasionally according to the memory assignment in different applications. 2. I'd like to suggest that we shall discuss more about when the booting HAL APIs are invoked in TF-M. `tfm_core_init()` initializes the TF-M core. Thus in theory, `tfm_core_init()` is irrelevant to the system topology or platform implementations. As a result, IMO, it can be more reasonable to put the HAL APIs outside the `tfm_core_init()`. 3. ` tfm_spm_hal_wait_for_ns_cpu_ready()` can be optional. The secure core acts as a server and it is driven by the request from NS core. The secure core actually doesn't have to wait for an explicit signal to know NS is ready. The synchronization can be guaranteed if NS core starts request via mailbox only after secure core is available. 4. It can be unnecessary to require calling `tfm_spm_hal_wait_for_s_cpu_ready()` in NS `main()`. It might be too early to wait in `main()` and may block other initializations which don't rely on mailbox. This API can be invoked in mailbox functionalities. The whole NS initialization can continue, including enabling application threads, until a NS application requests Secure services via mailbox at the very first time. Thus the whole dual core design can be more generic since the mailbox workflow should be identical on diverse platforms. And we can save the time and effort to hack each RTOS initialization. In other words, I wonder if we can make calling `tfm_spm_hal_wait_for_s_cpu_ready()` in NS `main() as an option and allow other implementations. Thank you. Best regards, Hu Ziji -------------------------------------------------------------------------------------------------------------- Date: Thu, 14 Mar 2019 18:50:56 +0000 From: Christopher Brand <chris.brand(a)cypress.com> To: "tf-m(a)lists.trustedfirmware.org" <tf-m(a)lists.trustedfirmware.org> Subject: [TF-M] [RFC] twin cpu bootloader design document Message-ID: <BYAPR06MB5301EBF02F4C0B60A9BB7742FE4B0(a)BYAPR06MB5301.namprd06.prod.outlook.com> Content-Type: text/plain; charset="us-ascii" Hi, I've posted a design document for bootloader changes to support twin cpu at https://developer.trustedfirmware.org/w/tf_m/design/twin-cpu/bootloader/ Comments appreciated! Thanks, Chris

7 years, 3 months

3
7
0 0

proposed change in Musca B1

by Tamas Kaman

Hi All, I'd like to notify everyone about a proposed change in Musca B1 platform in TF-M. Everyone who is using that platform might be affected. The code on Musca B1 is currently running from the external QSPI flash. With the coming change this moves to a much faster internal embedded Flash, so all you might observe is faster code execution. Link to review: https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/669/ Also, for loading the image to the a board another version of DAPLink FW will be needed. The eFlash type DAPLink FW can be downloaded from Arm Community page: https://community.arm.com/developer/tools-software/oss-platforms/w/docs/425… A short description of how to update the DAPLink FW can be found here as well. Thanks, Tamas 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.

7 years, 3 months

1
0
0 0

Re: [TF-M] Please explain tfm_register_client_id() use case

by Miklos Balint

Alan, You are absolutely right that registering client ID should normally be done once, preferably right after AllocModule. The current design allows multiple updates to be made, and for this to be possible, we identify the one to be updated by it being the active one. I do see an opportunity to extend this so that the last NS context to be Allocated can also be assumed to be the target of a registration in lieu of the active context if there isn't one. This way we keep the option to update ID when a context is active while also allow an easy and low overhead registration for the context that's latest to have been Allocated. Is this an acceptable amendment? Regards Miklos -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of DeMars, Alan via TF-M Sent: 26 March 2019 00:00 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] Please explain tfm_register_client_id() use case As currently specified, I don't see a simple way to invoke the tfm_register_client_id() API ONLY ONCE for each NS client thread. It appears that tfm_register_client_id() must be called after TZ_LoadContext_S() because the clientId provided by tfm_register_client_id() is always associated with the CURRENT NS MemoryId. However, TZ_LoadContext_S() is designed to be called only when the NS OS actually switches to a new NS thread. This creates pressure for tfm_register_client_id() to be called during a NS thread switch. However, calling tfm_register_client_id() on EVERY NS context switch is redundant and CPU wasteful. Adding code to test whether tfm_register_client_id() has already been called for a particular NS thread also seems wasteful. What seems natural to me is to add a MemoryId argument to tfm_register_client_id() so that the clientID can be mapped to the MemoryId provided by TZ_AllocModuleContext_S() right after TZ_AllocModuleContext_S() is called (ie only once). Please correct my understanding of how tfm_register_client_id() is intended to be used if the above analysis is off base. Alan -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

7 years, 3 months

1
0
0 0

Re: [TF-M] SYSTICK ownership

by Ken Liu (Arm Technology China)

Hi Alan, Sorry for the late response - the secure IRQ patches are on the way but currently we don't have scenarios for this case. We would create a ticket for tracking this question and let's collect comment there. And, this topic sounds like a timer requirement, so can you tell the actual user scenario? For example, would there still be requirements of using SYSTICK in secure partition if some timer things is available? Thanks. -Ken -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of DeMars, Alan via TF-M Sent: 19 February 2019 02:47 To: Ken Liu (Arm Technology China) <Ken.Liu(a)arm.com<mailto:Ken.Liu@arm.com>> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>>; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: Re: [TF-M] SYSTICK ownership My concern was the value one would provide for the "line_num" field within the manifest. The SYSTICK uses vector 15 which I believe would correspond to "line_num" = -1. I'm not sure the design accommodates negative line_nums. Also, disabling the SYSTICK interrupt while servicing its interrupt can't be handled in the normal way user IRQs are disabled. Special case code would be required in the SPM to support the SYSTICK as a secure partition interrupt. Alan -----Original Message----- From: TF-M [mailto:tf-m-bounces@lists.trustedfirmware.org] On Behalf Of Ken Liu (Arm Technology China) via TF-M Sent: Monday, February 18, 2019 5:34 PM To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Cc: nd Subject: [EXTERNAL] Re: [TF-M] SYSTICK ownership Hi Alan, >From your description, it looks like you want to use secure SYSTICK as an interrupt for Secure Partition, is this correct? In this case, it is similar to the secure interrupt usage. Since the interrupt handling is under developing, I will add a note in the task to remind how we could add SYSTICK as an interrupt in the manifest. BR -Ken > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of > DeMars, Alan via TF-M > Sent: Saturday, February 16, 2019 7:02 AM > To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> > Subject: [TF-M] SYSTICK ownership > > 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 > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org<mailto:TF-M@lists.trustedfirmware.org> > https://lists.trustedfirmware.org/mailman/listinfo/tf-m

7 years, 3 months

1
0
0 0

Re: [TF-M] TFM Core regression tests

by Andrej Butok

Hi Mate, OK. It's good to know that this is the known issue. I will wait for a final review and merge. Thanks, Andrej -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Mate Toth-Pal via TF-M Sent: Wednesday, March 27, 2019 2:45 PM To: TF-M(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] TFM Core regression tests Hi Andrej, Yes, on the master branch this is a limitation. I already have a few patches on review to fix this: https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr… https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr… They are most probably going to be merged with the secure IRQ handling commits. You can also cherry pick those for yourself for testing purposes, there should be no conflict, as it is quite independent from the parent commits on review. Regards, Mate -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M Sent: 27 March 2019 14:32 To: TF-M(a)lists.trustedfirmware.org Subject: [TF-M] TFM Core regression tests Hello We are trying to enable & compile TFM Core tests. But it looks like they are only for MPS2 platform: 1) tfm_ss_core_test.c: .... #include "smm_mps2.h" ... static psa_status_t test_peripheral_access(void) { struct arm_mps2_fpgaio_t *fpgaio = SEC_MPS2_FPGAIO; ... etc. 2) tfm_partition_list.inc ... #ifdef TFM_PARTITION_TEST_CORE ... PARTITION_ADD_PERIPHERAL(TFM_SP_CORE_TEST, TFM_PERIPHERAL_FPGA_IO); #endif /* TFM_PARTITION_TEST_CORE */ ... What do you suggest ? What is the plan? Should we to skip/ignore the TFM Core regression tests now? Thanks Andrej Butok SW Tech Lead Security & Connectivity, Microcontrollers NXP Semiconductors -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru…

7 years, 3 months

1
0
0 0

Re: [TF-M] TFM Core regression tests

by Mate Toth-Pal

Hi Andrej, Yes, on the master branch this is a limitation. I already have a few patches on review to fix this: https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/693/10 https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/683/11 They are most probably going to be merged with the secure IRQ handling commits. You can also cherry pick those for yourself for testing purposes, there should be no conflict, as it is quite independent from the parent commits on review. Regards, Mate -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M Sent: 27 March 2019 14:32 To: TF-M(a)lists.trustedfirmware.org Subject: [TF-M] TFM Core regression tests Hello We are trying to enable & compile TFM Core tests. But it looks like they are only for MPS2 platform: 1) tfm_ss_core_test.c: .... #include "smm_mps2.h" ... static psa_status_t test_peripheral_access(void) { struct arm_mps2_fpgaio_t *fpgaio = SEC_MPS2_FPGAIO; ... etc. 2) tfm_partition_list.inc ... #ifdef TFM_PARTITION_TEST_CORE ... PARTITION_ADD_PERIPHERAL(TFM_SP_CORE_TEST, TFM_PERIPHERAL_FPGA_IO); #endif /* TFM_PARTITION_TEST_CORE */ ... What do you suggest ? What is the plan? Should we to skip/ignore the TFM Core regression tests now? Thanks Andrej Butok SW Tech Lead Security & Connectivity, Microcontrollers NXP Semiconductors -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

7 years, 3 months

1
0
0 0

TFM Core regression tests

by Andrej Butok

Hello We are trying to enable & compile TFM Core tests. But it looks like they are only for MPS2 platform: 1) tfm_ss_core_test.c: .... #include "smm_mps2.h" ... static psa_status_t test_peripheral_access(void) { struct arm_mps2_fpgaio_t *fpgaio = SEC_MPS2_FPGAIO; ... etc. 2) tfm_partition_list.inc ... #ifdef TFM_PARTITION_TEST_CORE ... PARTITION_ADD_PERIPHERAL(TFM_SP_CORE_TEST, TFM_PERIPHERAL_FPGA_IO); #endif /* TFM_PARTITION_TEST_CORE */ ... What do you suggest ? What is the plan? Should we to skip/ignore the TFM Core regression tests now? Thanks Andrej Butok SW Tech Lead Security & Connectivity, Microcontrollers NXP Semiconductors

7 years, 3 months

1
0
0 0

Re: [TF-M] [RFC] Design document of isolation level 2 on TF-M

by Andrej Butok

Thank you, Antonio Looking forward for the 100% Crypto Service usage, it will solve the mbedTLS duplication issue. -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Antonio De Angelis via TF-M Sent: Tuesday, March 26, 2019 4:37 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] [RFC] Design document of isolation level 2 on TF-M Hi, Regarding the below: > Why the TFM services (SST, attestation) do not call PSA Crypto API? Attestation already calls the PSA Crypto APIs, and we are working actively on implementing the crypto bindings for SST to call the corresponding PSA Crypto API's. Thanks, Antonio -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Wang (Arm Technology China) via TF-M Sent: 26 March 2019 08:18 To: tf-m(a)lists.trustedfirmware.org; Ken Liu (Arm Technology China) <Ken.Liu(a)arm.com> Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] [RFC] Design document of isolation level 2 on TF-M Hi Andrej, Yes, I agree this is a useful design to mitigate the code size issue. Just sharing the advice from security perspective. Basically, we need to review the shared libs carefully(one of the focus of threat modelling). It's not a mandatory limit. From PSA FF spec v1.0 beta1 section 3.1.4 (Mandatory isolation rules) and 3.1.5 (Optional isolation rules), it's OK to have the shared RO code sections. It doesn't break the mandatory isolation rule I3 - If domain A needs protection from domain B, then Private data in domain A cannot be accessed by domain B. But it's worth to notice/mention that this will break optional isolation rules I4 and I5. I4 - If domain A needs protection from domain B, then Code and Constant data in domain A is not readable or executable by domain B. I5 - Code in a domain is not executable by any other domain. It makes sense to give the choice to the users. (may notify the user about the potential security risk) > Why the TFM services (SST, attestation) do not call PSA Crypto API? I think the experts of the modules might be more suitable than me to answer this question. 😊 Thanks. Hi @Ken Liu (Arm Technology China), I got your reply in another thread, so just to gather them here. >For first point, we can take a security analysis on this part and check if there are vulnerabilities. >The security requirement for these code are quite high, you can take 'memset' as example, it is read-only, caller stack based so no footprint would leave to another caller. Yes, like I mentioned above it's one of the focus of threat modelling. >For seconds point, it is do-able -- but need big change everywhere; and it back to the per-partition library design while we move to isolation level 3. Understand. Just thinking if we can keep the shared libs in the same protection domain. (to avoid breaking optional isolation rules) BTW, from PSA FF spec v1.0 beta1 section 3.1.2(memory access rules) rule l1, we may need to consider the separation of RO-Code and RO-data(execution never). Thanks. Regards, David Wang Arm Electronic Technology (Shanghai) Co., Ltd Phone: +86-21-6154 9142 (ext. 59142) -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M Sent: Monday, March 25, 2019 7:04 PM To: TF-M(a)lists.trustedfirmware.org Subject: Re: [TF-M] [RFC] Design document of isolation level 2 on TF-M Hi David, > Using shared libraries may give the window to exploit the vulnerabilities. Yes, you are right. BUT Code size may be a very critical parameter especially for constrained MCUs. Please do not give any mandatory limits. If any, they should be configurable. Let's give a possibility to choose for final users. BTW: 1) Current TF-M is using library approach with mbedTLS copy per each service. OK, security => but wasting of resources. In our code, we are using one copy of mbedTLS to avoid this type of wasting, but it requires original code modification. Please, give more freedom to final TFM users! 2) Why the TFM services (SST, attestation) do not call PSA Crypto API? It will eliminates mbedTLS duplication. Thanks, Andrej -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Wang (Arm Technology China) via TF-M Sent: Monday, March 25, 2019 10:57 AM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] [RFC] Design document of isolation level 2 on TF-M Hi Ken, Some comments from security review's perspective. * Using shared libraries may give the window to exploit the vulnerabilities. App RoT can analyze the shared lib to find out the useable vulnerabilities for attacking PSA RoT. * Is it a good idea to have two separate shared libs - one for all app RoT and one for all PSA RoT for isolation level2? (can still share one copy for level1.) Regards, David Wang Arm Electronic Technology (Shanghai) Co., Ltd Phone: +86-21-6154 9142 (ext. 59142) -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu (Arm Technology China) via TF-M Sent: Monday, March 25, 2019 5:05 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] [RFC] Design document of isolation level 2 on TF-M Hi, The document is updated due to a change in MPU regions part: In original design, some partition libraries like 'thread_exit' is going to be linked with partition statically, which means there would be multiple copies of these libraries for each partition. This provided strict protection of isolation but it looks over-protect. If we keep one shared code region for each partition to call these libraries, we could: * Save memory * The protection is enough if we mark the code area as read-only. In this case, the unprivileged code and RO region needs to be kept and these shared codes could be put there. The requirement of these codes are: * These codes must be thread safe and reentrant * These codes must be put in read-only region The change mainly happen under section "Linker script sections re-arrangement". Please help to comment. Thanks! -Ken > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken > Liu (Arm Technology China) via TF-M > Sent: Thursday, March 21, 2019 3:20 PM > To: tf-m(a)lists.trustedfirmware.org > Cc: nd <nd(a)arm.com> > Subject: Re: [TF-M] [RFC] Design document of isolation level 2 on TF-M > > Hi, > The document is updated, and keep open for comments ; ) > > The updated content is: > > 1. Available MPU regions for peripheral has number limitation based > on platform. If a SP needs many un-continuous peripheral registers and > the number exceeds available MPU number, it needs further investigation. > 2. Rely on linker to clean the unused object files instead of > remove them in scatter before the dependency is fully figured out. > > Thanks! > > -Ken > > From: Ken Liu (Arm Technology China) > Sent: Tuesday, February 19, 2019 6:44 PM > To: tf-m(a)lists.trustedfirmware.org > Cc: nd <nd(a)arm.com> > Subject: [RFC] Design document of isolation level 2 on TF-M > > Hello, > The first IPC implementation works under isolation level 1. The high > isolation levels need to be there to get compatible with PSA Firmware > Framework. A design document is created about implementing isolation level 2 for IPC model: > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdeve > loper.trustedfirmware.org%2Fw%2Ftf_m%2Fdesign%2Ftrusted_firmware-& > data=02%7C01%7Candrey.butok%40nxp.com%7C6a9c2cb6a5034aec48b908d6b10845 > 48%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636891046406628979&amp > ;sdata=yPus0lkd4L71ng5Z5o2hu2bDEMBAzSwUxAm1fyYf564%3D&reserved=0 > m_isolation_level_2/ > > The mainly change of isolation level 2 compare to isolation level 1 is: > * Put AppRoT Secure Partitions' components with same attribute (code, > read- only data, read-write data) into the same region, which helps > MPU setting region attributes. > * Change Secure Partition privileged setting based on Secure Partition > type while scheduling. > * Change mechanism of privileged API, such as printf. > > If you have any comments please share it. You can reply in mailing > list if there is no place for putting comments on the page. > > Thank you! > > -Ken > > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flist > s.trustedfirmware.org%2Fmailman%2Flistinfo%2Ftf-m&data=02%7C01%7Ca > ndrey.butok%40nxp.com%7C6a9c2cb6a5034aec48b908d6b1084548%7C686ea1d3bc2 > b4c6fa92cd99c5c301635%7C0%7C0%7C636891046406638984&sdata=7Wva1R6Lv > EKMxCpaVr6gRE26Fodub%2FPTQlLOiB2YvX0%3D&reserved=0 -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru…

7 years, 3 months

1
0
0 0

Re: [TF-M] [RFC] Design document of isolation level 2 on TF-M

by Antonio De Angelis

Hi, Regarding the below: > Why the TFM services (SST, attestation) do not call PSA Crypto API? Attestation already calls the PSA Crypto APIs, and we are working actively on implementing the crypto bindings for SST to call the corresponding PSA Crypto API's. Thanks, Antonio -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Wang (Arm Technology China) via TF-M Sent: 26 March 2019 08:18 To: tf-m(a)lists.trustedfirmware.org; Ken Liu (Arm Technology China) <Ken.Liu(a)arm.com> Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] [RFC] Design document of isolation level 2 on TF-M Hi Andrej, Yes, I agree this is a useful design to mitigate the code size issue. Just sharing the advice from security perspective. Basically, we need to review the shared libs carefully(one of the focus of threat modelling). It's not a mandatory limit. From PSA FF spec v1.0 beta1 section 3.1.4 (Mandatory isolation rules) and 3.1.5 (Optional isolation rules), it's OK to have the shared RO code sections. It doesn't break the mandatory isolation rule I3 - If domain A needs protection from domain B, then Private data in domain A cannot be accessed by domain B. But it's worth to notice/mention that this will break optional isolation rules I4 and I5. I4 - If domain A needs protection from domain B, then Code and Constant data in domain A is not readable or executable by domain B. I5 - Code in a domain is not executable by any other domain. It makes sense to give the choice to the users. (may notify the user about the potential security risk) > Why the TFM services (SST, attestation) do not call PSA Crypto API? I think the experts of the modules might be more suitable than me to answer this question. 😊 Thanks. Hi @Ken Liu (Arm Technology China), I got your reply in another thread, so just to gather them here. >For first point, we can take a security analysis on this part and check if there are vulnerabilities. >The security requirement for these code are quite high, you can take 'memset' as example, it is read-only, caller stack based so no footprint would leave to another caller. Yes, like I mentioned above it's one of the focus of threat modelling. >For seconds point, it is do-able -- but need big change everywhere; and it back to the per-partition library design while we move to isolation level 3. Understand. Just thinking if we can keep the shared libs in the same protection domain. (to avoid breaking optional isolation rules) BTW, from PSA FF spec v1.0 beta1 section 3.1.2(memory access rules) rule l1, we may need to consider the separation of RO-Code and RO-data(execution never). Thanks. Regards, David Wang Arm Electronic Technology (Shanghai) Co., Ltd Phone: +86-21-6154 9142 (ext. 59142) -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M Sent: Monday, March 25, 2019 7:04 PM To: TF-M(a)lists.trustedfirmware.org Subject: Re: [TF-M] [RFC] Design document of isolation level 2 on TF-M Hi David, > Using shared libraries may give the window to exploit the vulnerabilities. Yes, you are right. BUT Code size may be a very critical parameter especially for constrained MCUs. Please do not give any mandatory limits. If any, they should be configurable. Let's give a possibility to choose for final users. BTW: 1) Current TF-M is using library approach with mbedTLS copy per each service. OK, security => but wasting of resources. In our code, we are using one copy of mbedTLS to avoid this type of wasting, but it requires original code modification. Please, give more freedom to final TFM users! 2) Why the TFM services (SST, attestation) do not call PSA Crypto API? It will eliminates mbedTLS duplication. Thanks, Andrej -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Wang (Arm Technology China) via TF-M Sent: Monday, March 25, 2019 10:57 AM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] [RFC] Design document of isolation level 2 on TF-M Hi Ken, Some comments from security review's perspective. * Using shared libraries may give the window to exploit the vulnerabilities. App RoT can analyze the shared lib to find out the useable vulnerabilities for attacking PSA RoT. * Is it a good idea to have two separate shared libs - one for all app RoT and one for all PSA RoT for isolation level2? (can still share one copy for level1.) Regards, David Wang Arm Electronic Technology (Shanghai) Co., Ltd Phone: +86-21-6154 9142 (ext. 59142) -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu (Arm Technology China) via TF-M Sent: Monday, March 25, 2019 5:05 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] [RFC] Design document of isolation level 2 on TF-M Hi, The document is updated due to a change in MPU regions part: In original design, some partition libraries like 'thread_exit' is going to be linked with partition statically, which means there would be multiple copies of these libraries for each partition. This provided strict protection of isolation but it looks over-protect. If we keep one shared code region for each partition to call these libraries, we could: * Save memory * The protection is enough if we mark the code area as read-only. In this case, the unprivileged code and RO region needs to be kept and these shared codes could be put there. The requirement of these codes are: * These codes must be thread safe and reentrant * These codes must be put in read-only region The change mainly happen under section "Linker script sections re-arrangement". Please help to comment. Thanks! -Ken > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken > Liu (Arm Technology China) via TF-M > Sent: Thursday, March 21, 2019 3:20 PM > To: tf-m(a)lists.trustedfirmware.org > Cc: nd <nd(a)arm.com> > Subject: Re: [TF-M] [RFC] Design document of isolation level 2 on TF-M > > Hi, > The document is updated, and keep open for comments ; ) > > The updated content is: > > 1. Available MPU regions for peripheral has number limitation based > on platform. If a SP needs many un-continuous peripheral registers and > the number exceeds available MPU number, it needs further investigation. > 2. Rely on linker to clean the unused object files instead of > remove them in scatter before the dependency is fully figured out. > > Thanks! > > -Ken > > From: Ken Liu (Arm Technology China) > Sent: Tuesday, February 19, 2019 6:44 PM > To: tf-m(a)lists.trustedfirmware.org > Cc: nd <nd(a)arm.com> > Subject: [RFC] Design document of isolation level 2 on TF-M > > Hello, > The first IPC implementation works under isolation level 1. The high > isolation levels need to be there to get compatible with PSA Firmware > Framework. A design document is created about implementing isolation level 2 for IPC model: > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdeve > loper.trustedfirmware.org%2Fw%2Ftf_m%2Fdesign%2Ftrusted_firmware-& > data=02%7C01%7Candrey.butok%40nxp.com%7C6a9c2cb6a5034aec48b908d6b10845 > 48%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636891046406628979&amp > ;sdata=yPus0lkd4L71ng5Z5o2hu2bDEMBAzSwUxAm1fyYf564%3D&reserved=0 > m_isolation_level_2/ > > The mainly change of isolation level 2 compare to isolation level 1 is: > * Put AppRoT Secure Partitions' components with same attribute (code, > read- only data, read-write data) into the same region, which helps > MPU setting region attributes. > * Change Secure Partition privileged setting based on Secure Partition > type while scheduling. > * Change mechanism of privileged API, such as printf. > > If you have any comments please share it. You can reply in mailing > list if there is no place for putting comments on the page. > > Thank you! > > -Ken > > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flist > s.trustedfirmware.org%2Fmailman%2Flistinfo%2Ftf-m&data=02%7C01%7Ca > ndrey.butok%40nxp.com%7C6a9c2cb6a5034aec48b908d6b1084548%7C686ea1d3bc2 > b4c6fa92cd99c5c301635%7C0%7C0%7C636891046406638984&sdata=7Wva1R6Lv > EKMxCpaVr6gRE26Fodub%2FPTQlLOiB2YvX0%3D&reserved=0 -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… -- 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

7 years, 3 months

1
0
0 0

Re: [TF-M] [RFC] Design document of isolation level 2 on TF-M

by David Wang (Arm Technology China)

Hi Andrej, Yes, I agree this is a useful design to mitigate the code size issue. Just sharing the advice from security perspective. Basically, we need to review the shared libs carefully(one of the focus of threat modelling). It's not a mandatory limit. From PSA FF spec v1.0 beta1 section 3.1.4 (Mandatory isolation rules) and 3.1.5 (Optional isolation rules), it's OK to have the shared RO code sections. It doesn't break the mandatory isolation rule I3 - If domain A needs protection from domain B, then Private data in domain A cannot be accessed by domain B. But it's worth to notice/mention that this will break optional isolation rules I4 and I5. I4 - If domain A needs protection from domain B, then Code and Constant data in domain A is not readable or executable by domain B. I5 - Code in a domain is not executable by any other domain. It makes sense to give the choice to the users. (may notify the user about the potential security risk) > Why the TFM services (SST, attestation) do not call PSA Crypto API? I think the experts of the modules might be more suitable than me to answer this question. 😊 Thanks. Hi @Ken Liu (Arm Technology China), I got your reply in another thread, so just to gather them here. >For first point, we can take a security analysis on this part and check if there are vulnerabilities. >The security requirement for these code are quite high, you can take 'memset' as example, it is read-only, caller stack based so no footprint would leave to another caller. Yes, like I mentioned above it's one of the focus of threat modelling. >For seconds point, it is do-able -- but need big change everywhere; and it back to the per-partition library design while we move to isolation level 3. Understand. Just thinking if we can keep the shared libs in the same protection domain. (to avoid breaking optional isolation rules) BTW, from PSA FF spec v1.0 beta1 section 3.1.2(memory access rules) rule l1, we may need to consider the separation of RO-Code and RO-data(execution never). Thanks. Regards, David Wang Arm Electronic Technology (Shanghai) Co., Ltd Phone: +86-21-6154 9142 (ext. 59142) -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M Sent: Monday, March 25, 2019 7:04 PM To: TF-M(a)lists.trustedfirmware.org Subject: Re: [TF-M] [RFC] Design document of isolation level 2 on TF-M Hi David, > Using shared libraries may give the window to exploit the vulnerabilities. Yes, you are right. BUT Code size may be a very critical parameter especially for constrained MCUs. Please do not give any mandatory limits. If any, they should be configurable. Let's give a possibility to choose for final users. BTW: 1) Current TF-M is using library approach with mbedTLS copy per each service. OK, security => but wasting of resources. In our code, we are using one copy of mbedTLS to avoid this type of wasting, but it requires original code modification. Please, give more freedom to final TFM users! 2) Why the TFM services (SST, attestation) do not call PSA Crypto API? It will eliminates mbedTLS duplication. Thanks, Andrej -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Wang (Arm Technology China) via TF-M Sent: Monday, March 25, 2019 10:57 AM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] [RFC] Design document of isolation level 2 on TF-M Hi Ken, Some comments from security review's perspective. * Using shared libraries may give the window to exploit the vulnerabilities. App RoT can analyze the shared lib to find out the useable vulnerabilities for attacking PSA RoT. * Is it a good idea to have two separate shared libs - one for all app RoT and one for all PSA RoT for isolation level2? (can still share one copy for level1.) Regards, David Wang Arm Electronic Technology (Shanghai) Co., Ltd Phone: +86-21-6154 9142 (ext. 59142) -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu (Arm Technology China) via TF-M Sent: Monday, March 25, 2019 5:05 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] [RFC] Design document of isolation level 2 on TF-M Hi, The document is updated due to a change in MPU regions part: In original design, some partition libraries like 'thread_exit' is going to be linked with partition statically, which means there would be multiple copies of these libraries for each partition. This provided strict protection of isolation but it looks over-protect. If we keep one shared code region for each partition to call these libraries, we could: * Save memory * The protection is enough if we mark the code area as read-only. In this case, the unprivileged code and RO region needs to be kept and these shared codes could be put there. The requirement of these codes are: * These codes must be thread safe and reentrant * These codes must be put in read-only region The change mainly happen under section "Linker script sections re-arrangement". Please help to comment. Thanks! -Ken > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken > Liu (Arm Technology China) via TF-M > Sent: Thursday, March 21, 2019 3:20 PM > To: tf-m(a)lists.trustedfirmware.org > Cc: nd <nd(a)arm.com> > Subject: Re: [TF-M] [RFC] Design document of isolation level 2 on TF-M > > Hi, > The document is updated, and keep open for comments ; ) > > The updated content is: > > 1. Available MPU regions for peripheral has number limitation based > on platform. If a SP needs many un-continuous peripheral registers and > the number exceeds available MPU number, it needs further investigation. > 2. Rely on linker to clean the unused object files instead of > remove them in scatter before the dependency is fully figured out. > > Thanks! > > -Ken > > From: Ken Liu (Arm Technology China) > Sent: Tuesday, February 19, 2019 6:44 PM > To: tf-m(a)lists.trustedfirmware.org > Cc: nd <nd(a)arm.com> > Subject: [RFC] Design document of isolation level 2 on TF-M > > Hello, > The first IPC implementation works under isolation level 1. The high > isolation levels need to be there to get compatible with PSA Firmware > Framework. A design document is created about implementing isolation level 2 for IPC model: > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdeve > loper.trustedfirmware.org%2Fw%2Ftf_m%2Fdesign%2Ftrusted_firmware-& > data=02%7C01%7Candrey.butok%40nxp.com%7C6a9c2cb6a5034aec48b908d6b10845 > 48%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636891046406628979&amp > ;sdata=yPus0lkd4L71ng5Z5o2hu2bDEMBAzSwUxAm1fyYf564%3D&reserved=0 > m_isolation_level_2/ > > The mainly change of isolation level 2 compare to isolation level 1 is: > * Put AppRoT Secure Partitions' components with same attribute (code, > read- only data, read-write data) into the same region, which helps > MPU setting region attributes. > * Change Secure Partition privileged setting based on Secure Partition > type while scheduling. > * Change mechanism of privileged API, such as printf. > > If you have any comments please share it. You can reply in mailing > list if there is no place for putting comments on the page. > > Thank you! > > -Ken > > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flist > s.trustedfirmware.org%2Fmailman%2Flistinfo%2Ftf-m&data=02%7C01%7Ca > ndrey.butok%40nxp.com%7C6a9c2cb6a5034aec48b908d6b1084548%7C686ea1d3bc2 > b4c6fa92cd99c5c301635%7C0%7C0%7C636891046406638984&sdata=7Wva1R6Lv > EKMxCpaVr6gRE26Fodub%2FPTQlLOiB2YvX0%3D&reserved=0 -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

7 years, 3 months

1
0
0 0

Re: [TF-M] [RFC] Design document of isolation level 2 on TF-M

by Ken Liu (Arm Technology China)

Hi, For first point, we can take a security analysis on this part and check if there are vulnerabilities. The security requirement for these code are quite high, you can take 'memset' as example, it is read-only, caller stack based so no footprint would leave to another caller. For seconds point, it is do-able -- but need big change everywhere; and it back to the per-partition library design while we move to isolation level 3. -Ken > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David > Wang (Arm Technology China) via TF-M > Sent: Monday, March 25, 2019 5:57 PM > To: tf-m(a)lists.trustedfirmware.org > Cc: nd <nd(a)arm.com> > Subject: Re: [TF-M] [RFC] Design document of isolation level 2 on TF-M > > Hi Ken, > Some comments from security review's perspective. > * Using shared libraries may give the window to exploit the vulnerabilities. App > RoT can analyze the shared lib to find out the useable vulnerabilities for > attacking PSA RoT. > * Is it a good idea to have two separate shared libs - one for all app RoT and one > for all PSA RoT for isolation level2? (can still share one copy for level1.) > > Regards, > David Wang > Arm Electronic Technology (Shanghai) Co., Ltd > Phone: +86-21-6154 9142 (ext. 59142) > > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu > (Arm Technology China) via TF-M > Sent: Monday, March 25, 2019 5:05 PM > To: tf-m(a)lists.trustedfirmware.org > Cc: nd <nd(a)arm.com> > Subject: Re: [TF-M] [RFC] Design document of isolation level 2 on TF-M > > Hi, > > The document is updated due to a change in MPU regions part: > > In original design, some partition libraries like 'thread_exit' is going to be linked > with partition statically, which means there would be multiple copies of these > libraries for each partition. This provided strict protection of isolation but it > looks over-protect. > > If we keep one shared code region for each partition to call these libraries, we > could: > * Save memory > * The protection is enough if we mark the code area as read-only. > > In this case, the unprivileged code and RO region needs to be kept and these > shared codes could be put there. > The requirement of these codes are: > * These codes must be thread safe and reentrant > * These codes must be put in read-only region > > The change mainly happen under section "Linker script sections re-arrangement". > Please help to comment. > > Thanks! > > -Ken > > > -----Original Message----- > > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken > > Liu (Arm Technology China) via TF-M > > Sent: Thursday, March 21, 2019 3:20 PM > > To: tf-m(a)lists.trustedfirmware.org > > Cc: nd <nd(a)arm.com> > > Subject: Re: [TF-M] [RFC] Design document of isolation level 2 on TF-M > > > > Hi, > > The document is updated, and keep open for comments ; ) > > > > The updated content is: > > > > 1. Available MPU regions for peripheral has number limitation based > > on platform. If a SP needs many un-continuous peripheral registers and > > the number exceeds available MPU number, it needs further investigation. > > 2. Rely on linker to clean the unused object files instead of > > remove them in scatter before the dependency is fully figured out. > > > > Thanks! > > > > -Ken > > > > From: Ken Liu (Arm Technology China) > > Sent: Tuesday, February 19, 2019 6:44 PM > > To: tf-m(a)lists.trustedfirmware.org > > Cc: nd <nd(a)arm.com> > > Subject: [RFC] Design document of isolation level 2 on TF-M > > > > Hello, > > The first IPC implementation works under isolation level 1. The high > > isolation levels need to be there to get compatible with PSA Firmware > > Framework. A design document is created about implementing isolation level 2 > for IPC model: > > https://developer.trustedfirmware.org/w/tf_m/design/trusted_firmware- > > m_isolation_level_2/ > > > > The mainly change of isolation level 2 compare to isolation level 1 is: > > * Put AppRoT Secure Partitions' components with same attribute (code, > > read- only data, read-write data) into the same region, which helps > > MPU setting region attributes. > > * Change Secure Partition privileged setting based on Secure Partition > > type while scheduling. > > * Change mechanism of privileged API, such as printf. > > > > If you have any comments please share it. You can reply in mailing > > list if there is no place for putting comments on the page. > > > > Thank you! > > > > -Ken > > > > -- > > 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 > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m

7 years, 3 months

1
0
0 0

Please explain tfm_register_client_id() use case

by DeMars, Alan

As currently specified, I don't see a simple way to invoke the tfm_register_client_id() API ONLY ONCE for each NS client thread. It appears that tfm_register_client_id() must be called after TZ_LoadContext_S() because the clientId provided by tfm_register_client_id() is always associated with the CURRENT NS MemoryId. However, TZ_LoadContext_S() is designed to be called only when the NS OS actually switches to a new NS thread. This creates pressure for tfm_register_client_id() to be called during a NS thread switch. However, calling tfm_register_client_id() on EVERY NS context switch is redundant and CPU wasteful. Adding code to test whether tfm_register_client_id() has already been called for a particular NS thread also seems wasteful. What seems natural to me is to add a MemoryId argument to tfm_register_client_id() so that the clientID can be mapped to the MemoryId provided by TZ_AllocModuleContext_S() right after TZ_AllocModuleContext_S() is called (ie only once). Please correct my understanding of how tfm_register_client_id() is intended to be used if the above analysis is off base. Alan

7 years, 3 months

1
0
0 0

Re: [TF-M] [RFC] Design document of isolation level 2 on TF-M

by Andrej Butok

Hi David, > Using shared libraries may give the window to exploit the vulnerabilities. Yes, you are right. BUT Code size may be a very critical parameter especially for constrained MCUs. Please do not give any mandatory limits. If any, they should be configurable. Let's give a possibility to choose for final users. BTW: 1) Current TF-M is using library approach with mbedTLS copy per each service. OK, security => but wasting of resources. In our code, we are using one copy of mbedTLS to avoid this type of wasting, but it requires original code modification. Please, give more freedom to final TFM users! 2) Why the TFM services (SST, attestation) do not call PSA Crypto API? It will eliminates mbedTLS duplication. Thanks, Andrej -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Wang (Arm Technology China) via TF-M Sent: Monday, March 25, 2019 10:57 AM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] [RFC] Design document of isolation level 2 on TF-M Hi Ken, Some comments from security review's perspective. * Using shared libraries may give the window to exploit the vulnerabilities. App RoT can analyze the shared lib to find out the useable vulnerabilities for attacking PSA RoT. * Is it a good idea to have two separate shared libs - one for all app RoT and one for all PSA RoT for isolation level2? (can still share one copy for level1.) Regards, David Wang Arm Electronic Technology (Shanghai) Co., Ltd Phone: +86-21-6154 9142 (ext. 59142) -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu (Arm Technology China) via TF-M Sent: Monday, March 25, 2019 5:05 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] [RFC] Design document of isolation level 2 on TF-M Hi, The document is updated due to a change in MPU regions part: In original design, some partition libraries like 'thread_exit' is going to be linked with partition statically, which means there would be multiple copies of these libraries for each partition. This provided strict protection of isolation but it looks over-protect. If we keep one shared code region for each partition to call these libraries, we could: * Save memory * The protection is enough if we mark the code area as read-only. In this case, the unprivileged code and RO region needs to be kept and these shared codes could be put there. The requirement of these codes are: * These codes must be thread safe and reentrant * These codes must be put in read-only region The change mainly happen under section "Linker script sections re-arrangement". Please help to comment. Thanks! -Ken > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken > Liu (Arm Technology China) via TF-M > Sent: Thursday, March 21, 2019 3:20 PM > To: tf-m(a)lists.trustedfirmware.org > Cc: nd <nd(a)arm.com> > Subject: Re: [TF-M] [RFC] Design document of isolation level 2 on TF-M > > Hi, > The document is updated, and keep open for comments ; ) > > The updated content is: > > 1. Available MPU regions for peripheral has number limitation based > on platform. If a SP needs many un-continuous peripheral registers and > the number exceeds available MPU number, it needs further investigation. > 2. Rely on linker to clean the unused object files instead of > remove them in scatter before the dependency is fully figured out. > > Thanks! > > -Ken > > From: Ken Liu (Arm Technology China) > Sent: Tuesday, February 19, 2019 6:44 PM > To: tf-m(a)lists.trustedfirmware.org > Cc: nd <nd(a)arm.com> > Subject: [RFC] Design document of isolation level 2 on TF-M > > Hello, > The first IPC implementation works under isolation level 1. The high > isolation levels need to be there to get compatible with PSA Firmware > Framework. A design document is created about implementing isolation level 2 for IPC model: > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdeve > loper.trustedfirmware.org%2Fw%2Ftf_m%2Fdesign%2Ftrusted_firmware-& > data=02%7C01%7Candrey.butok%40nxp.com%7C6a9c2cb6a5034aec48b908d6b10845 > 48%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636891046406628979&amp > ;sdata=yPus0lkd4L71ng5Z5o2hu2bDEMBAzSwUxAm1fyYf564%3D&reserved=0 > m_isolation_level_2/ > > The mainly change of isolation level 2 compare to isolation level 1 is: > * Put AppRoT Secure Partitions' components with same attribute (code, > read- only data, read-write data) into the same region, which helps > MPU setting region attributes. > * Change Secure Partition privileged setting based on Secure Partition > type while scheduling. > * Change mechanism of privileged API, such as printf. > > If you have any comments please share it. You can reply in mailing > list if there is no place for putting comments on the page. > > Thank you! > > -Ken > > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flist > s.trustedfirmware.org%2Fmailman%2Flistinfo%2Ftf-m&data=02%7C01%7Ca > ndrey.butok%40nxp.com%7C6a9c2cb6a5034aec48b908d6b1084548%7C686ea1d3bc2 > b4c6fa92cd99c5c301635%7C0%7C0%7C636891046406638984&sdata=7Wva1R6Lv > EKMxCpaVr6gRE26Fodub%2FPTQlLOiB2YvX0%3D&reserved=0 -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru…

7 years, 3 months

1
0
0 0

Re: [TF-M] [RFC] Design document of isolation level 2 on TF-M

by David Wang (Arm Technology China)

Hi Ken, Some comments from security review's perspective. * Using shared libraries may give the window to exploit the vulnerabilities. App RoT can analyze the shared lib to find out the useable vulnerabilities for attacking PSA RoT. * Is it a good idea to have two separate shared libs - one for all app RoT and one for all PSA RoT for isolation level2? (can still share one copy for level1.) Regards, David Wang Arm Electronic Technology (Shanghai) Co., Ltd Phone: +86-21-6154 9142 (ext. 59142) -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu (Arm Technology China) via TF-M Sent: Monday, March 25, 2019 5:05 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] [RFC] Design document of isolation level 2 on TF-M Hi, The document is updated due to a change in MPU regions part: In original design, some partition libraries like 'thread_exit' is going to be linked with partition statically, which means there would be multiple copies of these libraries for each partition. This provided strict protection of isolation but it looks over-protect. If we keep one shared code region for each partition to call these libraries, we could: * Save memory * The protection is enough if we mark the code area as read-only. In this case, the unprivileged code and RO region needs to be kept and these shared codes could be put there. The requirement of these codes are: * These codes must be thread safe and reentrant * These codes must be put in read-only region The change mainly happen under section "Linker script sections re-arrangement". Please help to comment. Thanks! -Ken > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken > Liu (Arm Technology China) via TF-M > Sent: Thursday, March 21, 2019 3:20 PM > To: tf-m(a)lists.trustedfirmware.org > Cc: nd <nd(a)arm.com> > Subject: Re: [TF-M] [RFC] Design document of isolation level 2 on TF-M > > Hi, > The document is updated, and keep open for comments ; ) > > The updated content is: > > 1. Available MPU regions for peripheral has number limitation based > on platform. If a SP needs many un-continuous peripheral registers and > the number exceeds available MPU number, it needs further investigation. > 2. Rely on linker to clean the unused object files instead of > remove them in scatter before the dependency is fully figured out. > > Thanks! > > -Ken > > From: Ken Liu (Arm Technology China) > Sent: Tuesday, February 19, 2019 6:44 PM > To: tf-m(a)lists.trustedfirmware.org > Cc: nd <nd(a)arm.com> > Subject: [RFC] Design document of isolation level 2 on TF-M > > Hello, > The first IPC implementation works under isolation level 1. The high > isolation levels need to be there to get compatible with PSA Firmware > Framework. A design document is created about implementing isolation level 2 for IPC model: > https://developer.trustedfirmware.org/w/tf_m/design/trusted_firmware- > m_isolation_level_2/ > > The mainly change of isolation level 2 compare to isolation level 1 is: > * Put AppRoT Secure Partitions' components with same attribute (code, > read- only data, read-write data) into the same region, which helps > MPU setting region attributes. > * Change Secure Partition privileged setting based on Secure Partition > type while scheduling. > * Change mechanism of privileged API, such as printf. > > If you have any comments please share it. You can reply in mailing > list if there is no place for putting comments on the page. > > Thank you! > > -Ken > > -- > 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

7 years, 3 months

1
0
0 0

Re: [TF-M] [RFC] Design document of isolation level 2 on TF-M

by Ken Liu (Arm Technology China)

Hi, The document is updated due to a change in MPU regions part: In original design, some partition libraries like 'thread_exit' is going to be linked with partition statically, which means there would be multiple copies of these libraries for each partition. This provided strict protection of isolation but it looks over-protect. If we keep one shared code region for each partition to call these libraries, we could: * Save memory * The protection is enough if we mark the code area as read-only. In this case, the unprivileged code and RO region needs to be kept and these shared codes could be put there. The requirement of these codes are: * These codes must be thread safe and reentrant * These codes must be put in read-only region The change mainly happen under section "Linker script sections re-arrangement". Please help to comment. Thanks! -Ken > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu > (Arm Technology China) via TF-M > Sent: Thursday, March 21, 2019 3:20 PM > To: tf-m(a)lists.trustedfirmware.org > Cc: nd <nd(a)arm.com> > Subject: Re: [TF-M] [RFC] Design document of isolation level 2 on TF-M > > Hi, > The document is updated, and keep open for comments ; ) > > The updated content is: > > 1. Available MPU regions for peripheral has number limitation based on > platform. If a SP needs many un-continuous peripheral registers and the number > exceeds available MPU number, it needs further investigation. > 2. Rely on linker to clean the unused object files instead of remove them in > scatter before the dependency is fully figured out. > > Thanks! > > -Ken > > From: Ken Liu (Arm Technology China) > Sent: Tuesday, February 19, 2019 6:44 PM > To: tf-m(a)lists.trustedfirmware.org > Cc: nd <nd(a)arm.com> > Subject: [RFC] Design document of isolation level 2 on TF-M > > Hello, > The first IPC implementation works under isolation level 1. The high isolation > levels need to be there to get compatible with PSA Firmware Framework. A > design document is created about implementing isolation level 2 for IPC model: > https://developer.trustedfirmware.org/w/tf_m/design/trusted_firmware- > m_isolation_level_2/ > > The mainly change of isolation level 2 compare to isolation level 1 is: > * Put AppRoT Secure Partitions' components with same attribute (code, read- > only data, read-write data) into the same region, which helps MPU setting > region attributes. > * Change Secure Partition privileged setting based on Secure Partition type while > scheduling. > * Change mechanism of privileged API, such as printf. > > If you have any comments please share it. You can reply in mailing list if there is > no place for putting comments on the page. > > Thank you! > > -Ken > > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m

7 years, 3 months

1
0
0 0

Re: [TF-M] English topics

by Summer Qin (Arm Technology China)

Really sorry! sent by mistake. On 3/21/19, 5:41 PM, "TF-M on behalf of Summer Qin (Arm Technology China) via TF-M" <tf-m-bounces(a)lists.trustedfirmware.org on behalf of tf-m(a)lists.trustedfirmware.org> wrote: 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. -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

7 years, 3 months

1
0
0 0

English topics

by Summer Qin (Arm Technology China)

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.

7 years, 3 months

1
0
0 0

[RFC] Design document of SST IPC model

by Summer Qin (Arm Technology China)

Hi, The design document of SST IPC compatibility has been updated due to SST supports Protected Storage API now. Please take a look at the document and give feedback if you have: https://developer.trustedfirmware.org/w/tf_m/design/sst_ipc_compatibility/ Thanks a lot! Summer

7 years, 3 months

1
0
0 0

File attribute and line ending in sources

by Edison Ai (Arm Technology China)

Hi， I created two patches to fix the line ending and file attribute problem in the source code. Could you take a look that these patches and mind the file attribute and line ending change while submitting patches? Patches links are here: * https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/723/ * https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/724/ Thanks, Edison

7 years, 3 months

1
0
0 0

[RFC] Design document of isolation level 2 on TF-M

by Ken Liu (Arm Technology China)

Hello, The first IPC implementation works under isolation level 1. The high isolation levels need to be there to get compatible with PSA Firmware Framework. A design document is created about implementing isolation level 2 for IPC model: https://developer.trustedfirmware.org/w/tf_m/design/trusted_firmware-m_isol… The mainly change of isolation level 2 compare to isolation level 1 is: * Put AppRoT Secure Partitions' components with same attribute (code, read-only data, read-write data) into the same region, which helps MPU setting region attributes. * Change Secure Partition privileged setting based on Secure Partition type while scheduling. * Change mechanism of privileged API, such as printf. If you have any comments please share it. You can reply in mailing list if there is no place for putting comments on the page. Thank you! -Ken

7 years, 3 months

1
1
0 0

Re: [TF-M] IPC and clang

by Edison Ai (Arm Technology China)

Hi Andrej, For you question, please see my comments: If I understand well, the Crypto, SST and Attestation services do not use IPC, so far. Right? - Yes. Should the SST/Crypto/Attestation services be disabled when IPC is enabled? - No, we do not have to disable them. May the Library and IPC APIs be used simultaneously? - Yes. When using " ConfigCoreIPC.cmake" configure file with enabling the " REGRESSION", you can see all the regression test can work. What part of TFM is using IPC? - There are two IPC test partitions to use the IPC: trusted-firmware-m/test/test_services/tfm_ipc_client and trusted-firmware-m/test/test_services/tfm_ipc_service. They are used to do basic IPC function tests. Thanks, Edison -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M Sent: Wednesday, March 20, 2019 3:36 PM To: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] IPC and clang Hi Edison, If I understand well, the Crypto, SST and Attestation services do not use IPC, so far. Right? Should the SST/Crypto/Attestation services be disabled when IPC is enabled? May the Library and IPC APIs be used simultaneously? What part of TFM is using IPC? Thanks, Andrej -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Edison Ai (Arm Technology China) via TF-M Sent: Wednesday, March 20, 2019 8:22 AM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] IPC and clang Hi Andrej, We tested the IPC works on Musca A but not try it on Musca B yet. The current IPC related patches are used to enable IPC mechanism, but services such as crypto, protect storage and attestation are yet to make use of IPC. Thanks, Edison -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M Sent: Tuesday, March 19, 2019 6:06 PM To: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] IPC and clang Hi Edison, OK. So, according to https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr… the armclang IPC was added only to one platform (target/mps2/an521/armclang/mps2_an521_s.sct). What about Musca A and Musca B? Thanks, Andrej -----Original Message----- From: Edison Ai (Arm Technology China) <Edison.Ai(a)arm.com> Sent: Tuesday, March 19, 2019 9:52 AM To: Andrej Butok <andrey.butok(a)nxp.com> Cc: nd <nd(a)arm.com> Subject: RE: IPC and clang Hi Andrej, You can see the log history of master branch: https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.trust…p;reserved=0. All the IPC patches had been existed in master branch. You can use the master branch now, all the IPC functions had been ready for GCC and ARMCLANG. Thanks, Edison -----Original Message----- From: Andrej Butok <andrey.butok(a)nxp.com> Sent: Tuesday, March 19, 2019 4:43 PM To: Edison Ai (Arm Technology China) <Edison.Ai(a)arm.com> Cc: nd <nd(a)arm.com> Subject: RE: IPC and clang Hi Edison, https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.trust… master head the latest commit is still 4-day old (4 days Core: Retrieve extra parameter from correct positionHEADmaster Summer Qin). Should I wait some time till it will be propagated to the public git? Thanks, Andrej -----Original Message----- From: Edison Ai (Arm Technology China) <Edison.Ai(a)arm.com> Sent: Tuesday, March 19, 2019 9:26 AM To: Andrej Butok <andrey.butok(a)nxp.com> Cc: nd <nd(a)arm.com> Subject: RE: IPC and clang Hi Andrej, You are welcome. Now, the "feature-ipc" branch had been merge into the master branch with the merge patch mentioned below. So all the patches in "feature-ipc" branch had been merge into master too. You can find the related IPC patch in the log history of master branch. The IPC can works rightly in GCC and ARMCLANG on master branch. Thanks, Edison -----Original Message----- From: Andrej Butok <andrey.butok(a)nxp.com> Sent: Tuesday, March 19, 2019 4:10 PM To: Edison Ai (Arm Technology China) <Edison.Ai(a)arm.com> Cc: nd <nd(a)arm.com> Subject: RE: IPC and clang Thanks Adison, Yes, we are using the master branch. When are you planning to merge the mentioned fix to the mainline? Thanks, Andrej -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Edison Ai (Arm Technology China) via TF-M Sent: Tuesday, March 19, 2019 9:00 AM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] IPC and clang Hi Andrej, I think you mention the "Merge remote-tracking branch 'feature-ipc' into 'master" patch: https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr…p;reserved=0. This is a merge patch to fix the merge conflicts. The original patch to support to change the linker file is here: https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr…p;reserved=0. You can see both the linker files for GCC and ARMCLANG are changed. IPC had been developed and tested on both the GCC and ARMLANG already. Thanks for your question. Edison -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M Sent: Tuesday, March 19, 2019 3:35 PM To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] IPC and clang Hello, I have noticed, that with adding the IPC feature to master branch, it were updated GCC linker files (#ifdef TFM_PSA_API sections), but ARMCLANG linker files are without any change. Does it mean that IPC was developed and tested only using GCC? Is there a plan to updated the armclang linker files? Thanks, Andrej Butok -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

7 years, 3 months

1
0
0 0

Re: [TF-M] IPC and clang

by Andrej Butok

Hi Edison, If I understand well, the Crypto, SST and Attestation services do not use IPC, so far. Right? Should the SST/Crypto/Attestation services be disabled when IPC is enabled? May the Library and IPC APIs be used simultaneously? What part of TFM is using IPC? Thanks, Andrej -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Edison Ai (Arm Technology China) via TF-M Sent: Wednesday, March 20, 2019 8:22 AM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] IPC and clang Hi Andrej, We tested the IPC works on Musca A but not try it on Musca B yet. The current IPC related patches are used to enable IPC mechanism, but services such as crypto, protect storage and attestation are yet to make use of IPC. Thanks, Edison -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M Sent: Tuesday, March 19, 2019 6:06 PM To: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] IPC and clang Hi Edison, OK. So, according to https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr… the armclang IPC was added only to one platform (target/mps2/an521/armclang/mps2_an521_s.sct). What about Musca A and Musca B? Thanks, Andrej -----Original Message----- From: Edison Ai (Arm Technology China) <Edison.Ai(a)arm.com> Sent: Tuesday, March 19, 2019 9:52 AM To: Andrej Butok <andrey.butok(a)nxp.com> Cc: nd <nd(a)arm.com> Subject: RE: IPC and clang Hi Andrej, You can see the log history of master branch: https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.trust…p;reserved=0. All the IPC patches had been existed in master branch. You can use the master branch now, all the IPC functions had been ready for GCC and ARMCLANG. Thanks, Edison -----Original Message----- From: Andrej Butok <andrey.butok(a)nxp.com> Sent: Tuesday, March 19, 2019 4:43 PM To: Edison Ai (Arm Technology China) <Edison.Ai(a)arm.com> Cc: nd <nd(a)arm.com> Subject: RE: IPC and clang Hi Edison, https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.trust… master head the latest commit is still 4-day old (4 days Core: Retrieve extra parameter from correct positionHEADmaster Summer Qin). Should I wait some time till it will be propagated to the public git? Thanks, Andrej -----Original Message----- From: Edison Ai (Arm Technology China) <Edison.Ai(a)arm.com> Sent: Tuesday, March 19, 2019 9:26 AM To: Andrej Butok <andrey.butok(a)nxp.com> Cc: nd <nd(a)arm.com> Subject: RE: IPC and clang Hi Andrej, You are welcome. Now, the "feature-ipc" branch had been merge into the master branch with the merge patch mentioned below. So all the patches in "feature-ipc" branch had been merge into master too. You can find the related IPC patch in the log history of master branch. The IPC can works rightly in GCC and ARMCLANG on master branch. Thanks, Edison -----Original Message----- From: Andrej Butok <andrey.butok(a)nxp.com> Sent: Tuesday, March 19, 2019 4:10 PM To: Edison Ai (Arm Technology China) <Edison.Ai(a)arm.com> Cc: nd <nd(a)arm.com> Subject: RE: IPC and clang Thanks Adison, Yes, we are using the master branch. When are you planning to merge the mentioned fix to the mainline? Thanks, Andrej -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Edison Ai (Arm Technology China) via TF-M Sent: Tuesday, March 19, 2019 9:00 AM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] IPC and clang Hi Andrej, I think you mention the "Merge remote-tracking branch 'feature-ipc' into 'master" patch: https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr…p;reserved=0. This is a merge patch to fix the merge conflicts. The original patch to support to change the linker file is here: https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr…p;reserved=0. You can see both the linker files for GCC and ARMCLANG are changed. IPC had been developed and tested on both the GCC and ARMLANG already. Thanks for your question. Edison -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M Sent: Tuesday, March 19, 2019 3:35 PM To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] IPC and clang Hello, I have noticed, that with adding the IPC feature to master branch, it were updated GCC linker files (#ifdef TFM_PSA_API sections), but ARMCLANG linker files are without any change. Does it mean that IPC was developed and tested only using GCC? Is there a plan to updated the armclang linker files? Thanks, Andrej Butok -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru…

7 years, 3 months

1
0
0 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

TF-M