January 2020 - TF-M - lists.trustedfirmware.org

by Anton Komlev

Hello, Hope that the new year is truly happy for everybody. The next session of the Technical Forum is planned on the coming Thursday, January 9th. Regarding the time, I think that the last session was a good compromise to suit majority of the participants so propose to keep the time slot at 7:00-8:00 UTC. This time suits members in Europe and Asia, although participants from US (specially from the East coast) might have inconveniences. Reminding that the recorded sessions and materials are available on the web site: https://www.trustedfirmware.org/meetings/tf-m-technical-forum/ Please reply to this email to post your topics for the agenda. Any questions, proposals, concerns are all valid points for our open discussion so do not hesitate to share it. Best regards, Anton Komlev

5 years, 2 months

1
0
0 0

Re: [TF-M] irq handling in library mode

by Andrew Thoelke

> Just a question: For Isolation Level 1, the hardware features of v8-M should be sufficient to implement interrupts natively. Is this correct understanding or did I miss anything? This is essentially correct. As this is outside of the PSA-FF at present, TF-M would need to design and document how to integrate such IRQ handlers with its interrupt management framework, and how the interrupt handler can interact with the secure service code. For example, this might be achieved by resuming a SFC call that is waiting for a hardware operation to complete or delivering a signal to an IPC mode Secure Partition. IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

5 years, 2 months

1
0
0 0

Re: [TF-M] The logging mechanism change in TF-M

by Soby Mathew

On 06/01/2020 11:45, Anton Komlev via TF-M wrote: > Hi Ken, All, > > I like your approach of providing a minimalistic version of printf() for > the logging purpose only. > > This would benefit to code size and performance while rich print > formatting has no practical needs in this project. > > Best regards, > > Anton > > *From:* TF-M <tf-m-bounces(a)lists.trustedfirmware.org> *On Behalf Of *Ken > Liu via TF-M > *Sent:* 27 December 2019 03:38 > *To:* tf-m(a)lists.trustedfirmware.org > *Cc:* nd <nd(a)arm.com> > *Subject:* [TF-M] The logging mechanism change in TF-M > > Hi, > > We met some issues while implementing logging APIs like printf: > > * The build-in symbol optimization references other toolchain provided > symbols into image (like change ‘printf’ to ‘puts’ or ‘xxxprintf’), > this would happen in both we are implementing your ‘printf’ and > referencing toolchain ‘printf’. Use a -fno-builtin would suppress > this but this needs a compiler flag requirement for developers. > * If we don’t provide necessary symbol but somewhere in program > referenced it, ARMCLANG would provide one for us which contains the > semihosting things, this increases the code size and cause trouble > while the device is not running under semihosting env. > * Also there are CMSIS user reports that __stdout would affect > multiple thread object initialization. (No detail about the root > cause, anyone could help provide something?) > > So it would be better that we remove the reference to toolchain stdout > APIs, this could simplify the logging implementation since firmware > logging MAY not need rich format (Comments?). A customized printf-like > API is provided for logging but not being named as ‘printf’ directly. > > Due to the default logging device (UART) driver may be implemented for > threads only, the logging functionality in exceptions is going to be > suppressed for a while until we figure out how the logging in exceptions > can be – there is a trade-off between security consideration (isolation) > and performance (Routing the logging API to somewhere costs). > > Please provide your thinking, or what kind of logging API you are using. > > Thanks > > /Ken > The TF-A code base provides a reduced printf() functionality due to similar concerns and to reduce stack/memory usage https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tree/lib/libc/p… Also be aware that mbedTLS requires snprintf() so if printf() is being custom implemented, then it makes sense to do the same to snprintf() as well. Best Regards Soby Mathew

5 years, 2 months

1
0
0 0

Re: [TF-M] The logging mechanism change in TF-M

by Anton Komlev

Hi Ken, All, I like your approach of providing a minimalistic version of printf() for the logging purpose only. This would benefit to code size and performance while rich print formatting has no practical needs in this project. Best regards, Anton From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu via TF-M Sent: 27 December 2019 03:38 To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] The logging mechanism change in TF-M Hi, We met some issues while implementing logging APIs like printf: * The build-in symbol optimization references other toolchain provided symbols into image (like change 'printf' to 'puts' or 'xxxprintf'), this would happen in both we are implementing your 'printf' and referencing toolchain 'printf'. Use a -fno-builtin would suppress this but this needs a compiler flag requirement for developers. * If we don't provide necessary symbol but somewhere in program referenced it, ARMCLANG would provide one for us which contains the semihosting things, this increases the code size and cause trouble while the device is not running under semihosting env. * Also there are CMSIS user reports that __stdout would affect multiple thread object initialization. (No detail about the root cause, anyone could help provide something?) So it would be better that we remove the reference to toolchain stdout APIs, this could simplify the logging implementation since firmware logging MAY not need rich format (Comments?). A customized printf-like API is provided for logging but not being named as 'printf' directly. Due to the default logging device (UART) driver may be implemented for threads only, the logging functionality in exceptions is going to be suppressed for a while until we figure out how the logging in exceptions can be - there is a trade-off between security consideration (isolation) and performance (Routing the logging API to somewhere costs). Please provide your thinking, or what kind of logging API you are using. Thanks /Ken

5 years, 2 months

1
0
0 0

Re: [TF-M] System reset SPM HAL function

by Edison Ai

