- TF-M - lists.trustedfirmware.org

Re: [TF-M] Multi-threaded single-scheduler model proposal

by Anton Komlev

Hi Erik, Thanks for proposing improvements to TF-M, cooperative scheduling namely. You hit the topic which was considered but postponed at some moment. Believe, it will be beneficial to all of us to discuss it online and share our views on potential improvement and possible side effects. Let me know, please, if you want to include this topic into next forum agenda? Kind regards, Anton Komlev From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Shreve, Erik via TF-M Sent: 23 March 2020 14:26 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] Multi-threaded single-scheduler model proposal I'd like to propose an additional model that provides a single-scheduler _and_ multiple thread support for PSA RoT. To state a little more specifically: * The NSPE scheduler makes all scheduling decisions for execution (call) flows of the NSPE tasks - including when those flows are operating in secure side * APIs are provided to the NSPE scheduler to switch SPE task contexts (one task context associated to each NSPE task that uses PSA RoT) * Resource locking APIs are provided to allow PSA RoT functions to communicate with the NSPE scheduler (i.e. mutex take/give) * A SPE scheduler may still exist for application root of trust services, if any exist on a system. I don't see anything written up on a model like this in the design proposals or Phabricator. However, it appears to me that such a model (or something similar) must have been previously discussed. 1. There already exists a tz_context API set in CMSIS-Core for communicating task switches by the NSPE scheduler to the SPM 2. Cooperative scheduling rules design was accepted: https://ci.trustedfirmware.org/job/tf-m-build-test-nightly/lastSuccessfulBu… 3. https://youtu.be/6wEFoq49qUw?t=1671 speaks about having a stack on the SPE per NSPE task. Also, the question from the audience at the end of the presentation relates to having a single NSPE scheduler. A brief word on the motivation for such a proposal... To ease (and thus increase) adaptation of PSA RoT, wherein those services are protected from nontrusted code, the impact to the NSPE code should be minimized. The current models (Library, IPC) do well to minimize the impact from an API standpoint. That is, the NSPE caller need not know where/how the PSA RoT operates in order to compile. However, the current models do not minimize impact to scheduling on single core systems. The library model locks behind a single mutex the operations that previously existed independent of one another. The IPC model provides more flexibility. However, it still extends lock times beyond current implementations and it introduces an additional scheduler which removes determinism and forces system designers to rethink existing code. I'd like to know if there are any recorded plans for such a model (or something more similar to it than the three items above). If not, has it been discussed and actively rejected? If so why? I can/will write up a more concrete proposal, but wanted to get some discussion around the high-level idea first. Thanks, Erik Shreve, PSEM Software Security Engineer & Architect (CMCU Platform Development) Texas Instruments Inc. 12500 TI Boulevard, MS F4000 Dallas, TX 75243

5 years, 12 months

1
0
0 0

Re: [TF-M] TF-M Technical Forum call - April 2

by Jamie Fox

Hi Anton, As we will have moved to daylight saving time in US and Europe, it seems like 15.00 UTC could be a good compromise for this next session. Would result in 8.00 west coast/10.00 central/11.00 east/16.00 UK/17.00 Europe/23.00 China. So good times for US/Europe and still possible for China to join if anyone really wants to. What do you think? Kind regards, Jamie From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M Sent: 23 March 2020 14:30 To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] TF-M Technical Forum call - April 2 Hello, Last 3 sessions of the Tech Forum were convenient for Europe - Asia time zones, where majority of participants are. To let US members a chance to join at a reasonable time, propose to have the next session at US-friendly time (17:00 UTC) and then keep it every 4th, having 1:3 ratio. What do you think about such schema? As usual, please reply to this email with your proposals for agenda topics. Best regards, Anton Komlev

5 years, 12 months

2
1
0 0

TF-M Technical Forum call - April 2

by Anton Komlev

Hello, Last 3 sessions of the Tech Forum were convenient for Europe - Asia time zones, where majority of participants are. To let US members a chance to join at a reasonable time, propose to have the next session at US-friendly time (17:00 UTC) and then keep it every 4th, having 1:3 ratio. What do you think about such schema? As usual, please reply to this email with your proposals for agenda topics. Best regards, Anton Komlev

5 years, 12 months

1
0
0 0

Multi-threaded single-scheduler model proposal

by Shreve, Erik

I'd like to propose an additional model that provides a single-scheduler _and_ multiple thread support for PSA RoT. To state a little more specifically: * The NSPE scheduler makes all scheduling decisions for execution (call) flows of the NSPE tasks - including when those flows are operating in secure side * APIs are provided to the NSPE scheduler to switch SPE task contexts (one task context associated to each NSPE task that uses PSA RoT) * Resource locking APIs are provided to allow PSA RoT functions to communicate with the NSPE scheduler (i.e. mutex take/give) * A SPE scheduler may still exist for application root of trust services, if any exist on a system. I don't see anything written up on a model like this in the design proposals or Phabricator. However, it appears to me that such a model (or something similar) must have been previously discussed. 1. There already exists a tz_context API set in CMSIS-Core for communicating task switches by the NSPE scheduler to the SPM 2. Cooperative scheduling rules design was accepted: https://ci.trustedfirmware.org/job/tf-m-build-test-nightly/lastSuccessfulBu… 3. https://youtu.be/6wEFoq49qUw?t=1671 speaks about having a stack on the SPE per NSPE task. Also, the question from the audience at the end of the presentation relates to having a single NSPE scheduler. A brief word on the motivation for such a proposal... To ease (and thus increase) adaptation of PSA RoT, wherein those services are protected from nontrusted code, the impact to the NSPE code should be minimized. The current models (Library, IPC) do well to minimize the impact from an API standpoint. That is, the NSPE caller need not know where/how the PSA RoT operates in order to compile. However, the current models do not minimize impact to scheduling on single core systems. The library model locks behind a single mutex the operations that previously existed independent of one another. The IPC model provides more flexibility. However, it still extends lock times beyond current implementations and it introduces an additional scheduler which removes determinism and forces system designers to rethink existing code. I'd like to know if there are any recorded plans for such a model (or something more similar to it than the three items above). If not, has it been discussed and actively rejected? If so why? I can/will write up a more concrete proposal, but wanted to get some discussion around the high-level idea first. Thanks, Erik Shreve, PSEM Software Security Engineer & Architect (CMCU Platform Development) Texas Instruments Inc. 12500 TI Boulevard, MS F4000 Dallas, TX 75243

5 years, 12 months

1
0
0 0

Trusted Firmware Keynote @Linaro TechDays (Wed 25 Mar, 16:00-16:30 GMT)

by Shebu Varghese Kuriakose

Hi All, Trusted Firmware will be opening the Linaro Tech Days event on Wed 25th March at 4pm (16:00) GMT with a keynote presenting all the latest exciting news from the project. https://connect.linaro.org/resources/ltd20/ltd20-200k/ and, once registered, on sched: https://linarotechdays.sched.com/event/ZZFK/ltd20-200k-keynote-trusted-firm… The session will be live streamed and recorded (links in the above resources) and slides will be attached there too. Don't miss it! Regards, Shebu/Matteo

5 years, 12 months

1
0
0 0

Re: [TF-M] psa-arch-tests console baud rate

by Edison Ai

Hi Thomas, For your 2nd question. I have tested it on my side and it has the same problem. The TF-M can print normal boot message, but the log becomes garbage after enter into Arch test. The PSA Arch test is another independent project, and I have arisen this issue to the PSA Arch test project: https://github.com/ARM-software/psa-arch-tests/issues/164. You can watch this issue directly. Thanks, Edison From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Edison Ai via TF-M Sent: Thursday, March 19, 2020 9:54 PM To: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org> Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] psa-arch-tests console baud rate Hi Thomas, Thanks your mail. For your 1st question. There is indeed a problem to build the PSA arch crypto test on the Musca_a board for the RAM size is too small. I suggest you split the crypto tests into different test images on the Musca_a board. For the 2nd question, I only test that on FVP AN521 but never met this problem. We will test that on the MPS2 AN521 board soon to check if it is a real problem. If yes, we will try to fix that quickly. Thanks, Edison From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Thomas Törnblom via TF-M Sent: Wednesday, March 18, 2020 9:38 PM To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: [TF-M] psa-arch-tests console baud rate Triggered by Rays mail on slow RSA key pair generation, I built and tried to run the tests, but ran into a couple of issues: 1) I attempted to build it for the Musca A, but apparently that doesn't have enough RAM to run these tests 2) Switching to an MPS2+ with AN521 configuration I see that the baud rate on the UART appears wrong when running the tests. mcuboot produces correct messages at 115200 bps, as does the normal ConfigRegression* tests, but the ConfigPsaApiTest* appears to produce just garbage. Is there a setting I need to set to get any useful data on the terminal when running the ConfigPsaApiTests? Cheers, 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, 12 months

