- TF-M - lists.trustedfirmware.org

Re: [TF-M] Externally override flash layout and pin configurations (out-of-tree platforms?)

by Rønningstad, Øyvind

I've created a proof of concept for allowing out-of-tree platforms here: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/7301 It was simpler than I had thought :) Øyvind From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu via TF-M Sent: Thursday, November 26, 2020 07:57 To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Externally override flash layout and pin configurations (out-of-tree platforms?) Hi, In the ideal case with HAL API, the platform itself can decide which variant's layout to be applied, selected by build system switches or just some header files. Because SPM could get what it needed by HAL API run-time. It can be mostly done inside the platform folder if one platform has the variants management already. Others please give inputs as this is a very useful topic, we can list down the problem we met during integration first. BR /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Rønningstad, Øyvind via TF-M Sent: Thursday, November 26, 2020 3:47 AM To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Cc: Rasmussen, Torsten <Torsten.Rasmussen(a)nordicsemi.no<mailto:Torsten.Rasmussen@nordicsemi.no>> Subject: [TF-M] Externally override flash layout and pin configurations (out-of-tree platforms?) Hi all In our work integrating TFM into Zephyr and the nRF Connect SDK, it's apparent that the integration would be a lot smoother if we could specify TFM's flash layout externally. Looking into it a bit, I came up with a draft proposal here: https://github.com/zephyrproject-rtos/trusted-firmware-m/pull/18/files<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co…> We could just modify our own platforms to this and be happy, but I'm wondering if there would be interest in standardizing something. Now, a related problem is: How can we make it easier to add multiple boards based on a single chip. For the Nordic platforms we've already separated the chip-specific code (nRF9160/nRF5340) from the board specific code (DK/PDK), and for the boards, it really boils down to pin configurations. We could allow to specify pins via Cmake instead, to easily allow users to support their production PCBs. But (this was brought up in the above PR) we can also solve both problems by adding support for out-of-tree platforms. For example, allow TFM to be built like so: cmake -DTFM_PLATFORM=../../../../my_custom_board ... This would probably be less work that designing a new interface for overriding flash layouts and pin configurations. What are your thoughts? BR, Øyvind Rønningstad

5 years, 7 months

1
0
0 0

Review request for adding External Trusted Secure Storage service in TF-M

by Edward Yang

Hi everyone, Please help review the following design proposal of adding External Trusted Secure Storage service in TF-M,any comments and suggestions will be appreciated. https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/7295 Best Regards, Poppy Wu Macronix Microelectronics (Suzhou) Co.,Ltd http://www.mxic.com.cn ======================================================== ============================================================================ CONFIDENTIALITY NOTE: This e-mail and any attachments may contain confidential information and/or personal data, which is protected by applicable laws. Please be reminded that duplication, disclosure, distribution, or use of this e-mail (and/or its attachments) or any part thereof is prohibited. If you receive this e-mail in error, please notify us immediately and delete this mail as well as its attachment(s) from your system. In addition, please be informed that collection, processing, and/or use of personal data is prohibited unless expressly permitted by personal data protection laws. Thank you for your attention and cooperation. Macronix International Co., Ltd. =====================================================================

5 years, 7 months

1
0
0 0

Review request for adding External Trusted Secure Storage service in TF-M

by Edward Yang

Hi everyone, Please help review the following design proposal of adding External Trusted Secure Storage service in TF-M,any comments and suggestions will be appreciated. https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/7295 Best Regards, Poppy Wu Macronix Microelectronics (Suzhou) Co.,Ltd http://www.mxic.com.cn ======================================================== ============================================================================ CONFIDENTIALITY NOTE: This e-mail and any attachments may contain confidential information and/or personal data, which is protected by applicable laws. Please be reminded that duplication, disclosure, distribution, or use of this e-mail (and/or its attachments) or any part thereof is prohibited. If you receive this e-mail in error, please notify us immediately and delete this mail as well as its attachment(s) from your system. In addition, please be informed that collection, processing, and/or use of personal data is prohibited unless expressly permitted by personal data protection laws. Thank you for your attention and cooperation. Macronix International Co., Ltd. =====================================================================

5 years, 7 months

1
0
0 0

Deprecation of platform MPS2/SSE-200_AWS

by Marton Berke

Hi Everyone, I would like to propose the deprecation of platform MPS2/SSE-200_AWS because the platform is no longer available to use: https://aws.amazon.com/marketplace/pp/ARM-Ltd-DesignStart-FPGA-on-Cloud-Cor… As per the process, this proposal is open for discussion for a period of 4 weeks and if there are no major objections, the platform should be marked as deprecated and removed from TF-M master after next release. Thanks and Best regards, Marton Berke

5 years, 7 months

1
0
0 0

Re: [TF-M] Technical Forum call - November 26

by Karl Zhang

Hi Anton I would have an introduction to TF-M openCI. Thanks Karl ________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of David Hu via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: Monday, November 23, 2020 2:10 PM To: Anton Komlev <Anton.Komlev(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] Technical Forum call - November 26 Hi Anton, I’d like to share a proposal to improve dual-cpu mailbox. Best regards, Hu Ziji From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M Sent: Thursday, November 19, 2020 4:59 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] Technical Forum call - November 26 Hello, The next Technical Forum is planned on Thursday, November 26 at 15:00-16:00 GMT (US friendly time zone). Please reply on this email with your proposals for agenda topics. Recording and slides of previous meetings are here: https://www.trustedfirmware.org/meetings/tf-m-technical-forum/ Best regards, Anton

5 years, 7 months

2
1
0 0

Re: [TF-M] gcc compiler requirement documentation

by Shawn Shan

Hi Chris, Thanks for point out this. Here is the fix: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/7226 Regards, Shawn From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Christopher Brand via TF-M Sent: Thursday, November 26, 2020 2:55 AM To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] gcc compiler requirement documentation Looking at docs/getting_started//tfm_sw_requirement.rst it says that the version requirement for gcc is "GNU Arm compiler v7.3.1+". then it describes where to get that toolchain, but in that section the two versions it suggests are "GNU Arm Embedded Toolchain: 6-2017-q1-update" and "GNU Arm Embedded Toolchain: 7-2018-q2-update". The former is gcc version 6.3.1, which doesn't actually meet the requirements. Chris Brand Sr Prin Software Engr, MCD: WIRELESS Cypress Semiconductor Corp. An Infineon Technologies Company #320-13700 International Place, Richmond, British Columbia V6V 2X8 Canada www.infineon.com<http://www.infineon.com> www.cypress.com<http://www.cypress.com> 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, 7 months

