- TF-M - lists.trustedfirmware.org

Cancelled event with note: TF-M Tech Forum @ Thu 1 Oct 2020 07:00 - 08:00 (BST) (tf-m@lists.trustedfirmware.org)

by Bill Fletcher

This event has been cancelled with this note: "To be rescheduled with the time corrected" Title: TF-M Tech Forum About TF-M Tech forum:This is an open forum for anyone to participate and it is not restricted to Trusted Firmware project members. It will operate under the guidance of the TF TSC.Feel free to forward it to colleagues.Details of previous meetings are here: https://www.trustedfirmware.org/meetings/tf-m-technical-forum/Tr… Firmware is inviting you to a scheduled Zoom meeting.Join Zoom Meetinghttps://zoom.us/j/9159704974Meeting ID: 915 970 4974One tap mobile+16465588656,,9159704974# US (New York)+16699009128,,9159704974# US (San Jose)Dial by your location        +1 646 558 8656 US (New York)        +1 669 900 9128 US (San Jose)        877 853 5247 US Toll-free        888 788 0099 US Toll-freeMeeting ID: 915 970 4974Find your local number: https://zoom.us/u/ad27hc6t7h   When: Thu 1 Oct 2020 07:00 – 08:00 United Kingdom Time Calendar: tf-m(a)lists.trustedfirmware.org Who: * Bill Fletcher- creator * Don Harbin * tf-m(a)lists.trustedfirmware.org Invitation from Google Calendar: https://www.google.com/calendar/ You are receiving this courtesy email at the account tf-m(a)lists.trustedfirmware.org because you are an attendee of this event. To stop receiving future updates for this event, decline this event. Alternatively, you can sign up for a Google Account at https://www.google.com/calendar/ and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to send a response to the organiser and be added to the guest list, invite others regardless of their own invitation status or to modify your RSVP. Learn more at https://support.google.com/calendar/answer/37135#forwarding

5 years

1
0
0 0

Re: [TF-M] X.509 Certificate Chain Support in TF-M

by Ronald Cron