1
0
0 0

Re: [TF-M] [EXTERNAL] Re: SPM_IDLE

by DeMars, Alan

Ken, Our secure callback solution to this issue is working. I am just following up to understand what the SPM_IDLE concept is. Alan On Mar 20, 2020, at 4:34 AM, Ken Liu via TF-M <tf-m(a)lists.trustedfirmware.org> wrote: Hi Alan, Looks like this is the still classic case, but unfortunately that there is no defined design at the current stage. Heard you were working on an solution for this, and got some issues when non-secure preempts secure execution, since your scheduler works in thread mode so cannot update secure context while scheduling – please correct me if my understanding is wrong. Is this mail a follow up or another thread just focus on discussion of the cooperative scheduling document? BR /Ken From: DeMars, Alan <ademars(a)ti.com> Sent: Friday, March 20, 2020 2:27 AM To: Ken Liu <Ken.Liu(a)arm.com> Cc: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org> Subject: RE: SPM_IDLE Ken, Our use case is to support a “secure driver”: 1. A peripheral can only be accessed in secure mode. 2. The peripheral is configured and a hardware process is triggered within the peripheral. 3. When the process completes, a secure interrupt is triggered. 4. The NS thread that is using this driver should block (allowing other NS threads to run) while waiting for the hardware process to complete and resume when the process is finished. Alan From: TF-M [mailto:tf-m-bounces@lists.trustedfirmware.org] On Behalf Of Ken Liu via TF-M Sent: Thursday, March 5, 2020 10:28 PM To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Cc: nd Subject: [EXTERNAL] Re: [TF-M] SPM_IDLE Hi Alan, It (8.3.5) is one of the cases can be dealt with, and now it is not detail defined yet. Can you describe what your practical purpose for S/NS interactive is so that we could collect feedbacks to check if the rules are applicable? /Ken 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: Wednesday, March 4, 2020 10:51 PM To: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> Subject: [TF-M] SPM_IDLE Mention is made to “SPM_IDLE” in the Cooperative Scheduling Rules document: https://ci.trustedfirmware.org/job/tf-m-build-test-nightly/lastSuccessfulBu… I’m struggling to understand section 8.3.5 which references SPM_IDLE but doesn’t really define it. Is there more info on this topic? It appears to be a proposed solution for allowing other NS threads to be scheduled while the current NS thread is waiting for an asynchronous event in the secure service it has called. Alan -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years

1
0
0 0

Interface: Remove unused header include

by Devaraj Ranganna

Hi, The patchset https://review.trustedfirmware.org/c/trusted-firmware-m/+/3620 removes the header `tfm_veneers.h` from PSA IPC API source files. If there are no objects then can this patchset be merged? Thanks, Dev 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.

6 years

1
0
0 0

Re: [TF-M] SPM_IDLE

by DeMars, Alan

Ken, Our use case is to support a "secure driver": 1) A peripheral can only be accessed in secure mode. 2) The peripheral is configured and a hardware process is triggered within the peripheral. 3) When the process completes, a secure interrupt is triggered. 4) The NS thread that is using this driver should block (allowing other NS threads to run) while waiting for the hardware process to complete and resume when the process is finished. Alan From: TF-M [mailto:tf-m-bounces@lists.trustedfirmware.org] On Behalf Of Ken Liu via TF-M Sent: Thursday, March 5, 2020 10:28 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd Subject: [EXTERNAL] Re: [TF-M] SPM_IDLE Hi Alan, It (8.3.5) is one of the cases can be dealt with, and now it is not detail defined yet. Can you describe what your practical purpose for S/NS interactive is so that we could collect feedbacks to check if the rules are applicable? /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of DeMars, Alan via TF-M Sent: Wednesday, March 4, 2020 10:51 PM To: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org> Subject: [TF-M] SPM_IDLE Mention is made to "SPM_IDLE" in the Cooperative Scheduling Rules document: https://ci.trustedfirmware.org/job/tf-m-build-test-nightly/lastSuccessfulBu… I'm struggling to understand section 8.3.5 which references SPM_IDLE but doesn't really define it. Is there more info on this topic? It appears to be a proposed solution for allowing other NS threads to be scheduled while the current NS thread is waiting for an asynchronous event in the secure service it has called. Alan

6 years

2
1
0 0

Re: [TF-M] 2048-bit RSA Keypair generation is slow

by Raymond Ngun

Thanks Tamas, Did you try with CC312 disabled as well? I am wondering if you would be able to at least reproduce what I saw. Ray From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Tamas Ban via TF-M Sent: Thursday, March 19, 2020 4:30 AM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] FW: 2048-bit RSA Keypair generation is slow CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. Hi, We did measurements on Musca-B1 with enabled CC312. We did 10 run with both compiler( armclang and gnuarm). RSA2048 key generation takes 10-35 sec. In average gnuarm seems a bit slower. I suspect the reason behind that random number still need to be tested that are they fit for rsa2048 generation (might are they primes?) and the testing algorithm is might faster with armclang. But for sure we have not seen any run which could take minutes. Tamas From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Adrian Shaw via TF-M Sent: 19 March 2020 12:17 To: Raymond Ngun <Raymond.Ngun(a)cypress.com<mailto:Raymond.Ngun@cypress.com>>; Soby Mathew <Soby.Mathew(a)arm.com<mailto:Soby.Mathew@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] 2048-bit RSA Keypair generation is slow If the platform has on-chip NVM then you should consider using NV seed entropy. You still need a TRNG to get the initial entropy, but seems like it could improve average runtime performance. I believe there's a macro like MBEDTLS_ENTROPY_NV_SEED that you have to enable, as well as providing the hooks to read/write the flash. Adrian ________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> on behalf of Soby Mathew via TF-M <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> Sent: 18 March 2020 16:24 To: Raymond Ngun <Raymond.Ngun(a)cypress.com<mailto:Raymond.Ngun@cypress.com>> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>>; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> Subject: Re: [TF-M] 2048-bit RSA Keypair generation is slow Hi Ray, That is good information. The software RNG is not truly random and is not production quality. The predictable timing could be an indicator that the randomness is reproducible. That's all I know, but the mbed-crypto team may have more inputs and they can be queried here : https://github.com/ARMmbed/mbed-crypto/issues Best Regards Soby Mathew From: Raymond Ngun <Raymond.Ngun(a)cypress.com<mailto:Raymond.Ngun@cypress.com>> Sent: 18 March 2020 15:33 To: Soby Mathew <Soby.Mathew(a)arm.com<mailto:Soby.Mathew@arm.com>> Cc: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>; nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: RE: 2048-bit RSA Keypair generation is slow Hi Soby, Musca-B1 has CC312 support which will introduce an rng for this purpose. Unfortunately, I didn't test Musca-B1 with cc312 enabled and I don't have a board now to test with. However, I did test with a h/w rng on the PSoC64 and the performance isn't always better. When using s/w, the time it takes was quite consistent at 1.5 minutes or 5.5 minutes depending on toolchain. After introducing the h/w rng, I've seen it finish quickly (less than a minute) but I've also seen it take 15 minutes. Thanks, Ray From: Soby Mathew <Soby.Mathew(a)arm.com<mailto:Soby.Mathew@arm.com>> Sent: Wednesday, March 18, 2020 4:44 AM To: Raymond Ngun <Raymond.Ngun(a)cypress.com<mailto:Raymond.Ngun@cypress.com>> Cc: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>; nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: RE: 2048-bit RSA Keypair generation is slow Hi Raymond Thanks for bring this to the forum. When I did the migration to the latest mbed-crypto tag, I faced the same issue. After couple of discussion within the team and mbedcrypto, this is the understanding I have. Currently mbedcrypto is configured to use NULL entropy. Hence this is the print message when building mbedcrypto : #warning "**** WARNING! MBEDTLS_TEST_NULL_ENTROPY defined! " This means that mbedcrypto uses a software algorithm to generate randomness. It iterates this algorithm till it can generate enough randomness for the keypair generation and this is the reason for the delay. If the hardware has an entropy source which can be used for this random number generation, then I understand the performance will be much better. But this will need suitable configuration to be enabled from TF-M. I am not much familiar with hardware architecture of M-Class systems. One of the questions I have to the forum is, do we have such entropy sources on the hardware? Then it is worth scheduling some task to investigate how to abstract/use the entropy source. Best Regards Soby Mathew From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Raymond Ngun via TF-M Sent: 17 March 2020 21:02 To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: [TF-M] 2048-bit RSA Keypair generation is slow Hi all, When testing the PSA API Crypto Dev API test suite, I noticed that psa_generate_key() is awfully slow when generating a 2048-bit RSA keypair and the performance is different depending on toolchain used. I've run these tests on Musca-B1 and with GCC, key generation generally completes in 25s but an armclang build requires 2.5 minutes to complete. This is more pronounced on PSoC64 where we are building for armv6m. Here, the key generation can take up to 5.5 minutes and I've seen it take even longer - I assume this is due to values returned by rng. Anybody have comments on the performance of psa_generate_key() or more specifically mbedtls_rsa_gen_key()? What can be done to help improve the performance of this software implementation? Thank you, Ray This message and any attachments may contain confidential information from Cypress or its subsidiaries. If it has been received in error, please advise the sender and immediately delete this message. This message and any attachments may contain confidential information from Cypress or its subsidiaries. If it has been received in error, please advise the sender and immediately delete this message. 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. This message and any attachments may contain confidential information from Cypress or its subsidiaries. If it has been received in error, please advise the sender and immediately delete this message.