1
0
0 0

Re: [TF-M] Externally override flash layout and pin configurations (out-of-tree platforms?)

by Ken Liu

Hi, In the ideal case with HAL API, the platform itself can decide which variant's layout to be applied, selected by build system switches or just some header files. Because SPM could get what it needed by HAL API run-time. It can be mostly done inside the platform folder if one platform has the variants management already. Others please give inputs as this is a very useful topic, we can list down the problem we met during integration first. BR /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Rønningstad, Øyvind via TF-M Sent: Thursday, November 26, 2020 3:47 AM To: tf-m(a)lists.trustedfirmware.org Cc: Rasmussen, Torsten <Torsten.Rasmussen(a)nordicsemi.no> Subject: [TF-M] Externally override flash layout and pin configurations (out-of-tree platforms?) Hi all In our work integrating TFM into Zephyr and the nRF Connect SDK, it's apparent that the integration would be a lot smoother if we could specify TFM's flash layout externally. Looking into it a bit, I came up with a draft proposal here: https://github.com/zephyrproject-rtos/trusted-firmware-m/pull/18/files We could just modify our own platforms to this and be happy, but I'm wondering if there would be interest in standardizing something. Now, a related problem is: How can we make it easier to add multiple boards based on a single chip. For the Nordic platforms we've already separated the chip-specific code (nRF9160/nRF5340) from the board specific code (DK/PDK), and for the boards, it really boils down to pin configurations. We could allow to specify pins via Cmake instead, to easily allow users to support their production PCBs. But (this was brought up in the above PR) we can also solve both problems by adding support for out-of-tree platforms. For example, allow TFM to be built like so: cmake -DTFM_PLATFORM=../../../../my_custom_board ... This would probably be less work that designing a new interface for overriding flash layouts and pin configurations. What are your thoughts? BR, Øyvind Rønningstad

5 years, 7 months

1
0
0 0

Externally override flash layout and pin configurations (out-of-tree platforms?)

by Rønningstad, Øyvind

Hi all In our work integrating TFM into Zephyr and the nRF Connect SDK, it's apparent that the integration would be a lot smoother if we could specify TFM's flash layout externally. Looking into it a bit, I came up with a draft proposal here: https://github.com/zephyrproject-rtos/trusted-firmware-m/pull/18/files We could just modify our own platforms to this and be happy, but I'm wondering if there would be interest in standardizing something. Now, a related problem is: How can we make it easier to add multiple boards based on a single chip. For the Nordic platforms we've already separated the chip-specific code (nRF9160/nRF5340) from the board specific code (DK/PDK), and for the boards, it really boils down to pin configurations. We could allow to specify pins via Cmake instead, to easily allow users to support their production PCBs. But (this was brought up in the above PR) we can also solve both problems by adding support for out-of-tree platforms. For example, allow TFM to be built like so: cmake -DTFM_PLATFORM=../../../../my_custom_board ... This would probably be less work that designing a new interface for overriding flash layouts and pin configurations. What are your thoughts? BR, Øyvind Rønningstad

5 years, 7 months

1
0
0 0

gcc compiler requirement documentation

by Christopher Brand

Looking at docs/getting_started//tfm_sw_requirement.rst it says that the version requirement for gcc is "GNU Arm compiler v7.3.1+". then it describes where to get that toolchain, but in that section the two versions it suggests are "GNU Arm Embedded Toolchain: 6-2017-q1-update" and "GNU Arm Embedded Toolchain: 7-2018-q2-update". The former is gcc version 6.3.1, which doesn't actually meet the requirements. Chris Brand Sr Prin Software Engr, MCD: WIRELESS Cypress Semiconductor Corp. An Infineon Technologies Company #320-13700 International Place, Richmond, British Columbia V6V 2X8 Canada www.infineon.com<http://www.infineon.com> www.cypress.com<http://www.cypress.com> 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, 7 months

1
0
0 0

Re: [TF-M] MCUBOOT_LOG_LEVEL description confusing/wrong

by Tamas Ban

Hi Thomas, Here is the fix: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/7196 Actually since the CMake refactor the default value can be overridden from the command line, so it is possible to enable the logging even in Release builds. BR Tamas -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Thomas Törnblom via TF-M Sent: 2020. november 25., szerda 8:50 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] MCUBOOT_LOG_LEVEL description confusing/wrong The description of how to set MCUBOOT_LOG_LEVEL in tfm_secure_boot.rst appears wrong, or at least unclear. --- - MCUBOOT_LOG_LEVEL: Can be used to configure the level of logging in MCUBoot. The possible values are the following: - **LOG_LEVEL_OFF** - **LOG_LEVEL_ERROR** - **LOG_LEVEL_WARNING** - **LOG_LEVEL_INFO** - **LOG_LEVEL_DEBUG** The logging in MCUBoot can be disabled and thus the code size can be reduced by setting it to ``LOG_LEVEL_OFF``. Its value depends on the build type. If the build type is ``Debug`` and a value has been provided (e.g. through the command line or the CMake GUI) then that value will be used, otherwise it is ``LOG_LEVEL_INFO`` by default. In case of different kinds of ``Release`` builds its value is set to ``LOG_LEVEL_OFF`` (any other value will be overridden). --- I tried enabling MCUBOOT_LOG_LEVEL_DEBUG by adding -DMCUBOOT_LOG_LEVEL=LOG_LEVEL_DEBUG to the cmake command line, but that set the level to -1. I also tried -DMCUBOOT_LOG_LEVEL=4, which also set it to -1. I then noticed that the default setting in CMakeCache.txt is "MCUBOOT_LOG_LEVEL:STRING=INFO", so I instead used -DMCUBOOT_LOG_LEVEL=DEBUG, which worked. I would also like to be able to use logging for Release builds, as this may assist chasing down optimization issues. Thomas -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 7 months