Hi, I haven't dug into the details here but just wanted to point out that there is an x509 library in Mbed TLS. Thanks, Ronald. -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Abhishek Pandit via TF-M Sent: 28 September 2020 11:42 To: Soby Mathew <Soby.Mathew(a)arm.com>; David Brown <david.brown(a)linaro.org>; tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] X.509 Certificate Chain Support in TF-M Adding TF-M mailing list, in case anyone is interested in the topic. -----Original Message----- From: Soby Mathew <Soby.Mathew(a)arm.com> Sent: 24 September 2020 15:02 To: David Brown <david.brown(a)linaro.org> Cc: Abhishek Pandit <Abhishek.Pandit(a)arm.com>; Kevin Townsend <kevin.townsend(a)linaro.org>; Anton Komlev <Anton.Komlev(a)arm.com>; David Wang <David.Wang(a)arm.com>; Tamas Ban <Tamas.Ban(a)arm.com>; Shebu Varghese Kuriakose <Shebu.VargheseKuriakose(a)arm.com>; Adrian Shaw <Adrian.Shaw(a)arm.com> Subject: RE: X.509 Certificate Chain Support in TF-M [+Adrian] Hi David > To me, what might make some sense would be to have some kind of > restrictions on what can be done with the private key stored on the > secure side. If all operations are done through an extended API, > those would be the only operations permissible, whereas a generic > private key storage could allow rogue non-secure code to make use of > signing of other things, including signing non-resident data (one > device using another for attestation. At least the risks and costs of this should be considered. Thanks for the clarification. This would mean that given the current PSA Crypto design, the only way to achieve this would be to implement a custom RoT service in SPE. Hence the NSPE cannot make use of the key for arbitrary signing operation. > My primary concern with this solution at this point, is that we > haven't consider securing the protocol necessary to associate a > certificate/key pair with a particular device. Maybe we should be looking into SDO? Yes, that does seem like a good candidate. From my reading, several aspects of provisioning seem to be outside TF-M realm. > Having roots of trust instead of public keys (or certs) for direct > signing keys would give OEMs and other parties involved in the > firmware upgrade process more flexibility. > I see, thanks. We use certificate chains when firmware images need from different vendors need to be deployed in different privilege levels or multiple boot stages are present in A-profile. The Platform boot guide document https://developer.arm.com/documentation/den0072/0101/ mentions this as well. Possibly this is an enhancement to MCUBoot (Boot loader for TF-M). After talking with Adrian, I think there is consensus that certificate chain is a useful feature to have. So from my point of view, if there is some collaborative effort to develop such a service as TF-M specific extension, I think it would be very useful to the community. Best Regards Soby Mathew > -----Original Message----- > From: David Brown <david.brown(a)linaro.org> > Sent: 23 September 2020 19:12 > To: Soby Mathew <Soby.Mathew(a)arm.com> > Cc: Abhishek Pandit <Abhishek.Pandit(a)arm.com>; Kevin Townsend > <kevin.townsend(a)linaro.org>; Anton Komlev <Anton.Komlev(a)arm.com>; > David Wang <David.Wang(a)arm.com>; Tamas Ban <Tamas.Ban(a)arm.com>; Shebu > Varghese Kuriakose <Shebu.VargheseKuriakose(a)arm.com> > Subject: Re: X.509 Certificate Chain Support in TF-M > > On Wed, Sep 23, 2020 at 04:52:13PM +0000, Soby Mathew wrote: > > > I had a review and thanks for the excellent proposal, and it does > > make sense to me to add this support but some questions from my side: > > > > 1. Do you envisage the new CSR API and ability to store certificate blobs in > > secure world as an extension to PSA Attestation API ? > > 2. I know it is desirable to add this functionality to secure world, but to > > clear my mind, Is it possible to provide the same functionality from Non > > Secure side but making use of PSA crypto APIs ? For example the > > PSA > Crypto > > could export the public key and sign necessary data to create > > the CSR > from > > NS side. Similarly new keys can be imported to Crypto by NS > > world while > the > > certificate chains are maintained in NS world for non IAT services. I may > > have missed some key point. > > I agree that there is little reason to store the certificates > themselves on the secure side. If they were modified or tampered > with, there would no longer be a private key to make use of them. > > > My primary concern with this solution at this point, is that we > haven't consider securing the protocol necessary to associate a > certificate/key pair with a particular device. Maybe we should be looking into SDO? > > > 3. I understood how we can make use of certificate chains for > > attestation, > but > > it is less clear how this can be made use of while booting firmware images. > > Could you elaborate more ? > > Only in the sense of allowing a signed firmware image to have a > certificate chain with it. Having roots of trust instead of public > keys (or certs) for direct signing keys would give OEMs and other > parties involved in the firmware upgrade process more flexibility. > > David -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years

1
0
0 0

Re: [TF-M] X.509 Certificate Chain Support in TF-M

by Abhishek Pandit

