Hi Thomas
Thanks for the update, I go through your new patches initially and give some first review comments.
Besides, I am trying to have a build by IAR myself, and do a more detail review later.
Please be aware, the concept for review now is to make sure the new compiler can work on specified platform and won't block the current TFM process.
Since the new year holiday coming soon in China, my response may slow before 1st Feb. Sorry about that.
Thanks
Karl
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Thomas T?rnblom via TF-M
Sent: Tuesday, January 14, 2020 16:38
To: tf-m(a)lists.trustedfirmware.org
Subject: [TF-M] T398: Update to IAR support
I have just pushed the latest commits for the source cleanup and IAR integration.
https://review.trustedfirmware.org/c/trusted-firmware-m/+/3127/1
Please review.
Thanks,
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>
PSA-FF does not require isolation of code. Section 3.1 describes the isolation architecture (pages 21-25) and has three mandatory rules:
1. Only "code" is executable
2. Only "private data" is writable
3. "private data" is protected from untrusted "protection domains". (E.g. secure side "private data" cannot be accessed by non-secure)
[quoted items are defined terms in that section of the document]
Protecting "code" and "constant data" from other "protection domains" is provided in optional isolation rules 4, 5 and 6 with increasing levels of isolation (and system cost). The security rationale for isolating code is (a) confidentiality of the code and associated read-only data and (b) reduction of the number of ROP/JOP gadgets available to an attacker.
The level of isolation and implementation of the optional rules is intended to be a framework and/or product decision in order to match the product security requirements.
Regards,
Andrew
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu via TF-M
Sent: 09 January 2020 09:01
To: tf-m(a)lists.trustedfirmware.org
Cc: nd <nd(a)arm.com>
Subject: Re: [TF-M] Code Protection between secure services
Hi,
I assume the main purpose of isolation would be protect the code been seen by the AppRoT. Let's check with the FF author for detailed answers.
The building instructions now is just create separate libraries and finally combine them together - since vendors can create Secure Partitions, these modularized building can't be avoided.
/Ken
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Reinhard Keil via TF-M
Sent: Thursday, January 9, 2020 4:00 PM
To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>
Subject: [TF-M] Code Protection between secure services
I suggest we review the requirement of code isolation on the secure side.
R/W data and R/O data should definitely be isolated, but code isolation has implications:
* Code cannot be share between services (i.e. no linker optimization to reduce memory footprint)
* Sharing library code
* Overall the build instructions of the system are more complicated
* Adding device specific driver code (i.e. to crypto) can become tricky
Reinhard
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
Hello,
Just noted (thanks to David) that January 23 is a day ahead of Lunar New Year so we may expect less interest to the forum from Asia.
This is an opportunity to make the forum time US friendly on the next session.
Preliminary suggest to have it Thursday, January 23rd at 17:00-18:00 UTC. Which a morning time in US.
Again, please send your topics in respond to this mail. Experts and developers could be invited to answer specific questions asked in advance.
Best regards,
Anton Komlev
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M
Sent: 09 January 2020 11:22
To: TF-M(a)lists.trustedfirmware.org
Cc: nd <nd(a)arm.com>
Subject: [TF-M] TF-M Technical Forum call - January 23
Dear All,
The next session of the Technical Forum is planned in 2 weeks, Thursday, January 23rd at 7:00-8:00 UTC.
Please treat this email and an early invitation for agenda topic collection. Any questions, proposals, concerns are all valid points for our open discussion so do not hesitate to share it.
A big or complicated topics are worth to preliminary discussed over a mailing list.
Best regards,
Anton Komlev
Thanks Minos for comment.
I agree that there is still a small window as you describe in the 2nd case. Maybe this only can be solved by a super maintain who can merged patches to the master branch.
I am not sure if Gerrit can be enhanced to do this: it can trigger CI to do the test when it detects one merged patch are not on the TOP when two dev branches are merged at the same time. So that, we still can catch the problem soon even patches are merged to the master branch.
I also agree your most of the assumptions except this:
"There is no mitigation for scenarios of having individually tested patches merged in a small window, introducing a bug when combined, or having a patch-chain merged, and some of the intermediate patches breaking master but the final patch passing tests."
It is why we are discussing if we need to import the development or integration branch to TF-M to help to solve these problems partly. I agree the newly added branch cannot confirm the master branch is stable 100%. But it is significant if it can help improve stability.
There are many things we can and maybe we need to do to help to increase the quality of merged patches and help the users to use the master branch more convenient, such as policy, CI, code review, self-test, etc. The new branch is just only one part.
Thanks,
Edison
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Minos Galanakis via TF-M
Sent: Friday, January 10, 2020 6:18 PM
To: Edison Ai via TF-M <tf-m(a)lists.trustedfirmware.org>
Cc: nd <nd(a)arm.com>
Subject: Re: [TF-M] Create another branch for feature development
Hi.
I am a bit confused on how would the following be addressed by a having a dedicated development branch. Would it be possible to elaborate please?
There is another way maybe help to solve this problem, we can define a merge policy like this: The patches cannot be merged to master branch if the patch is not based on the TOP HEAD.
1. If you have dev branches A and B, with common ancestry the HEAD_M , they both have been tested, and are merged with 2 minutes difference, then branch B will be based on A and will not have tested in that way, but will be present in master and assumed stable.
2. If you have dev branches A and B , and we decide as policy that B needs to constantly be based on A ( i.e the newest patch should be based on the last patch under review ). There will always be a still a small window that you can make a change in A, merge it, and B is not updated. Not to account for the significant overhead this will have to development.
3. If we adopt a generic dev branch and merge it to master overnight then this problem does not exist to begin with but the overall development flow will be delayed.
The TF-M Merge strategy has the following components:
* Master as the common development branch.
* Release Tags for stable releases, based on master
* Feature branches for development of big changes without affecting the flow of master
To my understanding the following assumptions apply:
* RC tags are always stable and extensively tested.
* Feature branches usually are based on RC tags, and re-based on top of master right before merging them.
* Master should be stable, but is not guaranteed to to.
* There is no mitigation for scenarios of having individually tested patches merged in a small window, introducing a bug when combined, or having a patch-chain merged, and some of the intermediate patches breaking master but the final patch passing tests.
* It is impossible to test everything all the time, while keeping the merge bandwidth at maximum. The CI will have to test a significant amount of platforms, but relies on the developer on having a look on weather his change may affect anything outside of this scope. Since with the current process flow, there is no roll-back strategy, or a merge windows, there is a significant time gain in the time that each patch is held back when in review. Then the assumption is that if it breaks something which has not been tested, the developer will have to commit some extra time to address it. If that trade-off is unacceptable it can easily be addressed with a policy change.
In community projects the most commonly accepted solution that seems to mitigate a scenario of patches A, B being merged in a small time delta, is using "merge windows". But before we adopt any new policy we should be evaluating our needs.
To that end would it be possible to go back to start and decide on the requirements? What are we trying to achieve? What are we trying to address? What would the acceptable cost in development time be?
Regards,
Minos
________________________________
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> on behalf of Edison Ai via TF-M <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>>
Sent: 10 January 2020 07:40
To: 'tf-m(a)lists.trustedfirmware.org' <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] Create another branch for feature development
Hi,
Let's continue to discuss this topic.
I agree with this, the CI is just a tool, we should not only rely on it.
Thanks Gyorgy to point out the quality policy, we need to think about them when we discuss the version control.
In the current status, there is only one master branch for most of the development work in TF-M. Of course, we can add a warning to say that the master is constantly changing, there may be some problems in building or test running, and let the user use the release tag. But it is not convenience and impossible if they are upstreaming patches. And even to TF-M developers, we had met several times of the master branch is broken.
There is another way maybe help to solve this problem, we can define a merge policy like this: The patches cannot be merged to master branch if the patch is not based on the TOP HEAD. But this is very difficult to follow because there may be several maintainers could and need to merged patches at the same time. They need to align with each other to confirm their patches are on the TOP. But now, we often meet this case, while one patch rebases to TOP and waiting for the CI result, another patch is merged into master. The patch needs to rebase again.
I do not want to give more examples here.
Of course, it is a big change to involve a new branch, there must be many documents that need to be updated, and some policies need to be changed. And even this needs someone to maintain the alignment with 2 branches. But I think it is more useful and helpful for all users.
Thanks,
Edison
-----Original Message-----
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: Friday, December 13, 2019 10:01 PM
To: Minos Galanakis <Minos.Galanakis(a)arm.com<mailto:Minos.Galanakis@arm.com>>; Soby Mathew <Soby.Mathew(a)arm.com<mailto:Soby.Mathew@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] Create another branch for feature development
Hi,
Hi,
I agree, the CI shall not dictate how we use the version control system. It shall adapt.
Regarding your suggestions, I think the main problem is we are mixing stuff, this time quality with version control. Before we make decisions we shall understand where we are.
The current quality policy is that we only make releases for communication purposes. To give a clean interface for tf-m users and to allow planning their work. Releases allow them to execute their tf-m integration process less frequently. Only for each release or specific releases and not for each commit. The current quality policy identifies a single quality level only, and says any patch we publish is "golden quality", it matches the highest quality standard we can achieve (with sane constraints). Also to make our life easy we decided to use the master branch to hold these patches.
At the same time we use the master branch for development. Any change we make is made against master. This means each pull request and thus each review targets master. For review purposes the best is to have a chain of small modifications, otherwise the review content becomes too large to follow.
The TF-A "branching strategy" tries to address this issue by introducing an integration branch used for development. This allows master to be more release specific.
I suggest to take the following approach (details to be discussed):
- introduce more quality levels i.e.:
- none: content of a topic branch, or content pushed to review.
- bronze: content passed code review and patch specific testing.
- silver: content passed a more though daily testing.
- gold: a release. A pack of source-code, feature state document (release notes), reviewed documentation (user manual, reference manual), test evidence, documentation of test efforts to allow repeatability. The version control system can be used to store content, and to provide identification info (i.e. tagging), but most likely the release will need other kind of storage to be used (i.e. documentation).
- platina: reaching extra quality level trough passing PSA or some FUSA qualification. Or we may simply use extra release for this.
Naming the quality levels allows us to have a cleaner definition of what can be expected at a specific level (set of quality measures, i.e. static analysis, code review, test configuration). It would also allow us cleaner communication and to find how we use the version system for quality purposes.
I also expect this discussion to help defining how the version system is used for development purposes.
The current state works ok, but is a sort of naturally grown. We might have reached the point when more pragmatic approach may be needed.
/George
-----Original Message-----
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Minos Galanakis via TF-M
Sent: 13 December 2019 12:23
To: Edison Ai (Arm Technology China) via TF-M <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>>; Soby Mathew <Soby.Mathew(a)arm.com<mailto:Soby.Mathew@arm.com>>
Cc: nd <nd(a)arm.com<mailto:nd@arm.com>>
Subject: Re: [TF-M] Create another branch for feature development
Hi all.
My personal comments on this.
I would like to point out that the CI is a tool, not the core project. I do not believe we should be changing our development strategy based on what the tool is doing. We should instead adjust the tool to fit our requirements.
* No patches should be/ are merged to master when CI fails. If master breaks it should most commonly be because of something we are not testing for. Using an integration branch would not change that.
* As a developer I find it more convoluted to work with projects who use different integration strategies. The most common assumption in open source projects is that you have a master branch which is the bleeding edge, but can contain untested bugs, and the release immutable git tags for versioning. Using branch merges as versioning is a design for the pull request model which is not quite compatible with Gerrit.
* Most of the CI downtime has nothing to do with the merge strategy, they are more of a chicken and the egg philosophical problem. If your patch or branch introduced a change which affects the tests outputs, how will you test it if the CI expects the old output? An integration branch would not solve the merge freeze periods, would just affect a different branch from master.
* I believe feature branches are quite useful, since changes to master do not disrupt the development flow of a big change, and even though they will require some maintenance to re-sync before the final patch , it will be handled by an engineer who knows the feature, and full understands the regression vectors.
If I were to suggest some changes for stability purposes, I would start smaller:
* Update documentation to instruct users to check out from release tags, warning then that master is constantly changing.
* Adjust the CI to detect an Allow-CI flag from every branch. That way developers can test any patch from any feature branch. The logic for that is already present in the code, but requires Gerrit to be configured accordingly.
* Add an undo process. This would be the only case for an integration branch. All patches are merged to a temporary branch, after confirming they have passed testing individually. On the once per day nightly test, the group of different patches, will be tested against an extensive job, in models and hardware, and only if successful it will fast forward master to that state.
Regards
Minos
________________________________
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> on behalf of Edison Ai (Arm Technology China) via TF-M <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>>
Sent: 13 December 2019 08:55
To: Soby Mathew <Soby.Mathew(a)arm.com<mailto:Soby.Mathew@arm.com>>; 'tf-m(a)lists.trustedfirmware.org' <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] Create another branch for feature development
Hi Soby,
Thanks for your detail description.
> Integration is a temporary merge branch to merge several patches and run the CI against. Usually once CI passes, the master will be fast forwarded to integration within a day.
> This helps us to test integration of patches and detect any failure before master is updated. This means the master will pass CI at any given merge point.
I think it's a good method like this so that we can double confirm the "master" branch is stable.
And this also can fix one case even the CI can work normally: one patch is ready to merge, and it is not based on the latest HEAD, but there is no conflict. We can merge the patch directly and let gerrit do rebase by itself. But we cannot confirm the CI test can pass.
Any comment for this from others?
For multiple feature branches, I think we can stop to discuss about it now until we have some strong demands for it. It is indeed a big change for us now.
Thanks,
Edison
-----Original Message-----
From: Soby Mathew <Soby.Mathew(a)arm.com<mailto:Soby.Mathew@arm.com>>
Sent: Friday, December 13, 2019 5:14 AM
To: Edison Ai (Arm Technology China) <Edison.Ai(a)arm.com<mailto:Edison.Ai@arm.com>>; 'tf-m(a)lists.trustedfirmware.org' <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] Create another branch for feature development
On 11/12/2019 09:05, Edison Ai (Arm Technology China) via TF-M wrote:
> Hi Gyorgy,
>
> Thanks to point it out. I agree with you that it will be better if we can align these two projects in this. I had a quick check the branches from TF-A: https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/.
> There are three branches in TF-A:
> - "integration" branch, should be used for new features.
> - "master" branch, which is behind of "integration" branch. But I am nor sure what is the strategy to update it.
Hi Edison,
Integration is a temporary merge branch to merge several patches and run the CI against. Usually once CI passes, the master will be fast forwarded to integration within a day.
This helps us to test integration of patches and detect any failure before master is updated. This means the master will pass CI at any given merge point.
> - "topics/epic_beta0_spmd", I thinks it should like a feature branch for big feature.
> @Soby Mathew Could you help to share more information about it? Thanks very much.
We usually do not have feature branches in TF-A. The topics/epic_beta0_spmd is a prototyping branch where we wanted to share code with collaborators outside TF-A. The patches on this branch are not visible in gerrit review and no patches in gerrit review will be merged to this branch. Once the prototyping is complete, then patches on this branch will be reworked and pushed to gerrit review and finally get merged to integration and this branch will be deleted.
Our experience have been, long running development branches are generally a maintenance overhead. Merging these development branches before a release may also be risky as some of the changes may have unknown interactions and may become difficult to resolve.
The "topic" in gerrit review is effectively a branch. For example, this
review:
https://review.trustedfirmware.org/#/q/topic:od/debugfs+(status:open+OR+sta…
is a set of patches on topic "od/debugfs" and can be treated as development branch. This branch is alive as long as patches are not merged.
We need to understand the motivations for the change. Broken CI is an argument but development branches will only exacerbate that problem since we don't know the stability of each of those branches. Also merge conflict will not reduce due to development branches. Its just delaying the merge conflict to a later point.
There may be other reasons, but generally it is better to merge sensible patches (+2ed) within a feature even before the feature is complete as it will reduce merge conflicts (we have to ensure testing/build coverage for the patch). These are my thoughts on this.
Best Regards
Soby Mathew
--
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<mailto:TF-M@lists.trustedfirmware.org>
https://lists.trustedfirmware.org/mailman/listinfo/tf-m
--
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<mailto:TF-M@lists.trustedfirmware.org>
https://lists.trustedfirmware.org/mailman/listinfo/tf-m
The meeting video recording and slides are now posted at
https://www.trustedfirmware.org/meetings/tf-m-technical-forum/
Regards
Bill
On Wed, 8 Jan 2020 at 11:00, Anton Komlev via TF-M <
tf-m(a)lists.trustedfirmware.org> wrote:
> Hi All,
>
>
>
> Thanks, Ken and Edison for offering the topics for tomorrow’s Tech forum.
>
> The agenda (always open) starts from:
>
> 1. Secure Partition Runtime Library
> 2. PSA FF 1.0.0 alignment
>
>
>
> Best regards,
>
> Anton
>
>
>
> *From:* TF-M <tf-m-bounces(a)lists.trustedfirmware.org> * On Behalf Of *Edison
> Ai via TF-M
> *Sent:* 07 January 2020 08:19
> *To:* 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org>
> *Cc:* nd <nd(a)arm.com>
> *Subject:* Re: [TF-M] TF-M Technical Forum call - January 9
>
>
>
> Hi Anton,
>
>
>
> I will share something about the PSA FF 1.0.0 alignment. About 10 – 15
> minutes.
>
>
>
> Thanks,
>
> Edison
>
>
>
> *From:* TF-M <tf-m-bounces(a)lists.trustedfirmware.org> *On Behalf Of *Ken
> Liu via TF-M
> *Sent:* Tuesday, January 7, 2020 3:33 PM
> *To:* tf-m(a)lists.trustedfirmware.org
> *Cc:* nd <nd(a)arm.com>
> *Subject:* Re: [TF-M] TF-M Technical Forum call - January 9
>
>
>
> Hi Anton,
>
> I can share the status of Secure Partition Runtime Library in the tech
> forum.
>
>
>
> /Ken
>
>
>
> *From:* TF-M <tf-m-bounces(a)lists.trustedfirmware.org> *On Behalf Of *Anton
> Komlev via TF-M
> *Sent:* Tuesday, January 7, 2020 1:56 AM
> *To:* TF-M(a)lists.trustedfirmware.org
> *Cc:* nd <nd(a)arm.com>
> *Subject:* [TF-M] TF-M Technical Forum call - January 9
>
>
>
> Hello,
>
>
>
> Hope that the new year is truly happy for everybody.
>
> The next session of the Technical Forum is planned on the coming *Thursday,
> January 9th*.
>
> Regarding the time, I think that the last session was a good compromise to
> suit majority of the participants so propose to keep the time slot *at
> 7:00-8:00 UTC*.
>
> This time suits members in Europe and Asia, although participants from US
> (specially from the East coast) might have inconveniences.
>
> Reminding that the recorded sessions and materials are available on the
> web site: https://www.trustedfirmware.org/meetings/tf-m-technical-forum/
>
>
>
> Please reply to this email to post your topics for the agenda. Any
> questions, proposals, concerns are all valid points for our open discussion
> so do not hesitate to share it.
>
>
>
> Best regards,
>
> Anton Komlev
>
>
> --
> TF-M mailing list
> TF-M(a)lists.trustedfirmware.org
> https://lists.trustedfirmware.org/mailman/listinfo/tf-m
>
--
[image: Linaro] <http://www.linaro.org/>
*Bill Fletcher* | *Field Engineering*
T: +44 7833 498336 <+44+7833+498336>
bill.fletcher(a)linaro.org | Skype: billfletcher2020
Hi.
I am a bit confused on how would the following be addressed by a having a dedicated development branch. Would it be possible to elaborate please?
There is another way maybe help to solve this problem, we can define a merge policy like this: The patches cannot be merged to master branch if the patch is not based on the TOP HEAD.
1. If you have dev branches A and B, with common ancestry the HEAD_M , they both have been tested, and are merged with 2 minutes difference, then branch B will be based on A and will not have tested in that way, but will be present in master and assumed stable.
2. If you have dev branches A and B , and we decide as policy that B needs to constantly be based on A ( i.e the newest patch should be based on the last patch under review ). There will always be a still a small window that you can make a change in A, merge it, and B is not updated. Not to account for the significant overhead this will have to development.
3. If we adopt a generic dev branch and merge it to master overnight then this problem does not exist to begin with but the overall development flow will be delayed.
The TF-M Merge strategy has the following components:
* Master as the common development branch.
* Release Tags for stable releases, based on master
* Feature branches for development of big changes without affecting the flow of master
To my understanding the following assumptions apply:
* RC tags are always stable and extensively tested.
* Feature branches usually are based on RC tags, and re-based on top of master right before merging them.
* Master should be stable, but is not guaranteed to to.
* There is no mitigation for scenarios of having individually tested patches merged in a small window, introducing a bug when combined, or having a patch-chain merged, and some of the intermediate patches breaking master but the final patch passing tests.
* It is impossible to test everything all the time, while keeping the merge bandwidth at maximum. The CI will have to test a significant amount of platforms, but relies on the developer on having a look on weather his change may affect anything outside of this scope. Since with the current process flow, there is no roll-back strategy, or a merge windows, there is a significant time gain in the time that each patch is held back when in review. Then the assumption is that if it breaks something which has not been tested, the developer will have to commit some extra time to address it. If that trade-off is unacceptable it can easily be addressed with a policy change.
In community projects the most commonly accepted solution that seems to mitigate a scenario of patches A, B being merged in a small time delta, is using "merge windows". But before we adopt any new policy we should be evaluating our needs.
To that end would it be possible to go back to start and decide on the requirements? What are we trying to achieve? What are we trying to address? What would the acceptable cost in development time be?
Regards,
Minos
________________________________
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Edison Ai via TF-M <tf-m(a)lists.trustedfirmware.org>
Sent: 10 January 2020 07:40
To: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org>
Cc: nd <nd(a)arm.com>
Subject: Re: [TF-M] Create another branch for feature development
Hi,
Let's continue to discuss this topic.
I agree with this, the CI is just a tool, we should not only rely on it.
Thanks Gyorgy to point out the quality policy, we need to think about them when we discuss the version control.
In the current status, there is only one master branch for most of the development work in TF-M. Of course, we can add a warning to say that the master is constantly changing, there may be some problems in building or test running, and let the user use the release tag. But it is not convenience and impossible if they are upstreaming patches. And even to TF-M developers, we had met several times of the master branch is broken.
There is another way maybe help to solve this problem, we can define a merge policy like this: The patches cannot be merged to master branch if the patch is not based on the TOP HEAD. But this is very difficult to follow because there may be several maintainers could and need to merged patches at the same time. They need to align with each other to confirm their patches are on the TOP. But now, we often meet this case, while one patch rebases to TOP and waiting for the CI result, another patch is merged into master. The patch needs to rebase again.
I do not want to give more examples here.
Of course, it is a big change to involve a new branch, there must be many documents that need to be updated, and some policies need to be changed. And even this needs someone to maintain the alignment with 2 branches. But I think it is more useful and helpful for all users.
Thanks,
Edison
-----Original Message-----
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Gyorgy Szing via TF-M
Sent: Friday, December 13, 2019 10:01 PM
To: Minos Galanakis <Minos.Galanakis(a)arm.com>; Soby Mathew <Soby.Mathew(a)arm.com>; tf-m(a)lists.trustedfirmware.org
Cc: nd <nd(a)arm.com>
Subject: Re: [TF-M] Create another branch for feature development
Hi,
Hi,
I agree, the CI shall not dictate how we use the version control system. It shall adapt.
Regarding your suggestions, I think the main problem is we are mixing stuff, this time quality with version control. Before we make decisions we shall understand where we are.
The current quality policy is that we only make releases for communication purposes. To give a clean interface for tf-m users and to allow planning their work. Releases allow them to execute their tf-m integration process less frequently. Only for each release or specific releases and not for each commit. The current quality policy identifies a single quality level only, and says any patch we publish is "golden quality", it matches the highest quality standard we can achieve (with sane constraints). Also to make our life easy we decided to use the master branch to hold these patches.
At the same time we use the master branch for development. Any change we make is made against master. This means each pull request and thus each review targets master. For review purposes the best is to have a chain of small modifications, otherwise the review content becomes too large to follow.
The TF-A "branching strategy" tries to address this issue by introducing an integration branch used for development. This allows master to be more release specific.
I suggest to take the following approach (details to be discussed):
- introduce more quality levels i.e.:
- none: content of a topic branch, or content pushed to review.
- bronze: content passed code review and patch specific testing.
- silver: content passed a more though daily testing.
- gold: a release. A pack of source-code, feature state document (release notes), reviewed documentation (user manual, reference manual), test evidence, documentation of test efforts to allow repeatability. The version control system can be used to store content, and to provide identification info (i.e. tagging), but most likely the release will need other kind of storage to be used (i.e. documentation).
- platina: reaching extra quality level trough passing PSA or some FUSA qualification. Or we may simply use extra release for this.
Naming the quality levels allows us to have a cleaner definition of what can be expected at a specific level (set of quality measures, i.e. static analysis, code review, test configuration). It would also allow us cleaner communication and to find how we use the version system for quality purposes.
I also expect this discussion to help defining how the version system is used for development purposes.
The current state works ok, but is a sort of naturally grown. We might have reached the point when more pragmatic approach may be needed.
/George
-----Original Message-----
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Minos Galanakis via TF-M
Sent: 13 December 2019 12:23
To: Edison Ai (Arm Technology China) via TF-M <tf-m(a)lists.trustedfirmware.org>; Soby Mathew <Soby.Mathew(a)arm.com>
Cc: nd <nd(a)arm.com>
Subject: Re: [TF-M] Create another branch for feature development
Hi all.
My personal comments on this.
I would like to point out that the CI is a tool, not the core project. I do not believe we should be changing our development strategy based on what the tool is doing. We should instead adjust the tool to fit our requirements.
* No patches should be/ are merged to master when CI fails. If master breaks it should most commonly be because of something we are not testing for. Using an integration branch would not change that.
* As a developer I find it more convoluted to work with projects who use different integration strategies. The most common assumption in open source projects is that you have a master branch which is the bleeding edge, but can contain untested bugs, and the release immutable git tags for versioning. Using branch merges as versioning is a design for the pull request model which is not quite compatible with Gerrit.
* Most of the CI downtime has nothing to do with the merge strategy, they are more of a chicken and the egg philosophical problem. If your patch or branch introduced a change which affects the tests outputs, how will you test it if the CI expects the old output? An integration branch would not solve the merge freeze periods, would just affect a different branch from master.
* I believe feature branches are quite useful, since changes to master do not disrupt the development flow of a big change, and even though they will require some maintenance to re-sync before the final patch , it will be handled by an engineer who knows the feature, and full understands the regression vectors.
If I were to suggest some changes for stability purposes, I would start smaller:
* Update documentation to instruct users to check out from release tags, warning then that master is constantly changing.
* Adjust the CI to detect an Allow-CI flag from every branch. That way developers can test any patch from any feature branch. The logic for that is already present in the code, but requires Gerrit to be configured accordingly.
* Add an undo process. This would be the only case for an integration branch. All patches are merged to a temporary branch, after confirming they have passed testing individually. On the once per day nightly test, the group of different patches, will be tested against an extensive job, in models and hardware, and only if successful it will fast forward master to that state.
Regards
Minos
________________________________
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Edison Ai (Arm Technology China) via TF-M <tf-m(a)lists.trustedfirmware.org>
Sent: 13 December 2019 08:55
To: Soby Mathew <Soby.Mathew(a)arm.com>; 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org>
Cc: nd <nd(a)arm.com>
Subject: Re: [TF-M] Create another branch for feature development
Hi Soby,
Thanks for your detail description.
> Integration is a temporary merge branch to merge several patches and run the CI against. Usually once CI passes, the master will be fast forwarded to integration within a day.
> This helps us to test integration of patches and detect any failure before master is updated. This means the master will pass CI at any given merge point.
I think it's a good method like this so that we can double confirm the "master" branch is stable.
And this also can fix one case even the CI can work normally: one patch is ready to merge, and it is not based on the latest HEAD, but there is no conflict. We can merge the patch directly and let gerrit do rebase by itself. But we cannot confirm the CI test can pass.
Any comment for this from others?
For multiple feature branches, I think we can stop to discuss about it now until we have some strong demands for it. It is indeed a big change for us now.
Thanks,
Edison
-----Original Message-----
From: Soby Mathew <Soby.Mathew(a)arm.com>
Sent: Friday, December 13, 2019 5:14 AM
To: Edison Ai (Arm Technology China) <Edison.Ai(a)arm.com>; 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org>
Cc: nd <nd(a)arm.com>
Subject: Re: [TF-M] Create another branch for feature development
On 11/12/2019 09:05, Edison Ai (Arm Technology China) via TF-M wrote:
> Hi Gyorgy,
>
> Thanks to point it out. I agree with you that it will be better if we can align these two projects in this. I had a quick check the branches from TF-A: https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/.
> There are three branches in TF-A:
> - "integration" branch, should be used for new features.
> - "master" branch, which is behind of "integration" branch. But I am nor sure what is the strategy to update it.
Hi Edison,
Integration is a temporary merge branch to merge several patches and run the CI against. Usually once CI passes, the master will be fast forwarded to integration within a day.
This helps us to test integration of patches and detect any failure before master is updated. This means the master will pass CI at any given merge point.
> - "topics/epic_beta0_spmd", I thinks it should like a feature branch for big feature.
> @Soby Mathew Could you help to share more information about it? Thanks very much.
We usually do not have feature branches in TF-A. The topics/epic_beta0_spmd is a prototyping branch where we wanted to share code with collaborators outside TF-A. The patches on this branch are not visible in gerrit review and no patches in gerrit review will be merged to this branch. Once the prototyping is complete, then patches on this branch will be reworked and pushed to gerrit review and finally get merged to integration and this branch will be deleted.
Our experience have been, long running development branches are generally a maintenance overhead. Merging these development branches before a release may also be risky as some of the changes may have unknown interactions and may become difficult to resolve.
The "topic" in gerrit review is effectively a branch. For example, this
review:
https://review.trustedfirmware.org/#/q/topic:od/debugfs+(status:open+OR+sta…
is a set of patches on topic "od/debugfs" and can be treated as development branch. This branch is alive as long as patches are not merged.
We need to understand the motivations for the change. Broken CI is an argument but development branches will only exacerbate that problem since we don't know the stability of each of those branches. Also merge conflict will not reduce due to development branches. Its just delaying the merge conflict to a later point.
There may be other reasons, but generally it is better to merge sensible patches (+2ed) within a feature even before the feature is complete as it will reduce merge conflicts (we have to ensure testing/build coverage for the patch). These are my thoughts on this.
Best Regards
Soby Mathew
--
TF-M mailing list
TF-M(a)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
--
TF-M mailing list
TF-M(a)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
I propose to implement PSA_Panic () as a macro (like the classic C assert feature) and not as a plain C function.
The benefit is that the macro allows you to insert also information like __FILE__ and __LINE__ which helps during the development phase of projects (i.e. when TF-M is incorrectly used by the non-secure side. __FILE__ and __LINE__ is useful also when no source code is available (at the debug stage) as it allows support to provide hints for the root cause of the issue.
You may have different variants of the PSA_Panic macro, i.e. a debug and release version.
Reinhard
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
Ken,
Today there are multiple different implementation of event logging used in the industry, but in a nutshell all use a similar concept.
You may start reading http://www.keil.com/pack/doc/compiler/EventRecorder/html/er_overview.html which is the implementation used currently in MDK. It uses a buffer that is read by the debugger. The buffer size is configurable and a faster debugger requires typically smaller buffer sizes. Also it introduces an XML file that describes the messages - and this description is used also by other tools like Percepio.
You may remap the annotation hooks also to classic printf.
So overall the concept gives you more flexibility and introducing it at a later stage into a project usually creates legacy effects.
For example we had in MDK middleware initially printf type annotations and introduced later events. As users are reluctant to change technology during the project lifecycle we end up to maintain both the old printf and the new event recorder annotations. This could have been avoided by using the right (flexible) concept from the beginning.
Reinhard
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