1
0
0 0

TF-M v1.2.0 release

by Anton Komlev

Hello, TF-M project released version v1.2.0, tagged as TF-Mv1.2.0. This release has started using adopted semantic versioning as described in the release_process.rst<https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/docs/contr…> Please take a look into the release notes for the new features and changes. Thanks to everyone who directly and indirectly contributed to this milestone. Anton Komlev TF-M technical lead Arm Ltd.

5 years, 7 months

1
0
0 0

MCUBOOT_LOG_LEVEL description confusing/wrong

by Thomas Törnblom

The description of how to set MCUBOOT_LOG_LEVEL in tfm_secure_boot.rst appears wrong, or at least unclear. --- - MCUBOOT_LOG_LEVEL: Can be used to configure the level of logging in MCUBoot. The possible values are the following: - **LOG_LEVEL_OFF** - **LOG_LEVEL_ERROR** - **LOG_LEVEL_WARNING** - **LOG_LEVEL_INFO** - **LOG_LEVEL_DEBUG** The logging in MCUBoot can be disabled and thus the code size can be reduced by setting it to ``LOG_LEVEL_OFF``. Its value depends on the build type. If the build type is ``Debug`` and a value has been provided (e.g. through the command line or the CMake GUI) then that value will be used, otherwise it is ``LOG_LEVEL_INFO`` by default. In case of different kinds of ``Release`` builds its value is set to ``LOG_LEVEL_OFF`` (any other value will be overridden). --- I tried enabling MCUBOOT_LOG_LEVEL_DEBUG by adding -DMCUBOOT_LOG_LEVEL=LOG_LEVEL_DEBUG to the cmake command line, but that set the level to -1. I also tried -DMCUBOOT_LOG_LEVEL=4, which also set it to -1. I then noticed that the default setting in CMakeCache.txt is "MCUBOOT_LOG_LEVEL:STRING=INFO", so I instead used -DMCUBOOT_LOG_LEVEL=DEBUG, which worked. I would also like to be able to use logging for Release builds, as this may assist chasing down optimization issues. Thomas

5 years, 7 months

1
0
0 0

Re: [TF-M] Technical Forum call - November 26

by David Hu

Hi Anton, I'd like to share a proposal to improve dual-cpu mailbox. Best regards, Hu Ziji From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M Sent: Thursday, November 19, 2020 4:59 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] Technical Forum call - November 26 Hello, The next Technical Forum is planned on Thursday, November 26 at 15:00-16:00 GMT (US friendly time zone). Please reply on this email with your proposals for agenda topics. Recording and slides of previous meetings are here: https://www.trustedfirmware.org/meetings/tf-m-technical-forum/ Best regards, Anton

5 years, 7 months

1
0
0 0

Re: [TF-M] Code freeze heads up for TF-M v1.2

by Anton Komlev

Hi, New TF-M Release Candidate 3 is tagged by TF-Mv1.2-RC3 Please update all repositories as it contain all fixes for issues found in RC2. Best regards, Anton From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M Sent: 11 November 2020 15:34 To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Code freeze heads up for TF-M v1.2 Hi, New TF-M Release Candidate 2 is tagged by TF-Mv1.2-RC2. Please update all repositories as it contain fixes for issues found in RC1. Best regards, Anton From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Anton Komlev via TF-M Sent: 04 November 2020 16:35 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] Code freeze heads up for TF-M v1.2 Hi, All TF-M repositories are tagged with TF-Mv1.2-RC1 tag, marking the code freeze and beginning of the release candidate testing. 1. tf-m-tools 2. tf-m-tests 3. trusted-firmware-m 4. tf-m-ci-scripts 5. tf-m-job-configs Please use this tag for tests and report all issues found here. The best, Anton From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Anton Komlev via TF-M Sent: 02 November 2020 14:28 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] Code freeze heads up for TF-M v1.2 Hi All, This is a reminder and heads up that TF-Mv1.2 release is planned for the end of November and TF-M code repository is aimed for freeze on Nov 4th (Wed), tagged by TF-Mv1.2-RC1 for testing. Availability of the tag will be notified via this mailing list. Thanks, Anton

5 years, 7 months

1
0
0 0

Technical Forum call - November 26

by Anton Komlev

Hello, The next Technical Forum is planned on Thursday, November 26 at 15:00-16:00 GMT (US friendly time zone). Please reply on this email with your proposals for agenda topics. Recording and slides of previous meetings are here: https://www.trustedfirmware.org/meetings/tf-m-technical-forum/ Best regards, Anton

5 years, 7 months

1
0
0 0

Re: [TF-M] Semantic versioning

by Minos Galanakis