Adding TF-M mailing list, in case anyone is interested in the topic. -----Original Message----- From: Soby Mathew <Soby.Mathew(a)arm.com> Sent: 24 September 2020 15:02 To: David Brown <david.brown(a)linaro.org> Cc: Abhishek Pandit <Abhishek.Pandit(a)arm.com>; Kevin Townsend <kevin.townsend(a)linaro.org>; Anton Komlev <Anton.Komlev(a)arm.com>; David Wang <David.Wang(a)arm.com>; Tamas Ban <Tamas.Ban(a)arm.com>; Shebu Varghese Kuriakose <Shebu.VargheseKuriakose(a)arm.com>; Adrian Shaw <Adrian.Shaw(a)arm.com> Subject: RE: X.509 Certificate Chain Support in TF-M [+Adrian] Hi David > To me, what might make some sense would be to have some kind of > restrictions on what can be done with the private key stored on the > secure side. If all operations are done through an extended API, > those would be the only operations permissible, whereas a generic > private key storage could allow rogue non-secure code to make use of > signing of other things, including signing non-resident data (one > device using another for attestation. At least the risks and costs of this should be considered. Thanks for the clarification. This would mean that given the current PSA Crypto design, the only way to achieve this would be to implement a custom RoT service in SPE. Hence the NSPE cannot make use of the key for arbitrary signing operation. > My primary concern with this solution at this point, is that we > haven't consider securing the protocol necessary to associate a > certificate/key pair with a particular device. Maybe we should be looking into SDO? Yes, that does seem like a good candidate. From my reading, several aspects of provisioning seem to be outside TF-M realm. > Having roots of trust instead of public keys (or certs) for direct > signing keys would give OEMs and other parties involved in the > firmware upgrade process more flexibility. > I see, thanks. We use certificate chains when firmware images need from different vendors need to be deployed in different privilege levels or multiple boot stages are present in A-profile. The Platform boot guide document https://developer.arm.com/documentation/den0072/0101/ mentions this as well. Possibly this is an enhancement to MCUBoot (Boot loader for TF-M). After talking with Adrian, I think there is consensus that certificate chain is a useful feature to have. So from my point of view, if there is some collaborative effort to develop such a service as TF-M specific extension, I think it would be very useful to the community. Best Regards Soby Mathew > -----Original Message----- > From: David Brown <david.brown(a)linaro.org> > Sent: 23 September 2020 19:12 > To: Soby Mathew <Soby.Mathew(a)arm.com> > Cc: Abhishek Pandit <Abhishek.Pandit(a)arm.com>; Kevin Townsend > <kevin.townsend(a)linaro.org>; Anton Komlev <Anton.Komlev(a)arm.com>; > David Wang <David.Wang(a)arm.com>; Tamas Ban <Tamas.Ban(a)arm.com>; Shebu > Varghese Kuriakose <Shebu.VargheseKuriakose(a)arm.com> > Subject: Re: X.509 Certificate Chain Support in TF-M > > On Wed, Sep 23, 2020 at 04:52:13PM +0000, Soby Mathew wrote: > > > I had a review and thanks for the excellent proposal, and it does > > make sense to me to add this support but some questions from my side: > > > > 1. Do you envisage the new CSR API and ability to store certificate blobs in > > secure world as an extension to PSA Attestation API ? > > 2. I know it is desirable to add this functionality to secure world, but to > > clear my mind, Is it possible to provide the same functionality from Non > > Secure side but making use of PSA crypto APIs ? For example the > > PSA > Crypto > > could export the public key and sign necessary data to create > > the CSR > from > > NS side. Similarly new keys can be imported to Crypto by NS > > world while > the > > certificate chains are maintained in NS world for non IAT services. I may > > have missed some key point. > > I agree that there is little reason to store the certificates > themselves on the secure side. If they were modified or tampered > with, there would no longer be a private key to make use of them. > > > My primary concern with this solution at this point, is that we > haven't consider securing the protocol necessary to associate a > certificate/key pair with a particular device. Maybe we should be looking into SDO? > > > 3. I understood how we can make use of certificate chains for > > attestation, > but > > it is less clear how this can be made use of while booting firmware images. > > Could you elaborate more ? > > Only in the sense of allowing a signed firmware image to have a > certificate chain with it. Having roots of trust instead of public > keys (or certs) for direct signing keys would give OEMs and other > parties involved in the firmware upgrade process more flexibility. > > David

5 years

1
0
0 0

Cypress PSoC64 support update

by Andrei Narkevitch

Hi all, Just to let you know, some time ago Cypress has officially released the PSoC64 platform. With this, we are planning to stop supporting old PSoC64 development kits and move our focus on the new release boards. This is mainly because the old boards were programmed with an old firmware which is not compatible with the changes we do to the TFM code and it would be an unnecessary overhead to support both versions. Please let us know if it causes any issues. The new PSoC64 kit: https://www.cypress.com/documentation/development-kitsboards/psoc-64-standa… Thanks, Andrei Narkevitch Cypress Semiconductor Corp. An Infineon Technologies Company 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.

5 years, 1 month

1
0
0 0

Invitation: TF-M Tech Forum @ Thu 1 Oct 2020 07:00 - 08:00 (BST) (tf-m@lists.trustedfirmware.org)

by Bill Fletcher

You have been invited to the following event. Title: TF-M Tech Forum About TF-M Tech forum:This is an open forum for anyone to participate and it is not restricted to Trusted Firmware project members. It will operate under the guidance of the TF TSC.Feel free to forward it to colleagues.Details of previous meetings are here: https://www.trustedfirmware.org/meetings/tf-m-technical-forum/Tr… Firmware is inviting you to a scheduled Zoom meeting.Join Zoom Meetinghttps://zoom.us/j/9159704974Meeting ID: 915 970 4974One tap mobile+16465588656,,9159704974# US (New York)+16699009128,,9159704974# US (San Jose)Dial by your location        +1 646 558 8656 US (New York)        +1 669 900 9128 US (San Jose)        877 853 5247 US Toll-free        888 788 0099 US Toll-freeMeeting ID: 915 970 4974Find your local number: https://zoom.us/u/ad27hc6t7h   When: Thu 1 Oct 2020 07:00 – 08:00 United Kingdom Time Calendar: tf-m(a)lists.trustedfirmware.org Who: * Bill Fletcher- creator * Don Harbin * tf-m(a)lists.trustedfirmware.org Event details: https://www.google.com/calendar/event?action=VIEW&eid=N250M2VrZnZtMnY0MjU3d… Invitation from Google Calendar: https://www.google.com/calendar/ You are receiving this courtesy email at the account tf-m(a)lists.trustedfirmware.org because you are an attendee of this event. To stop receiving future updates for this event, decline this event. Alternatively, you can sign up for a Google Account at https://www.google.com/calendar/ and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to send a response to the organiser and be added to the guest list, invite others regardless of their own invitation status or to modify your RSVP. Learn more at https://support.google.com/calendar/answer/37135#forwarding

5 years, 1 month

1
0
0 0

Invitation: TF-M Tech Forum @ Thu 15 Oct 2020 16:00 - 17:00 (BST) (tf-m@lists.trustedfirmware.org)

by Bill Fletcher

You have been invited to the following event. Title: TF-M Tech Forum About TF-M Tech forum:This is an open forum for anyone to participate and it is not restricted to Trusted Firmware project members. It will operate under the guidance of the TF TSC.Feel free to forward it to colleagues.Details of previous meetings are here: https://www.trustedfirmware.org/meetings/tf-m-technical-forum/Tr… Firmware is inviting you to a scheduled Zoom meeting.Join Zoom Meetinghttps://zoom.us/j/9159704974Meeting ID: 915 970 4974One tap mobile+16465588656,,9159704974# US (New York)+16699009128,,9159704974# US (San Jose)Dial by your location        +1 646 558 8656 US (New York)        +1 669 900 9128 US (San Jose)        877 853 5247 US Toll-free        888 788 0099 US Toll-freeMeeting ID: 915 970 4974Find your local number: https://zoom.us/u/ad27hc6t7h   When: Thu 15 Oct 2020 16:00 – 17:00 United Kingdom Time Calendar: tf-m(a)lists.trustedfirmware.org Who: * Bill Fletcher- creator * Don Harbin * tf-m(a)lists.trustedfirmware.org Event details: https://www.google.com/calendar/event?action=VIEW&eid=MjRoajVlNjRuczZqYWIwN… Invitation from Google Calendar: https://www.google.com/calendar/ You are receiving this courtesy email at the account tf-m(a)lists.trustedfirmware.org because you are an attendee of this event. To stop receiving future updates for this event, decline this event. Alternatively, you can sign up for a Google Account at https://www.google.com/calendar/ and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to send a response to the organiser and be added to the guest list, invite others regardless of their own invitation status or to modify your RSVP. Learn more at https://support.google.com/calendar/answer/37135#forwarding

5 years, 1 month

1
0
0 0

New buildsystem merged

by Raef Coles

Hi all The new buildsystem has now been merged to both the trusted-firmware-m and tf-m-tests repositories. There are a few known issues: * STM platforms run into issues with flash space when building under debug configuration. * nxp/lpcxpresso66s69 fails regression tests - this is being looked into as a priority. For building with the new buildsystem, there have been some changes to the command-line. An example invocation is shown below. ``` cd <TFM root dir> mkdir build && cd build cmake .. -DTFM_PLATFORM=mps2/an521 -DCMAKE_TOOLCHAIN_FILE=../toolchain_GNUARM.cmake make ``` CMAKE_TOOLCHAIN_FILE and TFM_PLATFORM are the only required arguments. CMAKE_TOOLCHAIN_FILE is conceptually a replacement for COMPILER. It is a path to one of the three toolchain files in the TFM root dir. * <TFM root dir>/toolchain_GNUARM.cmake * <TFM root dir>/toolchain_ARMCLANG.cmake * <TFM root dir>/toolchain_IARARM.cmake TFM_PLATFORM is conceptually a replacement for TARGET_PLATFORM. Unlike TARGET_PLATFORM it takes as an argument the path between `platform/ext/target` and the target dir. For example: * -DTFM_PLATFORM=musca_s1 * -DTFM_PLATFORM=cypress/psoc64 * -DTFM_PLATFORM=nxp/lpcxpresso55s69 PROJ_CONFIG has now been removed. Instead configuration has been simplified using composable variables. Enable regression tests: -DTEST_NS=ON -DTEST_S=ON Enable IPC mode: -DTFM_PSA_API=ON Set isolation level: -DTFM_ISOLATION_LEVEL=2 So instead of ConfigRegressionIPC: -DTEST_NS=ON -DTEST_S=ON -DTFM_PSA_API=ON For integration with other projects, there is a new option: -DNS=[ON/OFF] If NS is set to OFF, TFM will build only the secure image (as bin tfm_s.axf) and the PSA api as a static library. This should make integration with other projects much simpler. Other miscellaneous improvements: * Full ninja support * Automatic dependency management * generation of axf, elf, hex and bin files for all outputs * Full support for partial rebuilding and parallel building * Modular support for crypto accelerators * better integration of multi-core support For full details of buildsystem variable changes, refer to `docs/getting_started/tfm_build_instructions.rst` and `config/config_default.cmake` Raef

5 years, 1 month

1
0
0 0

Re: [TF-M] Proposal to separate SCT/LD into each platform folder

by Ken Liu

Thanks all for the inputs. May I collect answers for these questions: * Does the build system/IDE support sub-project for components and finally assemble them into one final image? The intention is to check the possibility to integrate TFM with sub-projects instead of a whole item. * Is there scenarios that dynamic sections being added into sct/ld, how do you deal with this? A reference link is also helpful. The intention: TF-M is actually a set of components, and the secure firmware part (secure boot is another image binary so not listed here) contains: 1. Libraries. 2. Partitions. 3. SPM. 4. Image assembling with all above components. The straight way is to generate ABC as *.a and assemble them together into a final image. Then go through each component, A and C can be configured in C domain, as what they needs maybe just some feature flags. B is a bit special but we still could provide specification defined .json and its compatible .yaml manifest and pre-generated C-based manifest with preprocessors. D is the hard part, as it needs special arrangement inside ld/sct, which make this discussion happen. Even the ‘include’ and ‘preprocessor’ are supported inside sct/ld, we still can not avoid the partitions including part, we can not do a foreach on the partition list which involve the preprocessor complexity into sct/ld. Looks like the templating can’t be avoided here. For platform specific requirements like: * Some platform won’t separate RODATA and CODE; * Some platform got non-continuous memory regions for special data; Put a platform dedicated sct/ld into the platform folder would help; but to mitigate the effort of platform, a common sct/ld needs to be abstracted. Thanks again for your great feedback. /Ken [History collapsed due to message size limitation]

5 years, 1 month

1
0
0 0

Re: [TF-M] Proposal to separate SCT/LD into each platform folder

by Reed Hinkel

Hello Gyrogy: Your comment raises the question. Why is TF-M so complex and does it need to be the only answer? Either it needs to be simplified or respect must be paid to support in commercial tools as a first class citizen. Commercial tools are the path for large scale product developers. If they can’t engage TF-M with commercial tools or SiP tools then developers will face challenges to develop with it. It there are challenges they may even avoid using it in favor of simplified solutions much as they do today. Multiple target use cases will be using various components of TF-M (MbedTLS with and without hardware interfaces, Attestation, Audit Logs, etc.): 1. Arm v8M – Cortex-M33, M35, M55 2. Dual Core Systems – Multiple possible configs 3. Cortex v6M of v7M – M0, M0+, M3 & M4 4. TF-A 5. Other Cortex-R & Cortex-A implementations This reality argues for a more modular build packaging system that allows for it. All the best! Reed From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Gyorgy Szing via TF-M <tf-m(a)lists.trustedfirmware.org> Reply-To: Gyorgy Szing <Gyorgy.Szing(a)arm.com> Date: Wednesday, September 23, 2020 at 5:04 AM To: "tf-m(a)lists.trustedfirmware.org" <tf-m(a)lists.trustedfirmware.org> Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Proposal to separate SCT/LD into each platform folder Hi Andrej, TF-M relies heavily on compile time configuration, and C is quiet limited on that. This means we cannot rely on the only standardized part of the “ecosystem” solely, and we have to use non-standard tools. I would love to have a portable automation solution supported by most IDEs. Yes, a lot of projects can go well with a single configuration header but unfortunately TF-M is more complex than that: * How could we get information from manifest files to the build? * How could we generate signed binary packages for the boot-loader? * How could we control memory map in sync with the hw configuration in source files? (The current pre-processing linker files approach is already non-standard.) None of these can be solved with IDEs in a portable way. I understand that adding IDE support for TF-M is challenging but the root cause is not how we implemented the build system, but how IDEs can handle the complexity needed by TF-M. /George From: Andrej Butok <andrey.butok(a)nxp.com> Sent: 23 September 2020 09:33 To: Gyorgy Szing <Gyorgy.Szing(a)arm.com>; Ken Liu <Ken.Liu(a)arm.com> Cc: nd <nd(a)arm.com> Subject: RE: [TF-M] Proposal to separate SCT/LD into each platform folder Hi Ken, So we are using one default/typical configuration. If any change in it, a user have to do changes manually which are not clear without deeper knowledge of the TFM project. But this is the issue of the TF-M chosen approach - fully rely on cmake preprocessing. The proposal is to use approach which is good for all worlds (cmake and IDEs) and which is used by all embedded MCU open-source projects like MbedTLS, FreeRTOS, lwIP, FNET and etc. Which is to have only one set of platform-independent files and the framework configuration from a user/project configuration file. It will work for both worlds, will solve all configuration issues we have, and will make TF-M easy to use and more popular. I am talking about this from very beginning. As no steps in right direction, we have a forked TF-M for our SDK. Thanks George for support ;) Andrej Butok 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: Wednesday, September 23, 2020 8:45 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: Re: [TF-M] Proposal to separate SCT/LD into each platform folder Hi Andrej, Sounds like your IDE is using the default .sct/.ld file, may I ask some a question that: * Is there a scenario that someone wants to add more partitions other than the default ones into your system, and how could they do that? I believe the existing .sct/.ld do not support extra partitions out of the default ones unless some manually modification is done. We need to support more components (partition is the direct example), so in this case, the sct/ld can’t be avoided to be modified. Or do you think if we put a specific .sct/.ld under nxp folder would work if there is no other partitions are needed? Thanks. /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Gyorgy Szing via TF-M Sent: Wednesday, September 23, 2020 8:46 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: Re: [TF-M] Proposal to separate SCT/LD into each platform folder Hi, Good point, this is an important factor. I think templating can be IDE compliant as long as the IDE does support pre-build step(s). The current build flow already contains steps requiring this and thus I don’t think situation would be much worse with any mentioned solution than it is today. /George 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: 23 September 2020 08:33 To: Ken Liu <Ken.Liu(a)arm.com<mailto:Ken.Liu@arm.com>> Cc: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: Re: [TF-M] Proposal to separate SCT/LD into each platform folder Please, do not add changes to sources & linker-files which may harm Non-Cmake systems (IDEs). Thanks, Andrej Butok 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: Wednesday, September 23, 2020 8:05 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: Re: [TF-M] Proposal to separate SCT/LD into each platform folder As cmake is still the build system, let me check the cmake related feature – but need to wait the build system change get merged then we can take a look where to start. BR. /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Gyorgy Szing via TF-M Sent: Tuesday, September 22, 2020 4:43 PM To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: Re: [TF-M] Proposal to separate SCT/LD into each platform folder Hi Ken, I think templating is a good approach here, the current C preprocessor based solution is a very limited implementation of this. I see two main contenders for templating: 1. cmake has built in support for templating with the configure_file() [1] command. This would move ownership of this information info the build scripts, which are the focus point for such info already. A cmake based solution would feel more native to the existing system. On the other hand other solutions might have more features, which could lead to easier to read template files. Also cmake as a template engine is not that widely adopted. 2. jinja2 [2]. A widely adopted and more feature rich templating engine. TF-M already uses it for manifest file handling. I suggest using yahsa [3] instead of a custom pyhton script as the cli frontend though. This could speed up development as long as no complex processing is needed and the templates can be filled based on “simple” values. Which of the above is the best for the task depends on template file readability and on complexity of the task. It could be nice if a clean split could be made, and we could stop using the C preprocessor based processing completely. “Not sure if all these format support #include” The build system works around that by implementing a compiler specific cmake function to add the pre-processing step for compilers not supporting pre-processing out of the box. /George [1] https://cmake.org/cmake/help/v3.18/command/configure_file.html<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcmake.org…> [2] https://jinja.palletsprojects.com/en/2.11.x/<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fjinja.pal…> [3] https://github.com/kblomqvist/yasha<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co…> 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: 22 September 2020 10:15 To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: Re: [TF-M] Proposal to separate SCT/LD into each platform folder Hi, During the level3 prototyping, we found using a unified sct/ld/file would be hard because we are trying to cover platform-specific setting in ONE place. The biggest concern of preventing spreading the LD is: if there are COMMON changes then every platform source needs to be updated. I believe the COMMON change is the arrangement of ARoT and PRoT, those platform-specific things such as CODE_SRAM and MPU alignment issue should not be covered inside the common sct/ld/icf. Not sure if all these format support #include but as we are using a template so it should be possible to put COMMON settings inside a COMMON template and let platform to contain these common part and then add the specific settings. I have a rough idea (see above) and need more investigation, request for ideas/concerns about this part. Thanks. /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Shawn Shan via TF-M Sent: Wednesday, August 5, 2020 1:27 PM 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] Proposal to separate SCT/LD into each platform folder Hi all, There are many differences in linker scripts between each platform. Using a common_s.sct/ld makes it too complicated. And at the same time, in order to achieve isolation level 3, the position of the sessions in scatter and linker script file needs to be adjusted. The common linker scripts would be more complicated with isolation L3. So I would like to propose to have dedicated linker scripts for platforms with enough differential arrangements. What’s your opinion on this? Best regards, Shawn

