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