Hi, Following up the current discussions on semantic versioning, I have prepared a patch <https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/7075/1> . Feel free to review and comment. Expanded patch link: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/7075/1 Minos ________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Gyorgy Szing via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: 16 November 2020 17:32 To: tf-m(a)lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.org> Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Semantic versioning Hi, Well, yes. Not sure what backwards compatibility would mean in a complex application with a configurable set of services and service capabilities. Semantic versioning could work quite well for components (i.e. secure service implementations) though. /George From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M Sent: 16 November 2020 18:04 To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Semantic versioning Hi George, All, Thanks for the thoughts. Can I assume that you suggest to stay with option 1? The semantic versioning was proposed several times and sounds reasonable because it gives a meaning to each version component so downstream projects could rely on it. Yes, a version of a product represents some quality status but in my view that depends on convention. For downstream projects reference, TF-M issues releases periodically so a version represents a stable point in time and occasionally brings new features / fixes. Cheers, Anton 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: 16 November 2020 08:17 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] Semantic versioning Hi, I miss something here. What is being discussed, what is the purpose of changing version numbering? * Is more granularity needed and each or some lesser quality levels should be assigned a version number too? Currently a new version number is assigned if a new SW set reaches “Release” quality level. (Whatever that might be.) * Is there need for expressing backwards compatibility better? * Is the aim to enhance existing version numbers just by making them following a well-defined standard? I have the feeling different people are talking about different sub-topics. I think the most important purpose or having release numbers is to express quality. It could help on version numbers if quality would be defined cleaner. /George From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Kevin Peng via TF-M Sent: 16 November 2020 09:06 To: David Hu <David.Hu(a)arm.com<mailto:David.Hu@arm.com>>; David Wang <David.Wang(a)arm.com<mailto:David.Wang@arm.com>>; Anton Komlev <Anton.Komlev(a)arm.com<mailto:Anton.Komlev@arm.com>>; 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] Semantic versioning I would vote for Option 3, and “.2” - Backport the fixing patches to the existing v1.x.0 tag. – This provides the flexibility to have a released version with critical fixes only. If TF-M users want all the changes between the release and the fix they can take the master branch as well. Best Regards, Kevin From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of David Hu via TF-M Sent: Monday, November 16, 2020 3:45 PM To: David Wang <David.Wang(a)arm.com<mailto:David.Wang@arm.com>>; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>; Anton Komlev <Anton.Komlev(a)arm.com<mailto:Anton.Komlev@arm.com>> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: Re: [TF-M] Semantic versioning Hi Anton, Option 3 seems more reasonable to me. Hi David, I think we can leave tag v1.x.0 as it is and create a new tag v1.x.1 for this critical fix on master branch. It can be more easier to distinguish between tags. Best regards, Hu Ziji From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of David Wang via TF-M Sent: Monday, November 16, 2020 2:53 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] Semantic versioning Hi Anton, Option 3 is a good. Just to clarify, for example, if v1.x.0 released, and we got a critical fix 2 months later. Then in your proposal, we: * Tag the current master which includes the fixing patch (and may also include some other merged/ongoing features after last release) as v1.x.1, or * Backport the fixing patches to the existing v1.x.0 tag (keep it in a new branch) and tag the tip of the v1.x release branch as v1.x.1 Thanks. Regards, David Wang From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Kevin Townsend via TF-M Sent: Saturday, November 14, 2020 3:45 AM To: Anton Komlev <Anton.Komlev(a)arm.com<mailto:Anton.Komlev@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] Semantic versioning Hi Anton, Option 3 seems the most sensible to me for a project like TF-M at this stage. Best regards, Kevin On Fri, 13 Nov 2020 at 20:19, Anton Komlev via TF-M <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> wrote: Hi, I would like to continue the discussion on TF-M semantic versioning started on the last tech forum. Currently TF-M uses a loosely defined versioning schema with major and minor versions, following TF-A. There are several calls to switch TF-M to semantic versioning. Here is the reminder of the meaning: (https://semver.org/) v1.2.3 : 1. MAJOR version when you make incompatible API changes, 2. MINOR version when you add functionality in a backwards compatible manner, and 3. PATCH version when you make backwards compatible bug fixes. This is a good way to go for a mature project but TF-M will overkill from everyday re-versioning because of new patches. It was discussed on the forum and several options were proposed: 1. Do nothing, reasonably bumping up versions on release time only. 2. Use semantic versioning ignoring changes in PATCH by keeping it 0. So upcoming version could be: v1.2.0, next v1.3.0 and nothing in between. 3. Use option 2 but change PATCH when critical code change delivered within release cadence like a security vulnerability fix to let down-stream project relay on a fixed version. 4. Other ideas? Personally I tend to follow option 3 but looking for the community input. Thanks, Anton. -- TF-M mailing list TF-M(a)lists.trustedfirmware.org<mailto:TF-M@lists.trustedfirmware.org> https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 7 months

2
1
0 0

Blog for Amazon FreeRTOS Gateway Demo based on TF-M Profile Small

by David Wang

Hi, In Linaro Virtual Connect 20 (LVC20), Shebu and I presented a session "Scalable Security Using Trusted Firmware-M Profiles" (ref[1]). It basically shows an example of using FreeRTOS+TF-M Profile Small on armv8m devices to connect to AWS cloud through a Gateway. The key features demonstrated in the example: * Symmetric cipher based secure connection - TLS PSK * Usage of (symmetric) attestation * Device-Gateway-Cloud secure channel example A blog (https://www.trustedfirmware.org/blog/amazon-freertos-tfm-blog/) is shared in tf.org if you want to know more details of the design. Thanks. Ref: [1] Scalable Security Using Trusted Firmware-M Profiles - https://connect.linaro.org/resources/lvc20/lvc20-213/ Regards, David Wang ARM Electronic Technology (Shanghai) Co., Ltd Phone: +86-21-6154 9142 (ext. 59142)

5 years, 7 months

1
0
0 0

Re: [TF-M] Generated files location

by Ken Liu

Hi Andrej, Thanks for reporting this. It looks like the dependency on TFM_TEST_PATH matters. We need to define something for managing these generated files. /Ken -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M Sent: Friday, November 13, 2020 9:54 PM To: Raef Coles <Raef.Coles(a)arm.com>; Anton Komlev <Anton.Komlev(a)arm.com> Cc: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] Generated files location Hi, FYI: For Windows (not Liniux) users, the command have to be: ... set TFM_TEST_PATH=../tf-m-tests/test python tools/tfm_parse_manifest_list.py -m tools/tfm_manifest_list.yaml -f tools/tfm_generated_file_list.yaml -o <output> ... Also, all required Python modules have to be installed before (PyYAML, Jinja2) Best regards, Andrej Butok -----Original Message----- From: Raef Coles <Raef.Coles(a)arm.com> Sent: Thursday, November 12, 2020 2:11 PM To: Anton Komlev <Anton.Komlev(a)arm.com>; Andrej Butok <andrey.butok(a)nxp.com> Cc: tf-m(a)lists.trustedfirmware.org Subject: Re: Generated files location Hi, As an intermediate step, we've made a modification to the file generation code so that file can be generated without cmake being run. This generation can be run by: ``` python3 tools/tfm_parse_manifest_list.py -m tools/tfm_manifest_list.yaml -f tools/tfm_generated_file_list.yaml -o <output dir> ``` Which will output the files into the specified output directory. if the `-o` flag is not provided then the files will be generated into the TFM source tree. Note that this method still requires knowledge of the location of some dependencies, as this cannot be provided by cmake. When run in standalone mode, these paths are gathered from environment variables, and generation will fail if those variables are not set. Thus: ``` env TFM_TEST_PATH=$(realpath ../tf-m-tests/test) python3 tools/tfm_parse_manifest_list.py -m tools/tfm_manifest_list.yaml -f tools/tfm_generated_file_list.yaml ``` Raef ________________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Andrej Butok via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: 20 October 2020 08:39 To: Anton Komlev Cc: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] Generated files location Hi Anton If it's not possible to avoid a file generation now, it's good to have pre-generated files for a most typical configuration (l2, IPC etc.). As I mentioned before, ideally to use TFM as a real component/framework without generation of any source code. BUT If you believe, this requirement breaks a TFM concept, just tell us. Thanks, Andrej From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M Sent: Tuesday, October 20, 2020 9:27 AM To: tf-m(a)lists.trustedfirmware.org Cc: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] Generated files location Hi Andrej, Essentially, do you mean to move the files back to code tree and synch them with templates manually as it was ? Cheers, Anton From: Andrej Butok <andrey.butok(a)nxp.com<mailto:andrey.butok@nxp.com>> Sent: 19 October 2020 16:15 To: Anton Komlev <Anton.Komlev(a)arm.com<mailto:Anton.Komlev@arm.com>> Cc: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: RE: Generated files location Hi Anton, Another option: 3. Avoid the mandatory on-the-fly generation. Try to make TFM a component/framework, which is configurable by compile & run time parameters. Thanks, Andrej From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Anton Komlev via TF-M Sent: Monday, October 19, 2020 5:00 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] Generated files location Hi, Some source files in TF-M are templated and generated inside /<build_dir>/generated/ on the fly as a part of build process. This guaranty consistency between templates and generated but might make a trouble for IDE, where not all source files exist at the first run. I see 2 options for solution: 1. Explicitly generate those files via cmake as a part of IDE project creation (1 time action) 2. Relay on CMSIS Pack for IDE, where generated files must be presents Any alternative thoughts? Anton -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 7 months

1
0
0 0

Re: [TF-M] Semantic versioning

by Gyorgy Szing

Hi, Well, yes. Not sure what backwards compatibility would mean in a complex application with a configurable set of services and service capabilities. Semantic versioning could work quite well for components (i.e. secure service implementations) though. /George From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M Sent: 16 November 2020 18:04 To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Semantic versioning Hi George, All, Thanks for the thoughts. Can I assume that you suggest to stay with option 1? The semantic versioning was proposed several times and sounds reasonable because it gives a meaning to each version component so downstream projects could rely on it. Yes, a version of a product represents some quality status but in my view that depends on convention. For downstream projects reference, TF-M issues releases periodically so a version represents a stable point in time and occasionally brings new features / fixes. Cheers, Anton 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: 16 November 2020 08:17 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] Semantic versioning Hi, I miss something here. What is being discussed, what is the purpose of changing version numbering? * Is more granularity needed and each or some lesser quality levels should be assigned a version number too? Currently a new version number is assigned if a new SW set reaches “Release” quality level. (Whatever that might be.) * Is there need for expressing backwards compatibility better? * Is the aim to enhance existing version numbers just by making them following a well-defined standard? I have the feeling different people are talking about different sub-topics. I think the most important purpose or having release numbers is to express quality. It could help on version numbers if quality would be defined cleaner. /George From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Kevin Peng via TF-M Sent: 16 November 2020 09:06 To: David Hu <David.Hu(a)arm.com<mailto:David.Hu@arm.com>>; David Wang <David.Wang(a)arm.com<mailto:David.Wang@arm.com>>; Anton Komlev <Anton.Komlev(a)arm.com<mailto:Anton.Komlev@arm.com>>; 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] Semantic versioning I would vote for Option 3, and “.2” - Backport the fixing patches to the existing v1.x.0 tag. – This provides the flexibility to have a released version with critical fixes only. If TF-M users want all the changes between the release and the fix they can take the master branch as well. Best Regards, Kevin From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of David Hu via TF-M Sent: Monday, November 16, 2020 3:45 PM To: David Wang <David.Wang(a)arm.com<mailto:David.Wang@arm.com>>; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>; Anton Komlev <Anton.Komlev(a)arm.com<mailto:Anton.Komlev@arm.com>> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: Re: [TF-M] Semantic versioning Hi Anton, Option 3 seems more reasonable to me. Hi David, I think we can leave tag v1.x.0 as it is and create a new tag v1.x.1 for this critical fix on master branch. It can be more easier to distinguish between tags. Best regards, Hu Ziji From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of David Wang via TF-M Sent: Monday, November 16, 2020 2:53 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] Semantic versioning Hi Anton, Option 3 is a good. Just to clarify, for example, if v1.x.0 released, and we got a critical fix 2 months later. Then in your proposal, we: * Tag the current master which includes the fixing patch (and may also include some other merged/ongoing features after last release) as v1.x.1, or * Backport the fixing patches to the existing v1.x.0 tag (keep it in a new branch) and tag the tip of the v1.x release branch as v1.x.1 Thanks. Regards, David Wang From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Kevin Townsend via TF-M Sent: Saturday, November 14, 2020 3:45 AM To: Anton Komlev <Anton.Komlev(a)arm.com<mailto:Anton.Komlev@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] Semantic versioning Hi Anton, Option 3 seems the most sensible to me for a project like TF-M at this stage. Best regards, Kevin On Fri, 13 Nov 2020 at 20:19, Anton Komlev via TF-M <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> wrote: Hi, I would like to continue the discussion on TF-M semantic versioning started on the last tech forum. Currently TF-M uses a loosely defined versioning schema with major and minor versions, following TF-A. There are several calls to switch TF-M to semantic versioning. Here is the reminder of the meaning: (https://semver.org/) v1.2.3 : 1. MAJOR version when you make incompatible API changes, 2. MINOR version when you add functionality in a backwards compatible manner, and 3. PATCH version when you make backwards compatible bug fixes. This is a good way to go for a mature project but TF-M will overkill from everyday re-versioning because of new patches. It was discussed on the forum and several options were proposed: 1. Do nothing, reasonably bumping up versions on release time only. 2. Use semantic versioning ignoring changes in PATCH by keeping it 0. So upcoming version could be: v1.2.0, next v1.3.0 and nothing in between. 3. Use option 2 but change PATCH when critical code change delivered within release cadence like a security vulnerability fix to let down-stream project relay on a fixed version. 4. Other ideas? Personally I tend to follow option 3 but looking for the community input. Thanks, Anton. -- TF-M mailing list TF-M(a)lists.trustedfirmware.org<mailto:TF-M@lists.trustedfirmware.org> https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 7 months

1
0
0 0

Re: [TF-M] Semantic versioning

by Anton Komlev

Hi George, All, Thanks for the thoughts. Can I assume that you suggest to stay with option 1? The semantic versioning was proposed several times and sounds reasonable because it gives a meaning to each version component so downstream projects could rely on it. Yes, a version of a product represents some quality status but in my view that depends on convention. For downstream projects reference, TF-M issues releases periodically so a version represents a stable point in time and occasionally brings new features / fixes. Cheers, Anton From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Gyorgy Szing via TF-M Sent: 16 November 2020 08:17 To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Semantic versioning Hi, I miss something here. What is being discussed, what is the purpose of changing version numbering? * Is more granularity needed and each or some lesser quality levels should be assigned a version number too? Currently a new version number is assigned if a new SW set reaches “Release” quality level. (Whatever that might be.) * Is there need for expressing backwards compatibility better? * Is the aim to enhance existing version numbers just by making them following a well-defined standard? I have the feeling different people are talking about different sub-topics. I think the most important purpose or having release numbers is to express quality. It could help on version numbers if quality would be defined cleaner. /George From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Kevin Peng via TF-M Sent: 16 November 2020 09:06 To: David Hu <David.Hu(a)arm.com<mailto:David.Hu@arm.com>>; David Wang <David.Wang(a)arm.com<mailto:David.Wang@arm.com>>; Anton Komlev <Anton.Komlev(a)arm.com<mailto:Anton.Komlev@arm.com>>; 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] Semantic versioning I would vote for Option 3, and “.2” - Backport the fixing patches to the existing v1.x.0 tag. – This provides the flexibility to have a released version with critical fixes only. If TF-M users want all the changes between the release and the fix they can take the master branch as well. Best Regards, Kevin From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of David Hu via TF-M Sent: Monday, November 16, 2020 3:45 PM To: David Wang <David.Wang(a)arm.com<mailto:David.Wang@arm.com>>; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>; Anton Komlev <Anton.Komlev(a)arm.com<mailto:Anton.Komlev@arm.com>> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: Re: [TF-M] Semantic versioning Hi Anton, Option 3 seems more reasonable to me. Hi David, I think we can leave tag v1.x.0 as it is and create a new tag v1.x.1 for this critical fix on master branch. It can be more easier to distinguish between tags. Best regards, Hu Ziji From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of David Wang via TF-M Sent: Monday, November 16, 2020 2:53 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] Semantic versioning Hi Anton, Option 3 is a good. Just to clarify, for example, if v1.x.0 released, and we got a critical fix 2 months later. Then in your proposal, we: * Tag the current master which includes the fixing patch (and may also include some other merged/ongoing features after last release) as v1.x.1, or * Backport the fixing patches to the existing v1.x.0 tag (keep it in a new branch) and tag the tip of the v1.x release branch as v1.x.1 Thanks. Regards, David Wang From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Kevin Townsend via TF-M Sent: Saturday, November 14, 2020 3:45 AM To: Anton Komlev <Anton.Komlev(a)arm.com<mailto:Anton.Komlev@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] Semantic versioning Hi Anton, Option 3 seems the most sensible to me for a project like TF-M at this stage. Best regards, Kevin On Fri, 13 Nov 2020 at 20:19, Anton Komlev via TF-M <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> wrote: Hi, I would like to continue the discussion on TF-M semantic versioning started on the last tech forum. Currently TF-M uses a loosely defined versioning schema with major and minor versions, following TF-A. There are several calls to switch TF-M to semantic versioning. Here is the reminder of the meaning: (https://semver.org/) v1.2.3 : 1. MAJOR version when you make incompatible API changes, 2. MINOR version when you add functionality in a backwards compatible manner, and 3. PATCH version when you make backwards compatible bug fixes. This is a good way to go for a mature project but TF-M will overkill from everyday re-versioning because of new patches. It was discussed on the forum and several options were proposed: 1. Do nothing, reasonably bumping up versions on release time only. 2. Use semantic versioning ignoring changes in PATCH by keeping it 0. So upcoming version could be: v1.2.0, next v1.3.0 and nothing in between. 3. Use option 2 but change PATCH when critical code change delivered within release cadence like a security vulnerability fix to let down-stream project relay on a fixed version. 4. Other ideas? Personally I tend to follow option 3 but looking for the community input. Thanks, Anton. -- TF-M mailing list TF-M(a)lists.trustedfirmware.org<mailto:TF-M@lists.trustedfirmware.org> https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 7 months

1
0
0 0

Re: [TF-M] Combine secure and non-secure image

by Kevin Townsend

Hi Antonio, I'm not sure if this helps, but here is an example of how we sign the binaries for the MPS2 AN521, for example, after building the TF-M and Zephyr NS images, plus MCUBoot: https://github.com/zephyrproject-rtos/zephyr/blob/966015f503d1438c25d597937… Best regards, Kevin On Fri, 13 Nov 2020 at 16:19, Antonio Ken IANNILLO via TF-M < tf-m(a)lists.trustedfirmware.org> wrote: > Hi all, > > I abandoned the idea to build at once tf-m and zephyr and switched to > separated compilations. > > Now, I have both secure and non-secure binaries but I’m not sure how to > concatenate and sign them. > > I found the assemble.py script but I don’t know whether it is the correct > one or where to find the signing_layout. > > > > To be more specific, for my current target musca-a (going to switch to > musca-s as soon as it arrives): > > - I built TF-M > - I imported and included in my zephyr application both libpsa_api_ns.a > and libtfm_s_veneers.a > - I build my zephyr application > > Now (I suppose) I have to > > - merge zephyr.bin with tfm_s.bin > - sign the merged binary > - concatenate with bl2 > > I could not find any reference how to correctly do these last steps. > > > > Best, > > -- > > *Antonio Ken Iannillo* > > Research Scientist – SEDAN group > > SnT – Interdisciplinary Centre for Security, Reliability and Trust > > UNIVERSITÉ DU LUXEMBOURG > > > > CAMPUS KIRCHBERG > 29, avenue John F. Kennedy > L-1855 Luxembourg Kirchberg > T +352 46 66 44 9660 > > > > Join the conversation > > News <https://wwwen.uni.lu/snt/news_events> | Twitter > <https://twitter.com/SnT_uni_lu> | Linkedin > <https://www.linkedin.com/school/snt-lu/> > > www.uni.lu/snt > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m >

5 years, 7 months

3
2
0 0

Re: [TF-M] Semantic versioning

by Gyorgy Szing

Hi, I miss something here. What is being discussed, what is the purpose of changing version numbering? * Is more granularity needed and each or some lesser quality levels should be assigned a version number too? Currently a new version number is assigned if a new SW set reaches “Release” quality level. (Whatever that might be.) * Is there need for expressing backwards compatibility better? * Is the aim to enhance existing version numbers just by making them following a well-defined standard? I have the feeling different people are talking about different sub-topics. I think the most important purpose or having release numbers is to express quality. It could help on version numbers if quality would be defined cleaner. /George From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Kevin Peng via TF-M Sent: 16 November 2020 09:06 To: David Hu <David.Hu(a)arm.com>; David Wang <David.Wang(a)arm.com>; Anton Komlev <Anton.Komlev(a)arm.com>; tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Semantic versioning I would vote for Option 3, and “.2” - Backport the fixing patches to the existing v1.x.0 tag. – This provides the flexibility to have a released version with critical fixes only. If TF-M users want all the changes between the release and the fix they can take the master branch as well. Best Regards, Kevin From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of David Hu via TF-M Sent: Monday, November 16, 2020 3:45 PM To: David Wang <David.Wang(a)arm.com<mailto:David.Wang@arm.com>>; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>; Anton Komlev <Anton.Komlev(a)arm.com<mailto:Anton.Komlev@arm.com>> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: Re: [TF-M] Semantic versioning Hi Anton, Option 3 seems more reasonable to me. Hi David, I think we can leave tag v1.x.0 as it is and create a new tag v1.x.1 for this critical fix on master branch. It can be more easier to distinguish between tags. Best regards, Hu Ziji From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of David Wang via TF-M Sent: Monday, November 16, 2020 2:53 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] Semantic versioning Hi Anton, Option 3 is a good. Just to clarify, for example, if v1.x.0 released, and we got a critical fix 2 months later. Then in your proposal, we: * Tag the current master which includes the fixing patch (and may also include some other merged/ongoing features after last release) as v1.x.1, or * Backport the fixing patches to the existing v1.x.0 tag (keep it in a new branch) and tag the tip of the v1.x release branch as v1.x.1 Thanks. Regards, David Wang From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Kevin Townsend via TF-M Sent: Saturday, November 14, 2020 3:45 AM To: Anton Komlev <Anton.Komlev(a)arm.com<mailto:Anton.Komlev@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] Semantic versioning Hi Anton, Option 3 seems the most sensible to me for a project like TF-M at this stage. Best regards, Kevin On Fri, 13 Nov 2020 at 20:19, Anton Komlev via TF-M <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> wrote: Hi, I would like to continue the discussion on TF-M semantic versioning started on the last tech forum. Currently TF-M uses a loosely defined versioning schema with major and minor versions, following TF-A. There are several calls to switch TF-M to semantic versioning. Here is the reminder of the meaning: (https://semver.org/) v1.2.3 : 1. MAJOR version when you make incompatible API changes, 2. MINOR version when you add functionality in a backwards compatible manner, and 3. PATCH version when you make backwards compatible bug fixes. This is a good way to go for a mature project but TF-M will overkill from everyday re-versioning because of new patches. It was discussed on the forum and several options were proposed: 1. Do nothing, reasonably bumping up versions on release time only. 2. Use semantic versioning ignoring changes in PATCH by keeping it 0. So upcoming version could be: v1.2.0, next v1.3.0 and nothing in between. 3. Use option 2 but change PATCH when critical code change delivered within release cadence like a security vulnerability fix to let down-stream project relay on a fixed version. 4. Other ideas? Personally I tend to follow option 3 but looking for the community input. Thanks, Anton. -- TF-M mailing list TF-M(a)lists.trustedfirmware.org<mailto:TF-M@lists.trustedfirmware.org> https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 7 months

1
0
0 0

Re: [TF-M] Semantic versioning

by Kevin Peng

I would vote for Option 3, and “.2” - Backport the fixing patches to the existing v1.x.0 tag. – This provides the flexibility to have a released version with critical fixes only. If TF-M users want all the changes between the release and the fix they can take the master branch as well. Best Regards, Kevin From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Hu via TF-M Sent: Monday, November 16, 2020 3:45 PM To: David Wang <David.Wang(a)arm.com>; tf-m(a)lists.trustedfirmware.org; Anton Komlev <Anton.Komlev(a)arm.com> Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Semantic versioning Hi Anton, Option 3 seems more reasonable to me. Hi David, I think we can leave tag v1.x.0 as it is and create a new tag v1.x.1 for this critical fix on master branch. It can be more easier to distinguish between tags. Best regards, Hu Ziji From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of David Wang via TF-M Sent: Monday, November 16, 2020 2:53 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] Semantic versioning Hi Anton, Option 3 is a good. Just to clarify, for example, if v1.x.0 released, and we got a critical fix 2 months later. Then in your proposal, we: * Tag the current master which includes the fixing patch (and may also include some other merged/ongoing features after last release) as v1.x.1, or * Backport the fixing patches to the existing v1.x.0 tag (keep it in a new branch) and tag the tip of the v1.x release branch as v1.x.1 Thanks. Regards, David Wang From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Kevin Townsend via TF-M Sent: Saturday, November 14, 2020 3:45 AM To: Anton Komlev <Anton.Komlev(a)arm.com<mailto:Anton.Komlev@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] Semantic versioning Hi Anton, Option 3 seems the most sensible to me for a project like TF-M at this stage. Best regards, Kevin On Fri, 13 Nov 2020 at 20:19, Anton Komlev via TF-M <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> wrote: Hi, I would like to continue the discussion on TF-M semantic versioning started on the last tech forum. Currently TF-M uses a loosely defined versioning schema with major and minor versions, following TF-A. There are several calls to switch TF-M to semantic versioning. Here is the reminder of the meaning: (https://semver.org/) v1.2.3 : 1. MAJOR version when you make incompatible API changes, 2. MINOR version when you add functionality in a backwards compatible manner, and 3. PATCH version when you make backwards compatible bug fixes. This is a good way to go for a mature project but TF-M will overkill from everyday re-versioning because of new patches. It was discussed on the forum and several options were proposed: 1. Do nothing, reasonably bumping up versions on release time only. 2. Use semantic versioning ignoring changes in PATCH by keeping it 0. So upcoming version could be: v1.2.0, next v1.3.0 and nothing in between. 3. Use option 2 but change PATCH when critical code change delivered within release cadence like a security vulnerability fix to let down-stream project relay on a fixed version. 4. Other ideas? Personally I tend to follow option 3 but looking for the community input. Thanks, Anton. -- TF-M mailing list TF-M(a)lists.trustedfirmware.org<mailto:TF-M@lists.trustedfirmware.org> https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 7 months

1
0
0 0

Re: [TF-M] Semantic versioning

by David Hu

Hi Anton, Option 3 seems more reasonable to me. Hi David, I think we can leave tag v1.x.0 as it is and create a new tag v1.x.1 for this critical fix on master branch. It can be more easier to distinguish between tags. Best regards, Hu Ziji From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Wang via TF-M Sent: Monday, November 16, 2020 2:53 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Semantic versioning Hi Anton, Option 3 is a good. Just to clarify, for example, if v1.x.0 released, and we got a critical fix 2 months later. Then in your proposal, we: * Tag the current master which includes the fixing patch (and may also include some other merged/ongoing features after last release) as v1.x.1, or * Backport the fixing patches to the existing v1.x.0 tag (keep it in a new branch) and tag the tip of the v1.x release branch as v1.x.1 Thanks. Regards, David Wang From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Kevin Townsend via TF-M Sent: Saturday, November 14, 2020 3:45 AM To: Anton Komlev <Anton.Komlev(a)arm.com<mailto:Anton.Komlev@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] Semantic versioning Hi Anton, Option 3 seems the most sensible to me for a project like TF-M at this stage. Best regards, Kevin On Fri, 13 Nov 2020 at 20:19, Anton Komlev via TF-M <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> wrote: Hi, I would like to continue the discussion on TF-M semantic versioning started on the last tech forum. Currently TF-M uses a loosely defined versioning schema with major and minor versions, following TF-A. There are several calls to switch TF-M to semantic versioning. Here is the reminder of the meaning: (https://semver.org/) v1.2.3 : 1. MAJOR version when you make incompatible API changes, 2. MINOR version when you add functionality in a backwards compatible manner, and 3. PATCH version when you make backwards compatible bug fixes. This is a good way to go for a mature project but TF-M will overkill from everyday re-versioning because of new patches. It was discussed on the forum and several options were proposed: 1. Do nothing, reasonably bumping up versions on release time only. 2. Use semantic versioning ignoring changes in PATCH by keeping it 0. So upcoming version could be: v1.2.0, next v1.3.0 and nothing in between. 3. Use option 2 but change PATCH when critical code change delivered within release cadence like a security vulnerability fix to let down-stream project relay on a fixed version. 4. Other ideas? Personally I tend to follow option 3 but looking for the community input. Thanks, Anton. -- TF-M mailing list TF-M(a)lists.trustedfirmware.org<mailto:TF-M@lists.trustedfirmware.org> https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 7 months

1
0
0 0

Re: [TF-M] Semantic versioning

by David Wang

Hi Anton, Option 3 is a good. Just to clarify, for example, if v1.x.0 released, and we got a critical fix 2 months later. Then in your proposal, we: * Tag the current master which includes the fixing patch (and may also include some other merged/ongoing features after last release) as v1.x.1, or * Backport the fixing patches to the existing v1.x.0 tag (keep it in a new branch) and tag the tip of the v1.x release branch as v1.x.1 Thanks. Regards, David Wang From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Kevin Townsend via TF-M Sent: Saturday, November 14, 2020 3:45 AM To: Anton Komlev <Anton.Komlev(a)arm.com> Cc: nd <nd(a)arm.com>; tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] Semantic versioning Hi Anton, Option 3 seems the most sensible to me for a project like TF-M at this stage. Best regards, Kevin On Fri, 13 Nov 2020 at 20:19, Anton Komlev via TF-M <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> wrote: Hi, I would like to continue the discussion on TF-M semantic versioning started on the last tech forum. Currently TF-M uses a loosely defined versioning schema with major and minor versions, following TF-A. There are several calls to switch TF-M to semantic versioning. Here is the reminder of the meaning: (https://semver.org/) v1.2.3 : 1. MAJOR version when you make incompatible API changes, 2. MINOR version when you add functionality in a backwards compatible manner, and 3. PATCH version when you make backwards compatible bug fixes. This is a good way to go for a mature project but TF-M will overkill from everyday re-versioning because of new patches. It was discussed on the forum and several options were proposed: 1. Do nothing, reasonably bumping up versions on release time only. 2. Use semantic versioning ignoring changes in PATCH by keeping it 0. So upcoming version could be: v1.2.0, next v1.3.0 and nothing in between. 3. Use option 2 but change PATCH when critical code change delivered within release cadence like a security vulnerability fix to let down-stream project relay on a fixed version. 4. Other ideas? Personally I tend to follow option 3 but looking for the community input. Thanks, Anton. -- TF-M mailing list TF-M(a)lists.trustedfirmware.org<mailto:TF-M@lists.trustedfirmware.org> https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 7 months

1
0
0 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

TF-M