5 years, 1 month

2
2
0 0

Re: [TF-M] Proposal to separate SCT/LD into each platform folder

by Soby Mathew

Thanks Gyorgy for your inputs. I haven't checked out the details of all the pre-build processing, but it does seem complex to solve this in a portable way, but one suggestion from me is that perhaps the output from the pre-build processing should be a standard C header and from then on the standardized C pre-processing can be used for the rest of the configuration. For example, instead of the pre-build step generating producing the final linker script , it could instead generate a C header file which then can be consumed by the linker script. Here only the C header is generated and the linker script is untouched. This means that, if the IDEs can find a path to generate this C header file somehow (either via IDE configuration or different custom pre-build processing), then rest of the setup continues in a C standard way. Best regards Soby Mathew From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Gyorgy Szing via TF-M Sent: 23 September 2020 11:04 To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Proposal to separate SCT/LD into each platform folder Hi Andrej, TF-M relies heavily on compile time configuration, and C is quiet limited on that. This means we cannot rely on the only standardized part of the "ecosystem" solely, and we have to use non-standard tools. I would love to have a portable automation solution supported by most IDEs. Yes, a lot of projects can go well with a single configuration header but unfortunately TF-M is more complex than that: * How could we get information from manifest files to the build? * How could we generate signed binary packages for the boot-loader? * How could we control memory map in sync with the hw configuration in source files? (The current pre-processing linker files approach is already non-standard.) None of these can be solved with IDEs in a portable way. I understand that adding IDE support for TF-M is challenging but the root cause is not how we implemented the build system, but how IDEs can handle the complexity needed by TF-M. /George From: Andrej Butok <andrey.butok(a)nxp.com<mailto:andrey.butok@nxp.com>> Sent: 23 September 2020 09:33 To: Gyorgy Szing <Gyorgy.Szing(a)arm.com<mailto:Gyorgy.Szing@arm.com>>; Ken Liu <Ken.Liu(a)arm.com<mailto:Ken.Liu@arm.com>> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: RE: [TF-M] Proposal to separate SCT/LD into each platform folder Hi Ken, So we are using one default/typical configuration. If any change in it, a user have to do changes manually which are not clear without deeper knowledge of the TFM project. But this is the issue of the TF-M chosen approach - fully rely on cmake preprocessing. The proposal is to use approach which is good for all worlds (cmake and IDEs) and which is used by all embedded MCU open-source projects like MbedTLS, FreeRTOS, lwIP, FNET and etc. Which is to have only one set of platform-independent files and the framework configuration from a user/project configuration file. It will work for both worlds, will solve all configuration issues we have, and will make TF-M easy to use and more popular. I am talking about this from very beginning. As no steps in right direction, we have a forked TF-M for our SDK. Thanks George for support ;) Andrej Butok 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: Wednesday, September 23, 2020 8:45 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: Re: [TF-M] Proposal to separate SCT/LD into each platform folder Hi Andrej, Sounds like your IDE is using the default .sct/.ld file, may I ask some a question that: * Is there a scenario that someone wants to add more partitions other than the default ones into your system, and how could they do that? I believe the existing .sct/.ld do not support extra partitions out of the default ones unless some manually modification is done. We need to support more components (partition is the direct example), so in this case, the sct/ld can't be avoided to be modified. Or do you think if we put a specific .sct/.ld under nxp folder would work if there is no other partitions are needed? Thanks. /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Gyorgy Szing via TF-M Sent: Wednesday, September 23, 2020 8:46 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: Re: [TF-M] Proposal to separate SCT/LD into each platform folder Hi, Good point, this is an important factor. I think templating can be IDE compliant as long as the IDE does support pre-build step(s). The current build flow already contains steps requiring this and thus I don't think situation would be much worse with any mentioned solution than it is today. /George 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: 23 September 2020 08:33 To: Ken Liu <Ken.Liu(a)arm.com<mailto:Ken.Liu@arm.com>> Cc: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: Re: [TF-M] Proposal to separate SCT/LD into each platform folder Please, do not add changes to sources & linker-files which may harm Non-Cmake systems (IDEs). Thanks, Andrej Butok 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: Wednesday, September 23, 2020 8:05 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: Re: [TF-M] Proposal to separate SCT/LD into each platform folder As cmake is still the build system, let me check the cmake related feature - but need to wait the build system change get merged then we can take a look where to start. BR. /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Gyorgy Szing via TF-M Sent: Tuesday, September 22, 2020 4:43 PM To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: Re: [TF-M] Proposal to separate SCT/LD into each platform folder Hi Ken, I think templating is a good approach here, the current C preprocessor based solution is a very limited implementation of this. I see two main contenders for templating: 1. cmake has built in support for templating with the configure_file() [1] command. This would move ownership of this information info the build scripts, which are the focus point for such info already. A cmake based solution would feel more native to the existing system. On the other hand other solutions might have more features, which could lead to easier to read template files. Also cmake as a template engine is not that widely adopted. 2. jinja2 [2]. A widely adopted and more feature rich templating engine. TF-M already uses it for manifest file handling. I suggest using yahsa [3] instead of a custom pyhton script as the cli frontend though. This could speed up development as long as no complex processing is needed and the templates can be filled based on "simple" values. Which of the above is the best for the task depends on template file readability and on complexity of the task. It could be nice if a clean split could be made, and we could stop using the C preprocessor based processing completely. "Not sure if all these format support #include" The build system works around that by implementing a compiler specific cmake function to add the pre-processing step for compilers not supporting pre-processing out of the box. /George [1] https://cmake.org/cmake/help/v3.18/command/configure_file.html<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcmake.org…> [2] https://jinja.palletsprojects.com/en/2.11.x/<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fjinja.pal…> [3] https://github.com/kblomqvist/yasha<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co…> 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: 22 September 2020 10:15 To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: Re: [TF-M] Proposal to separate SCT/LD into each platform folder Hi, During the level3 prototyping, we found using a unified sct/ld/file would be hard because we are trying to cover platform-specific setting in ONE place. The biggest concern of preventing spreading the LD is: if there are COMMON changes then every platform source needs to be updated. I believe the COMMON change is the arrangement of ARoT and PRoT, those platform-specific things such as CODE_SRAM and MPU alignment issue should not be covered inside the common sct/ld/icf. Not sure if all these format support #include but as we are using a template so it should be possible to put COMMON settings inside a COMMON template and let platform to contain these common part and then add the specific settings. I have a rough idea (see above) and need more investigation, request for ideas/concerns about this part. Thanks. /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Shawn Shan via TF-M Sent: Wednesday, August 5, 2020 1:27 PM 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] Proposal to separate SCT/LD into each platform folder Hi all, There are many differences in linker scripts between each platform. Using a common_s.sct/ld makes it too complicated. And at the same time, in order to achieve isolation level 3, the position of the sessions in scatter and linker script file needs to be adjusted. The common linker scripts would be more complicated with isolation L3. So I would like to propose to have dedicated linker scripts for platforms with enough differential arrangements. What's your opinion on this? Best regards, Shawn

5 years, 1 month

2
1
0 0

2025

2024

2023

2022

2021

2020

2019

2018

TF-M