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
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
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
>
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
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
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
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
Option 3 +1.
/Ken
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
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> 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
> https://lists.trustedfirmware.org/mailman/listinfo/tf-m
>
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.
Hi Antonio,
This might be helpful in addition to Tamas:
https://ci.trustedfirmware.org/view/TF-M/job/tf-m-build-docs-nightly/lastSt…
The best,
Anton
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Tamas Ban via TF-M
Sent: 13 November 2020 15:36
To: tf-m(a)lists.trustedfirmware.org
Cc: nd <nd(a)arm.com>
Subject: Re: [TF-M] Combine secure and non-secure image
Hi Antonio,
Required steps on Musca-A (only single image boot is supported by MCUboot due to RAM_LOAD upgrade mode limitation):
- Concatenate zephyr.bin + tfm_s.bin.
[ 93%] Generating tfm_s_ns.bin
cd /home/tamban01/repo/tf-m/build/bl2/ext/mcuboot && ../../../../py_env/bin/python3 /home/tamban01/repo/tf-m/bl2/ext/mcuboot/scripts/assemble.py --layout /home/tamban01/repo/tf-m/build/bl2/ext/mcuboot/CMakeFiles/signing_layout_s.dir/signing_layout_s_ns.o -s /home/tamban01/repo/tf-m/build/bin/tfm_s.bin -n /home/tamban01/repo/tf-m/build/bin/tfm_ns.bin -o tfm_s_ns.bin
* Signing the concatenated binary:
[ 94%] Generating tfm_s_ns_signed.bin
cd /home/tamban01/repo/tf-m/build/bl2/ext/mcuboot && ../../../../py_env/bin/python3 /home/tamban01/repo/tf-m/bl2/ext/mcuboot/scripts/wrapper/wrapper.py -v 1.1.0 --layout /home/tamban01/repo/tf-m/build/bl2/ext/mcuboot/CMakeFiles/signing_layout_s.dir/signing_layout_s_ns.o -k /home/tamban01/repo/tf-m/bl2/ext/mcuboot/root-RSA-3072.pem --public-key-format full --align 1 --pad --pad-header -H 0x400 -s auto -d "(0, 0.0.0+0)" -d "(1, 0.0.0+0)" tfm_s_ns.bin /home/tamban01/repo/tf-m/build/bl2/ext/mcuboot/tfm_s_ns_signed.bin
* Combine bl2.bin and tfm_s_ns.bin:
srec_cat build/bin/bl2.bin -Binary -offset 0x200000 build/bin/tfm_s_ns_signed.bin -Binary -offset 0x220000 -o tfm.hex -Intel
Tamas
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: 2020. november 13., péntek 16:33
To: Antonio Ken IANNILLO <antonioken.iannillo(a)uni.lu<mailto:antonioken.iannillo@uni.lu>>
Cc: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>
Subject: Re: [TF-M] Combine secure and non-secure image
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<mailto:tf-m@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<http://www.uni.lu/snt>
--
TF-M mailing list
TF-M(a)lists.trustedfirmware.org<mailto:TF-M@lists.trustedfirmware.org>
https://lists.trustedfirmware.org/mailman/listinfo/tf-m
Hi Antonio,
Required steps on Musca-A (only single image boot is supported by MCUboot due to RAM_LOAD upgrade mode limitation):
- Concatenate zephyr.bin + tfm_s.bin.
[ 93%] Generating tfm_s_ns.bin
cd /home/tamban01/repo/tf-m/build/bl2/ext/mcuboot && ../../../../py_env/bin/python3 /home/tamban01/repo/tf-m/bl2/ext/mcuboot/scripts/assemble.py --layout /home/tamban01/repo/tf-m/build/bl2/ext/mcuboot/CMakeFiles/signing_layout_s.dir/signing_layout_s_ns.o -s /home/tamban01/repo/tf-m/build/bin/tfm_s.bin -n /home/tamban01/repo/tf-m/build/bin/tfm_ns.bin -o tfm_s_ns.bin
* Signing the concatenated binary:
[ 94%] Generating tfm_s_ns_signed.bin
cd /home/tamban01/repo/tf-m/build/bl2/ext/mcuboot && ../../../../py_env/bin/python3 /home/tamban01/repo/tf-m/bl2/ext/mcuboot/scripts/wrapper/wrapper.py -v 1.1.0 --layout /home/tamban01/repo/tf-m/build/bl2/ext/mcuboot/CMakeFiles/signing_layout_s.dir/signing_layout_s_ns.o -k /home/tamban01/repo/tf-m/bl2/ext/mcuboot/root-RSA-3072.pem --public-key-format full --align 1 --pad --pad-header -H 0x400 -s auto -d "(0, 0.0.0+0)" -d "(1, 0.0.0+0)" tfm_s_ns.bin /home/tamban01/repo/tf-m/build/bl2/ext/mcuboot/tfm_s_ns_signed.bin
* Combine bl2.bin and tfm_s_ns.bin:
srec_cat build/bin/bl2.bin -Binary -offset 0x200000 build/bin/tfm_s_ns_signed.bin -Binary -offset 0x220000 -o tfm.hex -Intel
Tamas
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Kevin Townsend via TF-M
Sent: 2020. november 13., péntek 16:33
To: Antonio Ken IANNILLO <antonioken.iannillo(a)uni.lu>
Cc: tf-m(a)lists.trustedfirmware.org
Subject: Re: [TF-M] Combine secure and non-secure image
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<mailto:tf-m@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<http://www.uni.lu/snt>
--
TF-M mailing list
TF-M(a)lists.trustedfirmware.org<mailto:TF-M@lists.trustedfirmware.org>
https://lists.trustedfirmware.org/mailman/listinfo/tf-m
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 | Twitter | Linkedin
www.uni.lu/snt
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
Hi Robert,
Thanks for the bug report. I have pushed a fix for review: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/6986
Kind regards,
Jamie
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Robert Rostohar via TF-M
Sent: 12 November 2020 13:57
To: tf-m(a)lists.trustedfirmware.org
Subject: [TF-M] Typo in return value (ps_object_system.c)
Hi,
I believe there is a small typo in the return value of function ps_read_object (ps_object_system.c). This results in build failure of Non-encrypted Protected Storage.
https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/secure_fw/…
The define used should be "PSA_ERROR_DATA_CORRUPT" and not "PSA_PS_ERROR_DATA_CORRUPT".
Best regards,
Robert
Hi,
I believe there is a small typo in the return value of function ps_read_object (ps_object_system.c). This results in build failure of Non-encrypted Protected Storage.
https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/secure_fw/…
The define used should be "PSA_ERROR_DATA_CORRUPT" and not "PSA_PS_ERROR_DATA_CORRUPT".
Best regards,
Robert
Hi Anton,
I have a topic, Partition Storage Arrangement, to introduce partition data storage briefly, for about 20 minutes.
Thanks,
Mingyang
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M
Sent: Wednesday, November 4, 2020 10:17 PM
To: tf-m(a)lists.trustedfirmware.org
Cc: nd <nd(a)arm.com>
Subject: [TF-M] Technical Forum call - November 12
Hello,
The next Technical Forum is planned on Thursday, November 12 at 6:00-07:00 UTC (Asia 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
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> On Behalf Of Anton Komlev via TF-M
Sent: 04 November 2020 16:35
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,
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
Hi,
With the upcoming release of TF-M 1.2, we are considering deprecating the GNU Arm compiler v6.3.1 to be able to reallocate testing bandwidth to newer and more up to date versions ( 7+ )
Before doing so I would like to ask for the community's feedback. Is anyone using this compiler, and if so, would you be affected by the change? Are there any other reasons we should consider keeping it in to the test plan?
Regards,
Minos
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> On Behalf Of Anton Komlev via TF-M
Sent: 02 November 2020 14:28
To: tf-m(a)lists.trustedfirmware.org
Cc: nd <nd(a)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
Hello,
The next Technical Forum is planned on Thursday, November 12 at 6:00-07:00 UTC (Asia 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
Just adding some hints from the TF-M point of view.
The TF-M test cases are RTOS independent.
And test entry functions are provided for integrating the tests to any RTOS - test_app()
You just need to call them in your application thread.
Of course, you need to implement the os_wrapper APIs as well.
You can refer to the os_wrapper_cmsis_rtos_v2.c for details.
The old build system of TF-M used to provide libraries of the tests.
The new build system is not having those yet. So the source codes need to be built.
The test case libraries should be added back to the new build system and then integrating tf-m tests to RTOS should be much more direct.
Best Regards,
Kevin
-----Original Message-----
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Raef Coles via TF-M
Sent: Tuesday, November 3, 2020 11:19 PM
To: Antonio Ken IANNILLO <antonioken.iannillo(a)uni.lu>; Kevin Townsend (kevin.townsend(a)linaro.org) <kevin.townsend(a)linaro.org>
Cc: tf-m(a)lists.trustedfirmware.org
Subject: Re: [TF-M] Integrating a different RTOS in tf-m-test
Good spot Antonio, those docs are out of date. I'll try to get them updated before the code freeze.
Raef
________________________________________
From: Antonio Ken IANNILLO
Sent: Tuesday, November 03, 2020 14:35
To: Raef Coles; Kevin Townsend (kevin.townsend(a)linaro.org)
Cc: tf-m(a)lists.trustedfirmware.org
Subject: Re: [TF-M] Integrating a different RTOS in tf-m-test
Hi Raef,
I agree with you, also reading the documentation https://ci.trustedfirmware.org/view/TF-M/job/tf-m-build-docs-nightly/lastSt… (even if it seems obsolete since some files are missing). For example, are now the static library for the test included in the one you mentioned?
I'm using the module offered by zephyr to build and import the tfm, but I get a lot of missing references.
Further, I searched in the install directory built by tfm and I cannot really find all of them.
--
Antonio Ken Iannillo
On 03/11/2020, 15:08, "Raef Coles" <Raef.Coles(a)arm.com> wrote:
One of the things tfm produces is the NS api static library, which should be found in `interface/libpsa_api_ns.a`. There is also a ns platforms static lib in the same directory. I'm not sure how easy it is to pick these up from the zephyr buildsystem, but those should contain the symbols you want.
Raef
________________________________________
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Antonio Ken IANNILLO via TF-M <tf-m(a)lists.trustedfirmware.org>
Sent: 03 November 2020 11:45
To: Kevin Townsend (kevin.townsend(a)linaro.org)
Cc: tf-m(a)lists.trustedfirmware.org
Subject: Re: [TF-M] Integrating a different RTOS in tf-m-test
Hi Kevin,
Thank you for your message.
I’m trying to create a zephyr application copying the tfm-test non secure application (https://github.com/zephyrproject-rtos/trusted-firmware-m/blob/master/tf-m-t…).
The only thing that is not clear is how to include the tfm platform code (e.g., https://github.com/zephyrproject-rtos/trusted-firmware-m/blob/master/truste…).
I suppose as a static library from the zephyr tfm module but I cannot really find how.
Can you point me to the right direction?
Or do you have a different way to run the tfm-tests?
Best,
--
Antonio Ken Iannillo
From: Kevin Townsend <kevin.townsend(a)linaro.org>
Date: Monday, 2 November 2020 at 13:08
To: Antonio Ken IANNILLO <antonioken.iannillo(a)uni.lu>
Cc: "tf-m(a)lists.trustedfirmware.org" <tf-m(a)lists.trustedfirmware.org>
Subject: Re: [TF-M] Integrating a different RTOS in tf-m-test
Hi Antonio,
There is currently an issue filed in Zephyr to add a new sample application that will make it easy to run the PSA API tests via Zephyr, but it we're currently working on finalizing higher priority changes before the 1.2 code freeze later this week: https://github.com/zephyrproject-rtos/zephyr/issues/29476
So, there isn't an 'easy' way to build these tests in Zephyr today out of the box using Zephyr as the RTOS on the NS side, unless you want to have a go at it yourself in the short term while we try to make sure Zephyr is ready for the changes in T-M 1.2.
Best regards,
Kevin
On Mon, 2 Nov 2020 at 10:29, Antonio Ken IANNILLO via TF-M <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> wrote:
Hi all,
I wanted to use some other RTOS in the NS side while testing tf-m.
Is there a simple way to use the Zephyr kernel or FreeRTOS in the tf-m-test (-DTEST_S=ON, -DTEST_NS=ON) instead of the default RTX?
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<http://www.uni.lu/snt>
--
TF-M mailing list
TF-M(a)lists.trustedfirmware.org<mailto:TF-M@lists.trustedfirmware.org>
https://lists.trustedfirmware.org/mailman/listinfo/tf-m
--
TF-M mailing list
TF-M(a)lists.trustedfirmware.org
https://lists.trustedfirmware.org/mailman/listinfo/tf-m
Good spot Antonio, those docs are out of date. I'll try to get them updated before the code freeze.
Raef
________________________________________
From: Antonio Ken IANNILLO
Sent: Tuesday, November 03, 2020 14:35
To: Raef Coles; Kevin Townsend (kevin.townsend(a)linaro.org)
Cc: tf-m(a)lists.trustedfirmware.org
Subject: Re: [TF-M] Integrating a different RTOS in tf-m-test
Hi Raef,
I agree with you, also reading the documentation https://ci.trustedfirmware.org/view/TF-M/job/tf-m-build-docs-nightly/lastSt… (even if it seems obsolete since some files are missing). For example, are now the static library for the test included in the one you mentioned?
I'm using the module offered by zephyr to build and import the tfm, but I get a lot of missing references.
Further, I searched in the install directory built by tfm and I cannot really find all of them.
--
Antonio Ken Iannillo
On 03/11/2020, 15:08, "Raef Coles" <Raef.Coles(a)arm.com> wrote:
One of the things tfm produces is the NS api static library, which should be found in `interface/libpsa_api_ns.a`. There is also a ns platforms static lib in the same directory. I'm not sure how easy it is to pick these up from the zephyr buildsystem, but those should contain the symbols you want.
Raef
________________________________________
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Antonio Ken IANNILLO via TF-M <tf-m(a)lists.trustedfirmware.org>
Sent: 03 November 2020 11:45
To: Kevin Townsend (kevin.townsend(a)linaro.org)
Cc: tf-m(a)lists.trustedfirmware.org
Subject: Re: [TF-M] Integrating a different RTOS in tf-m-test
Hi Kevin,
Thank you for your message.
I’m trying to create a zephyr application copying the tfm-test non secure application (https://github.com/zephyrproject-rtos/trusted-firmware-m/blob/master/tf-m-t…).
The only thing that is not clear is how to include the tfm platform code (e.g., https://github.com/zephyrproject-rtos/trusted-firmware-m/blob/master/truste…).
I suppose as a static library from the zephyr tfm module but I cannot really find how.
Can you point me to the right direction?
Or do you have a different way to run the tfm-tests?
Best,
--
Antonio Ken Iannillo
From: Kevin Townsend <kevin.townsend(a)linaro.org>
Date: Monday, 2 November 2020 at 13:08
To: Antonio Ken IANNILLO <antonioken.iannillo(a)uni.lu>
Cc: "tf-m(a)lists.trustedfirmware.org" <tf-m(a)lists.trustedfirmware.org>
Subject: Re: [TF-M] Integrating a different RTOS in tf-m-test
Hi Antonio,
There is currently an issue filed in Zephyr to add a new sample application that will make it easy to run the PSA API tests via Zephyr, but it we're currently working on finalizing higher priority changes before the 1.2 code freeze later this week: https://github.com/zephyrproject-rtos/zephyr/issues/29476
So, there isn't an 'easy' way to build these tests in Zephyr today out of the box using Zephyr as the RTOS on the NS side, unless you want to have a go at it yourself in the short term while we try to make sure Zephyr is ready for the changes in T-M 1.2.
Best regards,
Kevin
On Mon, 2 Nov 2020 at 10:29, Antonio Ken IANNILLO via TF-M <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> wrote:
Hi all,
I wanted to use some other RTOS in the NS side while testing tf-m.
Is there a simple way to use the Zephyr kernel or FreeRTOS in the tf-m-test (-DTEST_S=ON, -DTEST_NS=ON) instead of the default RTX?
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<http://www.uni.lu/snt>
--
TF-M mailing list
TF-M(a)lists.trustedfirmware.org<mailto:TF-M@lists.trustedfirmware.org>
https://lists.trustedfirmware.org/mailman/listinfo/tf-m
One of the things tfm produces is the NS api static library, which should be found in `interface/libpsa_api_ns.a`. There is also a ns platforms static lib in the same directory. I'm not sure how easy it is to pick these up from the zephyr buildsystem, but those should contain the symbols you want.
Raef
________________________________________
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Antonio Ken IANNILLO via TF-M <tf-m(a)lists.trustedfirmware.org>
Sent: 03 November 2020 11:45
To: Kevin Townsend (kevin.townsend(a)linaro.org)
Cc: tf-m(a)lists.trustedfirmware.org
Subject: Re: [TF-M] Integrating a different RTOS in tf-m-test
Hi Kevin,
Thank you for your message.
I’m trying to create a zephyr application copying the tfm-test non secure application (https://github.com/zephyrproject-rtos/trusted-firmware-m/blob/master/tf-m-t…).
The only thing that is not clear is how to include the tfm platform code (e.g., https://github.com/zephyrproject-rtos/trusted-firmware-m/blob/master/truste…).
I suppose as a static library from the zephyr tfm module but I cannot really find how.
Can you point me to the right direction?
Or do you have a different way to run the tfm-tests?
Best,
--
Antonio Ken Iannillo
From: Kevin Townsend <kevin.townsend(a)linaro.org>
Date: Monday, 2 November 2020 at 13:08
To: Antonio Ken IANNILLO <antonioken.iannillo(a)uni.lu>
Cc: "tf-m(a)lists.trustedfirmware.org" <tf-m(a)lists.trustedfirmware.org>
Subject: Re: [TF-M] Integrating a different RTOS in tf-m-test
Hi Antonio,
There is currently an issue filed in Zephyr to add a new sample application that will make it easy to run the PSA API tests via Zephyr, but it we're currently working on finalizing higher priority changes before the 1.2 code freeze later this week: https://github.com/zephyrproject-rtos/zephyr/issues/29476
So, there isn't an 'easy' way to build these tests in Zephyr today out of the box using Zephyr as the RTOS on the NS side, unless you want to have a go at it yourself in the short term while we try to make sure Zephyr is ready for the changes in T-M 1.2.
Best regards,
Kevin
On Mon, 2 Nov 2020 at 10:29, Antonio Ken IANNILLO via TF-M <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> wrote:
Hi all,
I wanted to use some other RTOS in the NS side while testing tf-m.
Is there a simple way to use the Zephyr kernel or FreeRTOS in the tf-m-test (-DTEST_S=ON, -DTEST_NS=ON) instead of the default RTX?
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<http://www.uni.lu/snt>
--
TF-M mailing list
TF-M(a)lists.trustedfirmware.org<mailto:TF-M@lists.trustedfirmware.org>
https://lists.trustedfirmware.org/mailman/listinfo/tf-m
Sorry Thomas - Someday I'll get that IAR license working and stop breaking support every 5 seconds. Thanks for all the hard work and fixes.
Patches look good, have reviewed.
Raef
________________________________________
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Thomas Törnblom via TF-M <tf-m(a)lists.trustedfirmware.org>
Sent: 03 November 2020 12:22
To: DeMars, Alan via TF-M
Subject: [TF-M] Current IAR support
Just when you think you have nailed everfything down, you decide to start with a fresh clone and stuff don't build anymore ;)
See: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/6766
I have now gone over and tried building everything that has IAR support and here are my findings.
I have used the following patches:
https://review.trustedfirmware.org/c/TF-M/tf-m-tests/+/5978https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/6766
I have built for the following targets:
musca_a
mps2/an519
mps2/an521
mps2/an539
mps2/sse-200_aws
mps3/an524
cypress/psoc64
nxp/lpcxpresso55s69 (-DBL2=False as bl2 support appears to have been added recently to this target)
stm/nucleo_l552ze_q
stm/stm32l562e_dk
The mps2/fvp_sse300 requires a compiler with support for the M55, and the IAR compiler with support for this is not yet released.
I have run tests on the following targets:
musca_a
mps2/an519
mps2/an521
mps2/an539
The cypress/psoc64 board I have appears to be obsolete now and I could not flash the secure image to it.
The nuvoton/m2351 appears to have IAR support, but it appears untested as it gives linking errors for the bl2 and NS startup files.
There are some old and new warnings for type issues and some other minor things.
The QCBOR NaN tests are still failing, see:
https://developer.trustedfirmware.org/T700
This really is an issue where the ARM ABI and IEEE 754 are incompatible and we are following the ARM ABI. In reality neither ARMCLANG nor GNUARM are fully ARM ABI compliant as they are not ignoring the relevant bits.
Thomas
--
Thomas Törnblom, Product Engineer
IAR Systems AB
Box 23051, Strandbodgatan 1
SE-750 23 Uppsala, SWEDEN
Mobile: +46 76 180 17 80 Fax: +46 18 16 78 01
E-mail: thomas.tornblom(a)iar.com<mailto:thomas.tornblom@iar.com> Website: www.iar.com<http://www.iar.com>
Twitter: www.twitter.com/iarsystems<http://www.twitter.com/iarsystems>