6 years

1
0
0 0

Re: [TF-M] psa-arch-tests console baud rate

by Edison Ai

Hi Thomas, Thanks your mail. For your 1st question. There is indeed a problem to build the PSA arch crypto test on the Musca_a board for the RAM size is too small. I suggest you split the crypto tests into different test images on the Musca_a board. For the 2nd question, I only test that on FVP AN521 but never met this problem. We will test that on the MPS2 AN521 board soon to check if it is a real problem. If yes, we will try to fix that quickly. Thanks, Edison From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Thomas Törnblom via TF-M Sent: Wednesday, March 18, 2020 9:38 PM To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] psa-arch-tests console baud rate Triggered by Rays mail on slow RSA key pair generation, I built and tried to run the tests, but ran into a couple of issues: 1) I attempted to build it for the Musca A, but apparently that doesn't have enough RAM to run these tests 2) Switching to an MPS2+ with AN521 configuration I see that the baud rate on the UART appears wrong when running the tests. mcuboot produces correct messages at 115200 bps, as does the normal ConfigRegression* tests, but the ConfigPsaApiTest* appears to produce just garbage. Is there a setting I need to set to get any useful data on the terminal when running the ConfigPsaApiTests? Cheers, 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>

6 years

1
0
0 0

Re: [TF-M] 2048-bit RSA Keypair generation is slow

by Adrian Shaw

Note that you'll still to re-seed from the TRNG periodically, but doesn't have to be done every time the application needs a random number. Adrian ________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Adrian Shaw via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: 19 March 2020 11:16 To: Raymond Ngun <Raymond.Ngun(a)cypress.com>; Soby Mathew <Soby.Mathew(a)arm.com> Cc: nd <nd(a)arm.com>; tf-m(a)lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.org> Subject: Re: [TF-M] 2048-bit RSA Keypair generation is slow If the platform has on-chip NVM then you should consider using NV seed entropy. You still need a TRNG to get the initial entropy, but seems like it could improve average runtime performance. I believe there's a macro like MBEDTLS_ENTROPY_NV_SEED that you have to enable, as well as providing the hooks to read/write the flash. Adrian ________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Soby Mathew via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: 18 March 2020 16:24 To: Raymond Ngun <Raymond.Ngun(a)cypress.com> Cc: nd <nd(a)arm.com>; tf-m(a)lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.org> Subject: Re: [TF-M] 2048-bit RSA Keypair generation is slow Hi Ray, That is good information. The software RNG is not truly random and is not production quality. The predictable timing could be an indicator that the randomness is reproducible. That’s all I know, but the mbed-crypto team may have more inputs and they can be queried here : https://github.com/ARMmbed/mbed-crypto/issues Best Regards Soby Mathew From: Raymond Ngun <Raymond.Ngun(a)cypress.com> Sent: 18 March 2020 15:33 To: Soby Mathew <Soby.Mathew(a)arm.com> Cc: tf-m(a)lists.trustedfirmware.org; nd <nd(a)arm.com> Subject: RE: 2048-bit RSA Keypair generation is slow Hi Soby, Musca-B1 has CC312 support which will introduce an rng for this purpose. Unfortunately, I didn’t test Musca-B1 with cc312 enabled and I don’t have a board now to test with. However, I did test with a h/w rng on the PSoC64 and the performance isn’t always better. When using s/w, the time it takes was quite consistent at 1.5 minutes or 5.5 minutes depending on toolchain. After introducing the h/w rng, I’ve seen it finish quickly (less than a minute) but I’ve also seen it take 15 minutes. Thanks, Ray From: Soby Mathew <Soby.Mathew(a)arm.com<mailto:Soby.Mathew@arm.com>> Sent: Wednesday, March 18, 2020 4:44 AM To: Raymond Ngun <Raymond.Ngun(a)cypress.com<mailto:Raymond.Ngun@cypress.com>> Cc: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>; nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: RE: 2048-bit RSA Keypair generation is slow Hi Raymond Thanks for bring this to the forum. When I did the migration to the latest mbed-crypto tag, I faced the same issue. After couple of discussion within the team and mbedcrypto, this is the understanding I have. Currently mbedcrypto is configured to use NULL entropy. Hence this is the print message when building mbedcrypto : #warning "**** WARNING! MBEDTLS_TEST_NULL_ENTROPY defined! " This means that mbedcrypto uses a software algorithm to generate randomness. It iterates this algorithm till it can generate enough randomness for the keypair generation and this is the reason for the delay. If the hardware has an entropy source which can be used for this random number generation, then I understand the performance will be much better. But this will need suitable configuration to be enabled from TF-M. I am not much familiar with hardware architecture of M-Class systems. One of the questions I have to the forum is, do we have such entropy sources on the hardware? Then it is worth scheduling some task to investigate how to abstract/use the entropy source. Best Regards Soby Mathew From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Raymond Ngun via TF-M Sent: 17 March 2020 21:02 To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: [TF-M] 2048-bit RSA Keypair generation is slow Hi all, When testing the PSA API Crypto Dev API test suite, I noticed that psa_generate_key() is awfully slow when generating a 2048-bit RSA keypair and the performance is different depending on toolchain used. I’ve run these tests on Musca-B1 and with GCC, key generation generally completes in 25s but an armclang build requires 2.5 minutes to complete. This is more pronounced on PSoC64 where we are building for armv6m. Here, the key generation can take up to 5.5 minutes and I’ve seen it take even longer – I assume this is due to values returned by rng. Anybody have comments on the performance of psa_generate_key() or more specifically mbedtls_rsa_gen_key()? What can be done to help improve the performance of this software implementation? Thank you, Ray This message and any attachments may contain confidential information from Cypress or its subsidiaries. If it has been received in error, please advise the sender and immediately delete this message. This message and any attachments may contain confidential information from Cypress or its subsidiaries. If it has been received in error, please advise the sender and immediately delete this message. 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. 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.

6 years

1
0
0 0

FW: 2048-bit RSA Keypair generation is slow

by Tamas Ban