This patch will add a new system reset function for SPM without using the existing platform_hal_system_reset(). The basic thinking is to create a dedicated HAL function for SPM to split with services, and not affect the secure partition work. I am not sure if this will bring some problems or any potential risk for platform porting. Please give feedback about this in this mail thread. Thanks, Edison From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Edison Ai via TF-M Sent: Monday, December 30, 2019 3:43 PM To: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org> Cc: nd <nd(a)arm.com> Subject: [TF-M] System reset SPM HAL function Hi All, To align with PSA FF 1.0.0, the SPM needs to restart the entire system when some programmer error or panics are detected. So I had upstream a patch to add a system reset HAL function for SPM: https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/2780/. The basic idea is to add a weak common function so that the platform can use this weak function to do reset. Please note, the platform needs to add its own implementation if there is any different. Unfortunately, there is no such test to test the system reset function curreetly. So please call psa_panic() in secure services for simple testing based on the top of this link: https://review.trustedfirmware.org/#/q/topic:tfm_panic+(status:open+OR+stat…. You can send mail or add comments directly in patches if you have any questions or comments. Thanks, Edison

5 years, 2 months

1
0
0 0

Secure Partition runtime library prototype is available

by Ken Liu

Hi, After couples of patches get merged, the Secure Partition runtime library prototype is available. The purpose of this library (aka SPRTL) is to provide a place for shared functions between secure partitions under isolation level 2/3 which could avoid duplicated code symbols in Secure Partitions. The situation is: - There is a folder for SPE dedicated function implementation: 'secure_fw/lib/sprt'. More APIs can be put in SPRTL by modifying the makefiles under this folder. - Keep using toolchain provided 'memset/memcpy' due to inherit them is a bit complicated (of course these toolchain symbols are put in the shared region to avoid duplication). And we keep the customized candidate in source code for further investigation to see if we need this customized version or the default version. - Overriding toolchain 'memcmp' into a customized version to show security consideration. - Implemented a customized 'tfm_log_printf' to replace 'printf', which could avoid involving complicated STDIO mechanism into the code base. - PSA FF APIs are now in it. These changes are now working under the code base, some other functions are not available yet and to be done later due to no actual requirement for them, such as: - Heap APIs, now crypto uses its own implemented heap while other services do not need them. - RoT Service APIs, would request service owner to move the existing RoT Service APIs into SPRTL (should be just some function attribute change, let's check it). Any feedbacks or issue reporting is welcome, please reply in the mailing list or create an issue at developer.trustedfirmware.org and assign to 'KenLSoft'. BR and thanks. /Ken

5 years, 2 months

1
0
0 0

Re: [TF-M] [Call for cygwin volunteers] Remove the mbed-crypto building workaround

by Ken Liu

Thanks for the feedback, let me take a note. /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Qixiang Xu via TF-M Sent: Monday, January 6, 2020 1:49 PM To: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] [Call for cygwin volunteers] Remove the mbed-crypto building workaround Ken, I have cherry picked the patch and tested it on Cygwin: $ cmake --version cmake version 3.11.1 CMake suite maintained and supported by Kitware (kitware.com/cmake). The patch works and no issue found. Best Regards, Qixiang Xu From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Ken Liu via TF-M Sent: Monday, January 6, 2020 11:00 AM To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: [TF-M] [Call for cygwin volunteers] Remove the mbed-crypto building workaround Hi, I create a patch for removing the workaround for mbed-crypto building: https://review.trustedfirmware.org/c/trusted-firmware-m/+/3022 We tried on cmake 3.7 and 3.10 with cygwin and it works; can some Cygwin/mingw user pick this patch and test if it could work in your side? Thanks for your contribution 😊 /Ken IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

5 years, 2 months

1
0
0 0

Re: [TF-M] [Call for cygwin volunteers] Remove the mbed-crypto building workaround

by Qixiang Xu

Ken, I have cherry picked the patch and tested it on Cygwin: $ cmake --version cmake version 3.11.1 CMake suite maintained and supported by Kitware (kitware.com/cmake). The patch works and no issue found. Best Regards, Qixiang Xu From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu via TF-M Sent: Monday, January 6, 2020 11:00 AM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] [Call for cygwin volunteers] Remove the mbed-crypto building workaround Hi, I create a patch for removing the workaround for mbed-crypto building: https://review.trustedfirmware.org/c/trusted-firmware-m/+/3022 We tried on cmake 3.7 and 3.10 with cygwin and it works; can some Cygwin/mingw user pick this patch and test if it could work in your side? Thanks for your contribution 😊 /Ken IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

5 years, 2 months

1
0
0 0

[Call for cygwin volunteers] Remove the mbed-crypto building workaround

by Ken Liu

Hi, I create a patch for removing the workaround for mbed-crypto building: https://review.trustedfirmware.org/c/trusted-firmware-m/+/3022 We tried on cmake 3.7 and 3.10 with cygwin and it works; can some Cygwin/mingw user pick this patch and test if it could work in your side? Thanks for your contribution 😊 /Ken

5 years, 2 months

1
0
0 0

Re: [TF-M] irq handling in library mode

by Reinhard Keil

Hi Andrew, Thanks for the reply and the confirmation of the flexibility of the PSA-FF Just a question: For Isolation Level 1, the hardware features of v8-M should be sufficient to implement interrupts natively. Is this correct understanding or did I miss anything? Reinhard IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

5 years, 2 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

TF-M January 2020