Hi, We did measurements on Musca-B1 with enabled CC312. We did 10 run with both compiler( armclang and gnuarm). RSA2048 key generation takes 10-35 sec. In average gnuarm seems a bit slower. I suspect the reason behind that random number still need to be tested that are they fit for rsa2048 generation (might are they primes?) and the testing algorithm is might faster with armclang. But for sure we have not seen any run which could take minutes. Tamas From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Adrian Shaw via TF-M Sent: 19 March 2020 12:17 To: Raymond Ngun <Raymond.Ngun(a)cypress.com<mailto:Raymond.Ngun@cypress.com>>; Soby Mathew <Soby.Mathew(a)arm.com<mailto:Soby.Mathew@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] 2048-bit RSA Keypair generation is slow If the platform has on-chip NVM then you should consider using NV seed entropy. You still need a TRNG to get the initial entropy, but seems like it could improve average runtime performance. I believe there's a macro like MBEDTLS_ENTROPY_NV_SEED that you have to enable, as well as providing the hooks to read/write the flash. Adrian ________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> on behalf of Soby Mathew via TF-M <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> Sent: 18 March 2020 16:24 To: Raymond Ngun <Raymond.Ngun(a)cypress.com<mailto:Raymond.Ngun@cypress.com>> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>>; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> Subject: Re: [TF-M] 2048-bit RSA Keypair generation is slow Hi Ray, That is good information. The software RNG is not truly random and is not production quality. The predictable timing could be an indicator that the randomness is reproducible. That's all I know, but the mbed-crypto team may have more inputs and they can be queried here : https://github.com/ARMmbed/mbed-crypto/issues Best Regards Soby Mathew From: Raymond Ngun <Raymond.Ngun(a)cypress.com<mailto:Raymond.Ngun@cypress.com>> Sent: 18 March 2020 15:33 To: Soby Mathew <Soby.Mathew(a)arm.com<mailto:Soby.Mathew@arm.com>> Cc: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>; nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: RE: 2048-bit RSA Keypair generation is slow Hi Soby, Musca-B1 has CC312 support which will introduce an rng for this purpose. Unfortunately, I didn't test Musca-B1 with cc312 enabled and I don't have a board now to test with. However, I did test with a h/w rng on the PSoC64 and the performance isn't always better. When using s/w, the time it takes was quite consistent at 1.5 minutes or 5.5 minutes depending on toolchain. After introducing the h/w rng, I've seen it finish quickly (less than a minute) but I've also seen it take 15 minutes. Thanks, Ray From: Soby Mathew <Soby.Mathew(a)arm.com<mailto:Soby.Mathew@arm.com>> Sent: Wednesday, March 18, 2020 4:44 AM To: Raymond Ngun <Raymond.Ngun(a)cypress.com<mailto:Raymond.Ngun@cypress.com>> Cc: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>; nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: RE: 2048-bit RSA Keypair generation is slow Hi Raymond Thanks for bring this to the forum. When I did the migration to the latest mbed-crypto tag, I faced the same issue. After couple of discussion within the team and mbedcrypto, this is the understanding I have. Currently mbedcrypto is configured to use NULL entropy. Hence this is the print message when building mbedcrypto : #warning "**** WARNING! MBEDTLS_TEST_NULL_ENTROPY defined! " This means that mbedcrypto uses a software algorithm to generate randomness. It iterates this algorithm till it can generate enough randomness for the keypair generation and this is the reason for the delay. If the hardware has an entropy source which can be used for this random number generation, then I understand the performance will be much better. But this will need suitable configuration to be enabled from TF-M. I am not much familiar with hardware architecture of M-Class systems. One of the questions I have to the forum is, do we have such entropy sources on the hardware? Then it is worth scheduling some task to investigate how to abstract/use the entropy source. Best Regards Soby Mathew From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Raymond Ngun via TF-M Sent: 17 March 2020 21:02 To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: [TF-M] 2048-bit RSA Keypair generation is slow Hi all, When testing the PSA API Crypto Dev API test suite, I noticed that psa_generate_key() is awfully slow when generating a 2048-bit RSA keypair and the performance is different depending on toolchain used. I've run these tests on Musca-B1 and with GCC, key generation generally completes in 25s but an armclang build requires 2.5 minutes to complete. This is more pronounced on PSoC64 where we are building for armv6m. Here, the key generation can take up to 5.5 minutes and I've seen it take even longer - I assume this is due to values returned by rng. Anybody have comments on the performance of psa_generate_key() or more specifically mbedtls_rsa_gen_key()? What can be done to help improve the performance of this software implementation? Thank you, Ray This message and any attachments may contain confidential information from Cypress or its subsidiaries. If it has been received in error, please advise the sender and immediately delete this message. This message and any attachments may contain confidential information from Cypress or its subsidiaries. If it has been received in error, please advise the sender and immediately delete this message. 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.

6 years

1
0
0 0

Re: [TF-M] 2048-bit RSA Keypair generation is slow

by Adrian Shaw

If the platform has on-chip NVM then you should consider using NV seed entropy. You still need a TRNG to get the initial entropy, but seems like it could improve average runtime performance. I believe there's a macro like MBEDTLS_ENTROPY_NV_SEED that you have to enable, as well as providing the hooks to read/write the flash. Adrian ________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Soby Mathew via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: 18 March 2020 16:24 To: Raymond Ngun <Raymond.Ngun(a)cypress.com> Cc: nd <nd(a)arm.com>; tf-m(a)lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.org> Subject: Re: [TF-M] 2048-bit RSA Keypair generation is slow Hi Ray, That is good information. The software RNG is not truly random and is not production quality. The predictable timing could be an indicator that the randomness is reproducible. That’s all I know, but the mbed-crypto team may have more inputs and they can be queried here : https://github.com/ARMmbed/mbed-crypto/issues Best Regards Soby Mathew From: Raymond Ngun <Raymond.Ngun(a)cypress.com> Sent: 18 March 2020 15:33 To: Soby Mathew <Soby.Mathew(a)arm.com> Cc: tf-m(a)lists.trustedfirmware.org; nd <nd(a)arm.com> Subject: RE: 2048-bit RSA Keypair generation is slow Hi Soby, Musca-B1 has CC312 support which will introduce an rng for this purpose. Unfortunately, I didn’t test Musca-B1 with cc312 enabled and I don’t have a board now to test with. However, I did test with a h/w rng on the PSoC64 and the performance isn’t always better. When using s/w, the time it takes was quite consistent at 1.5 minutes or 5.5 minutes depending on toolchain. After introducing the h/w rng, I’ve seen it finish quickly (less than a minute) but I’ve also seen it take 15 minutes. Thanks, Ray From: Soby Mathew <Soby.Mathew(a)arm.com<mailto:Soby.Mathew@arm.com>> Sent: Wednesday, March 18, 2020 4:44 AM To: Raymond Ngun <Raymond.Ngun(a)cypress.com<mailto:Raymond.Ngun@cypress.com>> Cc: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>; nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: RE: 2048-bit RSA Keypair generation is slow Hi Raymond Thanks for bring this to the forum. When I did the migration to the latest mbed-crypto tag, I faced the same issue. After couple of discussion within the team and mbedcrypto, this is the understanding I have. Currently mbedcrypto is configured to use NULL entropy. Hence this is the print message when building mbedcrypto : #warning "**** WARNING! MBEDTLS_TEST_NULL_ENTROPY defined! " This means that mbedcrypto uses a software algorithm to generate randomness. It iterates this algorithm till it can generate enough randomness for the keypair generation and this is the reason for the delay. If the hardware has an entropy source which can be used for this random number generation, then I understand the performance will be much better. But this will need suitable configuration to be enabled from TF-M. I am not much familiar with hardware architecture of M-Class systems. One of the questions I have to the forum is, do we have such entropy sources on the hardware? Then it is worth scheduling some task to investigate how to abstract/use the entropy source. Best Regards Soby Mathew From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Raymond Ngun via TF-M Sent: 17 March 2020 21:02 To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: [TF-M] 2048-bit RSA Keypair generation is slow Hi all, When testing the PSA API Crypto Dev API test suite, I noticed that psa_generate_key() is awfully slow when generating a 2048-bit RSA keypair and the performance is different depending on toolchain used. I’ve run these tests on Musca-B1 and with GCC, key generation generally completes in 25s but an armclang build requires 2.5 minutes to complete. This is more pronounced on PSoC64 where we are building for armv6m. Here, the key generation can take up to 5.5 minutes and I’ve seen it take even longer – I assume this is due to values returned by rng. Anybody have comments on the performance of psa_generate_key() or more specifically mbedtls_rsa_gen_key()? What can be done to help improve the performance of this software implementation? Thank you, Ray This message and any attachments may contain confidential information from Cypress or its subsidiaries. If it has been received in error, please advise the sender and immediately delete this message. This message and any attachments may contain confidential information from Cypress or its subsidiaries. If it has been received in error, please advise the sender and immediately delete this message. 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.

6 years

1
0
0 0

Re: [TF-M] 2048-bit RSA Keypair generation is slow

by Soby Mathew

Hi Raymond Thanks for bring this to the forum. When I did the migration to the latest mbed-crypto tag, I faced the same issue. After couple of discussion within the team and mbedcrypto, this is the understanding I have. Currently mbedcrypto is configured to use NULL entropy. Hence this is the print message when building mbedcrypto : #warning "**** WARNING! MBEDTLS_TEST_NULL_ENTROPY defined! " This means that mbedcrypto uses a software algorithm to generate randomness. It iterates this algorithm till it can generate enough randomness for the keypair generation and this is the reason for the delay. If the hardware has an entropy source which can be used for this random number generation, then I understand the performance will be much better. But this will need suitable configuration to be enabled from TF-M. I am not much familiar with hardware architecture of M-Class systems. One of the questions I have to the forum is, do we have such entropy sources on the hardware? Then it is worth scheduling some task to investigate how to abstract/use the entropy source. Best Regards Soby Mathew From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Raymond Ngun via TF-M Sent: 17 March 2020 21:02 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] 2048-bit RSA Keypair generation is slow Hi all, When testing the PSA API Crypto Dev API test suite, I noticed that psa_generate_key() is awfully slow when generating a 2048-bit RSA keypair and the performance is different depending on toolchain used. I've run these tests on Musca-B1 and with GCC, key generation generally completes in 25s but an armclang build requires 2.5 minutes to complete. This is more pronounced on PSoC64 where we are building for armv6m. Here, the key generation can take up to 5.5 minutes and I've seen it take even longer - I assume this is due to values returned by rng. Anybody have comments on the performance of psa_generate_key() or more specifically mbedtls_rsa_gen_key()? What can be done to help improve the performance of this software implementation? Thank you, Ray This message and any attachments may contain confidential information from Cypress or its subsidiaries. If it has been received in error, please advise the sender and immediately delete this message.

6 years

2
2
0 0

psa-arch-tests console baud rate

by Thomas Törnblom

Triggered by Rays mail on slow RSA key pair generation, I built and tried to run the tests, but ran into a couple of issues: 1) I attempted to build it for the Musca A, but apparently that doesn't have enough RAM to run these tests 2) Switching to an MPS2+ with AN521 configuration I see that the baud rate on the UART appears wrong when running the tests. mcuboot produces correct messages at 115200 bps, as does the normal ConfigRegression* tests, but the ConfigPsaApiTest* appears to produce just garbage. Is there a setting I need to set to get any useful data on the terminal when running the ConfigPsaApiTests? Cheers, 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>

6 years

1
0
0 0

2048-bit RSA Keypair generation is slow

by Raymond Ngun

Hi all, When testing the PSA API Crypto Dev API test suite, I noticed that psa_generate_key() is awfully slow when generating a 2048-bit RSA keypair and the performance is different depending on toolchain used. I've run these tests on Musca-B1 and with GCC, key generation generally completes in 25s but an armclang build requires 2.5 minutes to complete. This is more pronounced on PSoC64 where we are building for armv6m. Here, the key generation can take up to 5.5 minutes and I've seen it take even longer - I assume this is due to values returned by rng. Anybody have comments on the performance of psa_generate_key() or more specifically mbedtls_rsa_gen_key()? What can be done to help improve the performance of this software implementation? Thank you, Ray This message and any attachments may contain confidential information from Cypress or its subsidiaries. If it has been received in error, please advise the sender and immediately delete this message.

6 years

1
0
0 0

Re: [TF-M] Cooperative Scheduling Rules and CMSIS tz_context

by Shreve, Erik

Thanks, The library model seems to treat the entire SPE as a single resource as it appears to lock and only allow a single entry at a time: /* This is the "Big Lock" on the secure side, to guarantee single entry * to SPE */ extern int32_t tfm_secure_lock; Is this a limitation of the current implementation or is this the envisioned design for the library model? If the latter, is there a technical/security reason why only a single entry is allowed? Or is it that no use-case to allow multiple entry has been discussed. To back up a bit, we have use cases where I would like to see the NSPE RTOS make all the scheduling decisions and further have all the secure peripheral resources be managed individually with respect to blocking threads. The IPC model seems to be built around having a scheduler in the SPM and the library model seems to preclude the ability to manage secure peripherals individually. Erik Shreve, PSEM Software Security Engineer & Architect (CMCU Platform Development) From: TF-M [mailto:tf-m-bounces@lists.trustedfirmware.org] On Behalf Of Mate Toth-Pal via TF-M Sent: Friday, March 13, 2020 7:50 AM To: Cc: nd Subject: [EXTERNAL] Re: [TF-M] Cooperative Scheduling Rules and CMSIS tz_context Hi Erik, Yes, the two working models are mutually exclusive, and the model is selected compile time, by choosing a corresponding config cmake file. I'm afraid there isn't a comprehensive specification for the Library model, like for IPC model. For examples on calling services in library model, you can have a look in the Secure Service API implementations. Look in interface/src for NS, and in the directory of the services, for example services/initial_attestation/tfm_attestation_secure_api.c for secure examples. The working model specific code parts that are in common files are (across the whole TF-M codebase) guarded by the TFM_PSA_API define: #ifdef TFM_PSA_API /* IPC model implementation */ #else /* TFM_PSA_API */ /* Library model implementation */ #endif /* TFM_PSA_API */ If a source file is IPC model specific it has 'ipc' in its name, or is in a directory called 'ipc'. Library model specific files have 'func' in their name. Regards, Mate From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Shreve, Erik via TF-M Sent: Friday, March 13, 2020 1:34 PM To: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] Cooperative Scheduling Rules and CMSIS tz_context Mate, Thanks for providing your time to respond. Understanding there are two models in play helps a lot. A few follow up questions... Can you confirm that the models are mutually exclusive? This page indicates to me that they are mutually exclusive: https://ci.trustedfirmware.org/job/tf-m-build-test-nightly/lastSuccessfulBu… Or are there provisions to allow a system to run both models on the _same_ execution node? For example running both on the same v7 or v8 with TrustZone core. If there are provisions for this, where can I go to get a better understanding of them? Also, is there any spec for the library model beyond the API descriptions in the CMSIS documentation (https://arm-software.github.io/CMSIS_5/Core/html/using_TrustZone_pg.html#RT… If not, then I'll rely on reading the existing code. Please feel free to point me more documentation if I can get answers there. (I don't mind a friendly "read the manual" or "run this example code.") Thanks again for your time. Erik Shreve, PSEM Software Security Engineer & Architect (CMCU Platform Development) From: TF-M [mailto:tf-m-bounces@lists.trustedfirmware.org] On Behalf Of Mate Toth-Pal via TF-M Sent: Thursday, March 12, 2020 2:34 PM To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Cc: nd Subject: [EXTERNAL] Re: [TF-M] Cooperative Scheduling Rules and CMSIS tz_context Hi Erik, Your mail contains quite a few questions. I'll try to give an overview in the topic you are asking, hoping that it is going to answer most (hopefully all) questions. If there is anything left unanswered, please follow up. So currently TF-M supports two working model: IPC model, and Library model. Library model has no scheduling on the secure side, secure services are called like normal functions. The IPC model contains a simple scheduler. (IPC model is an implementation of the PSA Firmware Framework for M (PSA-FF-M): https://developer.arm.com/-/media/Files/pdf/PlatformSecurityArchitecture/Ar… ) In this model, all the secure partitions have a runtime context associated with them. They have a separate stack, and their runtime state is saved when they are not scheduled by the Secure scheduler. This means that the number of secure contexts is determined compile time. 'Cooperative Scheduling Rules' document is a proposal of how a Non-Secure and a Secure scheduler should work together, to efficiently handle secure and non-secure asynchronous events. Currently The Secure scheduler has no knowledge of the state of the NS scheduler, and vice-versa. There is a roadmap item 'Scheduler - Initial Support' (currently without deadline) at https://developer.trustedfirmware.org/w/tf_m/planning/ which refers to this. The RTOS Thread Context Management API implementation had been added to TF-M, to support a feature called TF-M Non-Secure client identification. It is used by the /** * \brief Stores caller's client id in state context */ void tfm_core_get_caller_client_id_handler(const uint32_t svc_args[]); API that is available for the secure services. Through this API secure services can distinguish Non-Secure clients. TF-M manages a database of clients reported by the Non secure software (through the TZ_*APIs), and also tracks the ID of the currently active client. That client ID is returned by 'tfm_core_get_caller_client_id_handler' (in case the Secure Service was called from Non-Secure code) Please note that the 'tfm_core_get_caller_client_id_handler' API is only supported in Library model. The TZ_* APIs are implemented in the NSPM module: secure_fw/core/tfm_nspm_func.c. The IPC model's implementation of the NSPM module is empty: secure_fw/core/tfm_nspm_ipc.c The original idea behind the RTOS Thread Context Management API is that the Secure context creation (allocating stack, and other supporting data structures) and destruction is initiated from the Non-Secure code. The number of active secure contexts is decided by the NS code in run time (of course if there is no more resource, the context creation fails). On scheduling, the non-secure SW notifies the secure code, to activate the context for the thread to be scheduled. This results in setting the secure stack pointer to the desired context (hence the "prepare"). After the NS Scheduler returns to the thread, the Secure or the Non-Secure code continues execution, depending on whether Secure, or Non-Secure execution had been interrupted by the NS scheduling. Neither the single secure context design of the library model, and the above described design of the IPC model supports this approach, and that's why the semantics of the APIs in TF-M are different in TF-M. Regards, Mate From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Shreve, Erik via TF-M Sent: Wednesday, March 11, 2020 3:07 PM To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: [TF-M] Cooperative Scheduling Rules and CMSIS tz_context Hello everyone, I'm new to the list. Quick introduction: I work at Texas Instruments and I'm investigating TFM for use in some of our platforms here. I'm trying to understand the scheduling and task architecture for PSA and the TFM implementation and how that intersects with NS tasks. I found the following: https://ci.trustedfirmware.org/job/tf-m-build-test-nightly/lastSuccessfulBu… https://arm-software.github.io/CMSIS_5/Core/html/group__context__trustzone_… The existing TFM implementation doesn't seem to do much with the tz_context interface. It looks like it tracks which NS client is active, but I don't see where it uses that information to do anything. Am I missing something? I'd like to understand more about where TFM is going with the tz_context interface. Will there be a tz_context focused scheduler? I can imagine one where the SPM associates NS clients with running Secure Partitions and resumes execution of a running a Secure Partition when the NS RTOS indicates the NS client is "active." But it isn't clear to me if this is the direction or not. I note that the text for TZ_LoadContext_S says "**Prepare** the secure context for execution so that a thread in the non-secure state can call secure library modules." Preparing sounds different than immediate execution. Are there other documents I can read or source implementations I can reference to get more of a handle on this? Thanks, Erik Shreve, PSEM Software Security Engineer & Architect (CMCU Platform Development) Texas Instruments

6 years

2
1
0 0

Re: [TF-M] Cooperative Scheduling Rules and CMSIS tz_context

by Mate Toth-Pal

Hi Erik, Yes, the two working models are mutually exclusive, and the model is selected compile time, by choosing a corresponding config cmake file. I'm afraid there isn't a comprehensive specification for the Library model, like for IPC model. For examples on calling services in library model, you can have a look in the Secure Service API implementations. Look in interface/src for NS, and in the directory of the services, for example services/initial_attestation/tfm_attestation_secure_api.c for secure examples. The working model specific code parts that are in common files are (across the whole TF-M codebase) guarded by the TFM_PSA_API define: #ifdef TFM_PSA_API /* IPC model implementation */ #else /* TFM_PSA_API */ /* Library model implementation */ #endif /* TFM_PSA_API */ If a source file is IPC model specific it has 'ipc' in its name, or is in a directory called 'ipc'. Library model specific files have 'func' in their name. Regards, Mate From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Shreve, Erik via TF-M Sent: Friday, March 13, 2020 1:34 PM To: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] Cooperative Scheduling Rules and CMSIS tz_context Mate, Thanks for providing your time to respond. Understanding there are two models in play helps a lot. A few follow up questions... Can you confirm that the models are mutually exclusive? This page indicates to me that they are mutually exclusive: https://ci.trustedfirmware.org/job/tf-m-build-test-nightly/lastSuccessfulBu… Or are there provisions to allow a system to run both models on the _same_ execution node? For example running both on the same v7 or v8 with TrustZone core. If there are provisions for this, where can I go to get a better understanding of them? Also, is there any spec for the library model beyond the API descriptions in the CMSIS documentation (https://arm-software.github.io/CMSIS_5/Core/html/using_TrustZone_pg.html#RT… If not, then I'll rely on reading the existing code. Please feel free to point me more documentation if I can get answers there. (I don't mind a friendly "read the manual" or "run this example code.") Thanks again for your time. Erik Shreve, PSEM Software Security Engineer & Architect (CMCU Platform Development) From: TF-M [mailto:tf-m-bounces@lists.trustedfirmware.org] On Behalf Of Mate Toth-Pal via TF-M Sent: Thursday, March 12, 2020 2:34 PM To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Cc: nd Subject: [EXTERNAL] Re: [TF-M] Cooperative Scheduling Rules and CMSIS tz_context Hi Erik, Your mail contains quite a few questions. I'll try to give an overview in the topic you are asking, hoping that it is going to answer most (hopefully all) questions. If there is anything left unanswered, please follow up. So currently TF-M supports two working model: IPC model, and Library model. Library model has no scheduling on the secure side, secure services are called like normal functions. The IPC model contains a simple scheduler. (IPC model is an implementation of the PSA Firmware Framework for M (PSA-FF-M): https://developer.arm.com/-/media/Files/pdf/PlatformSecurityArchitecture/Ar… ) In this model, all the secure partitions have a runtime context associated with them. They have a separate stack, and their runtime state is saved when they are not scheduled by the Secure scheduler. This means that the number of secure contexts is determined compile time. 'Cooperative Scheduling Rules' document is a proposal of how a Non-Secure and a Secure scheduler should work together, to efficiently handle secure and non-secure asynchronous events. Currently The Secure scheduler has no knowledge of the state of the NS scheduler, and vice-versa. There is a roadmap item 'Scheduler - Initial Support' (currently without deadline) at https://developer.trustedfirmware.org/w/tf_m/planning/ which refers to this. The RTOS Thread Context Management API implementation had been added to TF-M, to support a feature called TF-M Non-Secure client identification. It is used by the /** * \brief Stores caller's client id in state context */ void tfm_core_get_caller_client_id_handler(const uint32_t svc_args[]); API that is available for the secure services. Through this API secure services can distinguish Non-Secure clients. TF-M manages a database of clients reported by the Non secure software (through the TZ_*APIs), and also tracks the ID of the currently active client. That client ID is returned by 'tfm_core_get_caller_client_id_handler' (in case the Secure Service was called from Non-Secure code) Please note that the 'tfm_core_get_caller_client_id_handler' API is only supported in Library model. The TZ_* APIs are implemented in the NSPM module: secure_fw/core/tfm_nspm_func.c. The IPC model's implementation of the NSPM module is empty: secure_fw/core/tfm_nspm_ipc.c The original idea behind the RTOS Thread Context Management API is that the Secure context creation (allocating stack, and other supporting data structures) and destruction is initiated from the Non-Secure code. The number of active secure contexts is decided by the NS code in run time (of course if there is no more resource, the context creation fails). On scheduling, the non-secure SW notifies the secure code, to activate the context for the thread to be scheduled. This results in setting the secure stack pointer to the desired context (hence the "prepare"). After the NS Scheduler returns to the thread, the Secure or the Non-Secure code continues execution, depending on whether Secure, or Non-Secure execution had been interrupted by the NS scheduling. Neither the single secure context design of the library model, and the above described design of the IPC model supports this approach, and that's why the semantics of the APIs in TF-M are different in TF-M. Regards, Mate From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Shreve, Erik via TF-M Sent: Wednesday, March 11, 2020 3:07 PM To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: [TF-M] Cooperative Scheduling Rules and CMSIS tz_context Hello everyone, I'm new to the list. Quick introduction: I work at Texas Instruments and I'm investigating TFM for use in some of our platforms here. I'm trying to understand the scheduling and task architecture for PSA and the TFM implementation and how that intersects with NS tasks. I found the following: https://ci.trustedfirmware.org/job/tf-m-build-test-nightly/lastSuccessfulBu… https://arm-software.github.io/CMSIS_5/Core/html/group__context__trustzone_… The existing TFM implementation doesn't seem to do much with the tz_context interface. It looks like it tracks which NS client is active, but I don't see where it uses that information to do anything. Am I missing something? I'd like to understand more about where TFM is going with the tz_context interface. Will there be a tz_context focused scheduler? I can imagine one where the SPM associates NS clients with running Secure Partitions and resumes execution of a running a Secure Partition when the NS RTOS indicates the NS client is "active." But it isn't clear to me if this is the direction or not. I note that the text for TZ_LoadContext_S says "**Prepare** the secure context for execution so that a thread in the non-secure state can call secure library modules." Preparing sounds different than immediate execution. Are there other documents I can read or source implementations I can reference to get more of a handle on this? Thanks, Erik Shreve, PSEM Software Security Engineer & Architect (CMCU Platform Development) Texas Instruments

6 years

1
0
0 0

Re: [TF-M] Cooperative Scheduling Rules and CMSIS tz_context

by Shreve, Erik

Mate, Thanks for providing your time to respond. Understanding there are two models in play helps a lot. A few follow up questions... Can you confirm that the models are mutually exclusive? This page indicates to me that they are mutually exclusive: https://ci.trustedfirmware.org/job/tf-m-build-test-nightly/lastSuccessfulBu… Or are there provisions to allow a system to run both models on the _same_ execution node? For example running both on the same v7 or v8 with TrustZone core. If there are provisions for this, where can I go to get a better understanding of them? Also, is there any spec for the library model beyond the API descriptions in the CMSIS documentation (https://arm-software.github.io/CMSIS_5/Core/html/using_TrustZone_pg.html#RT… If not, then I'll rely on reading the existing code. Please feel free to point me more documentation if I can get answers there. (I don't mind a friendly "read the manual" or "run this example code.") Thanks again for your time. Erik Shreve, PSEM Software Security Engineer & Architect (CMCU Platform Development) From: TF-M [mailto:tf-m-bounces@lists.trustedfirmware.org] On Behalf Of Mate Toth-Pal via TF-M Sent: Thursday, March 12, 2020 2:34 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd Subject: [EXTERNAL] Re: [TF-M] Cooperative Scheduling Rules and CMSIS tz_context Hi Erik, Your mail contains quite a few questions. I'll try to give an overview in the topic you are asking, hoping that it is going to answer most (hopefully all) questions. If there is anything left unanswered, please follow up. So currently TF-M supports two working model: IPC model, and Library model. Library model has no scheduling on the secure side, secure services are called like normal functions. The IPC model contains a simple scheduler. (IPC model is an implementation of the PSA Firmware Framework for M (PSA-FF-M): https://developer.arm.com/-/media/Files/pdf/PlatformSecurityArchitecture/Ar… ) In this model, all the secure partitions have a runtime context associated with them. They have a separate stack, and their runtime state is saved when they are not scheduled by the Secure scheduler. This means that the number of secure contexts is determined compile time. 'Cooperative Scheduling Rules' document is a proposal of how a Non-Secure and a Secure scheduler should work together, to efficiently handle secure and non-secure asynchronous events. Currently The Secure scheduler has no knowledge of the state of the NS scheduler, and vice-versa. There is a roadmap item 'Scheduler - Initial Support' (currently without deadline) at https://developer.trustedfirmware.org/w/tf_m/planning/ which refers to this. The RTOS Thread Context Management API implementation had been added to TF-M, to support a feature called TF-M Non-Secure client identification. It is used by the /** * \brief Stores caller's client id in state context */ void tfm_core_get_caller_client_id_handler(const uint32_t svc_args[]); API that is available for the secure services. Through this API secure services can distinguish Non-Secure clients. TF-M manages a database of clients reported by the Non secure software (through the TZ_*APIs), and also tracks the ID of the currently active client. That client ID is returned by 'tfm_core_get_caller_client_id_handler' (in case the Secure Service was called from Non-Secure code) Please note that the 'tfm_core_get_caller_client_id_handler' API is only supported in Library model. The TZ_* APIs are implemented in the NSPM module: secure_fw/core/tfm_nspm_func.c. The IPC model's implementation of the NSPM module is empty: secure_fw/core/tfm_nspm_ipc.c The original idea behind the RTOS Thread Context Management API is that the Secure context creation (allocating stack, and other supporting data structures) and destruction is initiated from the Non-Secure code. The number of active secure contexts is decided by the NS code in run time (of course if there is no more resource, the context creation fails). On scheduling, the non-secure SW notifies the secure code, to activate the context for the thread to be scheduled. This results in setting the secure stack pointer to the desired context (hence the "prepare"). After the NS Scheduler returns to the thread, the Secure or the Non-Secure code continues execution, depending on whether Secure, or Non-Secure execution had been interrupted by the NS scheduling. Neither the single secure context design of the library model, and the above described design of the IPC model supports this approach, and that's why the semantics of the APIs in TF-M are different in TF-M. Regards, Mate From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Shreve, Erik via TF-M Sent: Wednesday, March 11, 2020 3:07 PM To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] Cooperative Scheduling Rules and CMSIS tz_context Hello everyone, I'm new to the list. Quick introduction: I work at Texas Instruments and I'm investigating TFM for use in some of our platforms here. I'm trying to understand the scheduling and task architecture for PSA and the TFM implementation and how that intersects with NS tasks. I found the following: https://ci.trustedfirmware.org/job/tf-m-build-test-nightly/lastSuccessfulBu… https://arm-software.github.io/CMSIS_5/Core/html/group__context__trustzone_… The existing TFM implementation doesn't seem to do much with the tz_context interface. It looks like it tracks which NS client is active, but I don't see where it uses that information to do anything. Am I missing something? I'd like to understand more about where TFM is going with the tz_context interface. Will there be a tz_context focused scheduler? I can imagine one where the SPM associates NS clients with running Secure Partitions and resumes execution of a running a Secure Partition when the NS RTOS indicates the NS client is "active." But it isn't clear to me if this is the direction or not. I note that the text for TZ_LoadContext_S says "**Prepare** the secure context for execution so that a thread in the non-secure state can call secure library modules." Preparing sounds different than immediate execution. Are there other documents I can read or source implementations I can reference to get more of a handle on this? Thanks, Erik Shreve, PSEM Software Security Engineer & Architect (CMCU Platform Development) Texas Instruments

6 years

1
0
0 0

Re: [TF-M] Cooperative Scheduling Rules and CMSIS tz_context

by Mate Toth-Pal

Hi Erik, Your mail contains quite a few questions. I'll try to give an overview in the topic you are asking, hoping that it is going to answer most (hopefully all) questions. If there is anything left unanswered, please follow up. So currently TF-M supports two working model: IPC model, and Library model. Library model has no scheduling on the secure side, secure services are called like normal functions. The IPC model contains a simple scheduler. (IPC model is an implementation of the PSA Firmware Framework for M (PSA-FF-M): https://developer.arm.com/-/media/Files/pdf/PlatformSecurityArchitecture/Ar… ) In this model, all the secure partitions have a runtime context associated with them. They have a separate stack, and their runtime state is saved when they are not scheduled by the Secure scheduler. This means that the number of secure contexts is determined compile time. 'Cooperative Scheduling Rules' document is a proposal of how a Non-Secure and a Secure scheduler should work together, to efficiently handle secure and non-secure asynchronous events. Currently The Secure scheduler has no knowledge of the state of the NS scheduler, and vice-versa. There is a roadmap item 'Scheduler - Initial Support' (currently without deadline) at https://developer.trustedfirmware.org/w/tf_m/planning/ which refers to this. The RTOS Thread Context Management API implementation had been added to TF-M, to support a feature called TF-M Non-Secure client identification. It is used by the /** * \brief Stores caller's client id in state context */ void tfm_core_get_caller_client_id_handler(const uint32_t svc_args[]); API that is available for the secure services. Through this API secure services can distinguish Non-Secure clients. TF-M manages a database of clients reported by the Non secure software (through the TZ_*APIs), and also tracks the ID of the currently active client. That client ID is returned by 'tfm_core_get_caller_client_id_handler' (in case the Secure Service was called from Non-Secure code) Please note that the 'tfm_core_get_caller_client_id_handler' API is only supported in Library model. The TZ_* APIs are implemented in the NSPM module: secure_fw/core/tfm_nspm_func.c. The IPC model's implementation of the NSPM module is empty: secure_fw/core/tfm_nspm_ipc.c The original idea behind the RTOS Thread Context Management API is that the Secure context creation (allocating stack, and other supporting data structures) and destruction is initiated from the Non-Secure code. The number of active secure contexts is decided by the NS code in run time (of course if there is no more resource, the context creation fails). On scheduling, the non-secure SW notifies the secure code, to activate the context for the thread to be scheduled. This results in setting the secure stack pointer to the desired context (hence the "prepare"). After the NS Scheduler returns to the thread, the Secure or the Non-Secure code continues execution, depending on whether Secure, or Non-Secure execution had been interrupted by the NS scheduling. Neither the single secure context design of the library model, and the above described design of the IPC model supports this approach, and that's why the semantics of the APIs in TF-M are different in TF-M. Regards, Mate From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Shreve, Erik via TF-M Sent: Wednesday, March 11, 2020 3:07 PM To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] Cooperative Scheduling Rules and CMSIS tz_context Hello everyone, I'm new to the list. Quick introduction: I work at Texas Instruments and I'm investigating TFM for use in some of our platforms here. I'm trying to understand the scheduling and task architecture for PSA and the TFM implementation and how that intersects with NS tasks. I found the following: https://ci.trustedfirmware.org/job/tf-m-build-test-nightly/lastSuccessfulBu… https://arm-software.github.io/CMSIS_5/Core/html/group__context__trustzone_… The existing TFM implementation doesn't seem to do much with the tz_context interface. It looks like it tracks which NS client is active, but I don't see where it uses that information to do anything. Am I missing something? I'd like to understand more about where TFM is going with the tz_context interface. Will there be a tz_context focused scheduler? I can imagine one where the SPM associates NS clients with running Secure Partitions and resumes execution of a running a Secure Partition when the NS RTOS indicates the NS client is "active." But it isn't clear to me if this is the direction or not. I note that the text for TZ_LoadContext_S says "**Prepare** the secure context for execution so that a thread in the non-secure state can call secure library modules." Preparing sounds different than immediate execution. Are there other documents I can read or source implementations I can reference to get more of a handle on this? Thanks, Erik Shreve, PSEM Software Security Engineer & Architect (CMCU Platform Development) Texas Instruments

6 years

1
0
0 0

Re: [TF-M] NS DATA Linker file

by Mate Toth-Pal

Hi Andrej, You seem to be right. In the current platforms NS_DATA_SIZE is defined as either of the following: * #define NS_DATA_SIZE (TOTAL_RAM_SIZE - S_DATA_SIZE) * #define NS_DATA_SIZE (TOTAL_RAM_SIZE / 2) Which means NS_DATA_SIZE Is the maximum available RAM for the NS Software. So the maximum available size of the RW and ZI data is decreased by the amounts you enumerate in your mail. I created a task to fix this: https://developer.trustedfirmware.org/T687 Thanks, Mate From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M Sent: Thursday, March 12, 2020 9:23 AM To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] NS DATA Linker file Hello, It looks like there is a mistake for ER_DATA region in the NS armclang linker file. ... ER_DATA NS_DATA_START NS_DATA_SIZE { * (+ZI +RW) } /* MSP */ ARM_LIB_STACK_MSP +0 ALIGN 32 EMPTY NS_MSP_STACK_SIZE { } /* PSP */ ARM_LIB_STACK +0 ALIGN 32 EMPTY NS_PSP_STACK_SIZE { } ARM_LIB_HEAP +0 ALIGN 8 EMPTY NS_HEAP_SIZE { } ... ER_DATA does not take into account the NS_MSP_STACK_SIZE+NS_PSP_STACK_SIZE+EMPTY NS_HEAP_SIZE size: #define NS_DATA_SIZE (TOTAL_RAM_SIZE - S_DATA_SIZE) Guess, the NS linker file should be: ... ER_DATA NS_DATA_START NS_DATA_SIZE-NS_MSP_STACK_SIZE-NS_PSP_STACK_SIZE-EMPTY NS_HEAP_SIZE { * (+ZI +RW) } ... Or, did I miss something? Thank you, Andrej Butok

6 years

1
0
0 0

Re: [TF-M] PSA Test Suite - Attestation test

by Andrej Butok

Hi Tamas, I have noticed today, that the PSA test suite has done several merges to its master branch. Based the PSA test-suit readme, it has switched to newer versions of the PSA API. Should we try to update or better to wait for a right signal from the TFM team? Thanks, Andrej From: Tamas Ban <Tamas.Ban(a)arm.com<mailto:Tamas.Ban@arm.com>> Sent: Thursday, February 6, 2020 2:09 PM To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Cc: Andrej Butok <andrey.butok(a)nxp.com<mailto:andrey.butok@nxp.com>> Subject: RE: PSA Test Suite - Attestation test Hi Andrej, The v19.08_TBSA0.9 version of psa-arch test suite is aligned with current TF-M master. I have executed the test suite and found that unfortunately the attestation test suite is currently broken: * It was introduced by the QCBOR library update in https://review.trustedfirmware.org/c/trusted-firmware-m/+/2679/6<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr…> * Currently there is a misalignment between psa-arch and tf-m in terms of QCBOR version. psa-arch still relies on older version of QCBOR. * The version mismatch lead some parsing error in CBOR that is the reason why the test suite is failing. * Other issue is that v19.08_TBSA0.9 version of psa-arch mandates the key-id in unprotected COSE header, however that field is optional according to the standard. In TF-M the inclusion of key-id was bind to ATTEST_INCLUDE_TEST_CODE_AND_KEY_ID, which was split to two compile time switch (https://review.trustedfirmware.org/c/trusted-firmware-m/+/3147<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr…>) ATTEST_INCLUDE_COSE_KEY_ID and ATTEST_ INCLUDE_TEST_CODE. Way forward: * I let the psa-arch test team to update QCBOR. * Fix will be put on master, but currently the tip of the psa-arch master is not aligned with TF-M master. They are supports different PSA API versions. * In TF-M there is a branch<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.trust…> where the PSA API update is happening. This branch is intended to be merged to master in Q1. Tamas From: Andrej Butok <andrey.butok(a)nxp.com<mailto:andrey.butok@nxp.com>> Sent: 05 February 2020 14:21 To: Tamas Ban <Tamas.Ban(a)arm.com<mailto:Tamas.Ban@arm.com>> Cc: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: RE: PSA Test Suite - Attestation test Hi Tamas > Could you tell what was the values of these compile time switches in your test? For the previous TFM, we have used INCLUDE_TEST_CODE_AND_KEY_ID. For the current TFM it was renamed to INCLUDE_TEST_CODE. Other parameters are new, so I have tried different combinations of these parameters, but the PSA Test-Suite Attestation is still failed. > Further do you implemented the boot data sharing between bootloader and runtime firmware? It's used the TFM template code without change from tfm\platform\ext\common\template > Do you sign SPE and NPSE images together or they are signed separately? We do not use the secondary bootloader so far, so image is not signed. As the Attestation Regression tests are passed. It's good to know what combination of parameters have to be used to generate the same token as it was generated by the older TFM and accepted by the PSA Test Suite (last commit on master branch). Or the PSA Test Suite is obsolete. Thank you, Andrej From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Tamas Ban via TF-M Sent: Wednesday, February 5, 2020 1:13 PM To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: Re: [TF-M] PSA Test Suite - Attestation test Hi Andrej, Could you tell what was the values of these compile time switches in your test? I assume you did the test on NXP board. Further do you implemented the boot data sharing between bootloader and runtime firmware? Do you sign SPE and NPSE images together or they are signed separately? Tamas From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Andrej Butok via TF-M Sent: 04 February 2020 17:33 To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: [TF-M] PSA Test Suite - Attestation test Hello, After upgrade to the latest version of TFM, the Attestation test from the PSA Test Suite is failed (but the TFM Attestation regression tests are passed). What combination of configuration parameters must be used (INCLUDE_OPTIONAL_CLAIMS, INCLUDE_TEST_CODE, INCLUDE_COSE_KEY_ID, BOOT_DATA_AVAILABLE) to follow PSA Test Suite expectations? What commit of the PSA Test-suite must be used for the latest TFM? We are still on the 2019-07-25 (c80681ed7c7f3e2cbf02ded1ef2464ba2ca7ccd5) commit, which was OK with 2-month old TFM. Is the PSA Test Suite Attestation test valid for the latest TFM? Thank you, Andrej Butok 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. 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.

6 years

2
3
0 0

Re: [TF-M] TF-M Technical Forum call - March 19

by Mate Toth-Pal

Hi All, I would like to give a short talk about a tool proposal to test IRQ handling in TF-M core. Regards, Mate From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M Sent: Wednesday, March 11, 2020 1:27 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] TF-M Technical Forum call - March 19 Hello, The next Technical Forum is planned on Thursday, March 19 at 7:00-8:00 UTC. Please reply on this email with your proposals for agenda topics. Best regards, Anton Komlev

6 years

1
0
0 0

NS DATA Linker file

by Andrej Butok

Hello, It looks like there is a mistake for ER_DATA region in the NS armclang linker file. ... ER_DATA NS_DATA_START NS_DATA_SIZE { * (+ZI +RW) } /* MSP */ ARM_LIB_STACK_MSP +0 ALIGN 32 EMPTY NS_MSP_STACK_SIZE { } /* PSP */ ARM_LIB_STACK +0 ALIGN 32 EMPTY NS_PSP_STACK_SIZE { } ARM_LIB_HEAP +0 ALIGN 8 EMPTY NS_HEAP_SIZE { } ... ER_DATA does not take into account the NS_MSP_STACK_SIZE+NS_PSP_STACK_SIZE+EMPTY NS_HEAP_SIZE size: #define NS_DATA_SIZE (TOTAL_RAM_SIZE - S_DATA_SIZE) Guess, the NS linker file should be: ... ER_DATA NS_DATA_START NS_DATA_SIZE-NS_MSP_STACK_SIZE-NS_PSP_STACK_SIZE-EMPTY NS_HEAP_SIZE { * (+ZI +RW) } ... Or, did I miss something? Thank you, Andrej Butok

6 years

1
0
0 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

TF-M