Hi Abhishek, all
I just answered to Julius's email concerning inclusive language
No additional topics from my side
I will be most likely not able to join this TSC meeting.
Regards,
Eric Finco
[Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: logo_big5]
Eric FINCO | Tel: +33 (0)2 4402 7154
MDG | Technical Specialist
From: TSC <tsc-bounces(a)lists.trustedfirmware.org> On Behalf Of Abhishek Pandit via TSC
Sent: mardi 13 octobre 2020 15:32
To: tsc(a)lists.trustedfirmware.org
Subject: [TF-TSC] TSC Agenda 15 Oct 2020
Hi All,
Any agenda items for this week's meeting?
We have two existing topics which need to be decided by vote. Please do not reply to this email with your vote, there will be a separate email to the voting members.
1. Inclusive language guideline.
This is based on the discussion in the previous TSC meeting and the follow up proposal from Julius.
2. Trusted services project creation.
Arm team has been developing reference trusted services running in Secure EL0 that we plan to upstream in TF.org. This would form a new project to provide trusted services running on A profile devices.
The topic has already been discussed in board and Arm engineering team will provide further details in the TSC meeting.
Thanks
Abhishek
Hi All,
Any agenda items for this week's meeting?
We have two existing topics which need to be decided by vote. Please do not reply to this email with your vote, there will be a separate email to the voting members.
1. Inclusive language guideline.
This is based on the discussion in the previous TSC meeting and the follow up proposal from Julius.
2. Trusted services project creation.
Arm team has been developing reference trusted services running in Secure EL0 that we plan to upstream in TF.org. This would form a new project to provide trusted services running on A profile devices.
The topic has already been discussed in board and Arm engineering team will provide further details in the TSC meeting.
Thanks
Abhishek
Attendees
Dan Handley (Arm)
Eric Finco (ST)
Kangkang (Futurewei)
Julius Werner (Google)
Joakim Bech (Linaro)
Kevin Townsend (Linaro)
Praneeth Bajjuri (TI)
David Brown (Linaro)
Bill Fletcher (Linaro Community Projects)
Don Harbin (Linaro Community Projects)
Andrej Butok (NXP)
Dave Cocca (Renesas)
Minutes
Inclusivity language
JW: Proposing to follow lead of other open source projects in removing some
terms seen as non inclusive. Same as Linux did recently. May have to make
exception for some dependencies
DB: Wait for documentation of a device to do it, or proceed with it and
risk coming up with different terms. Seems suggesting to wait for upstream
to come up with it. A lot of older protocols may not get changed.
JW: Lowest common denominator to not update before internal dependencies.
DB: If the community agrees on a consensus on new terminology worth moving
to it.
AP: No issue to declare intent on e.g. wiki page.
AB: Some specifications are fixed and can’t change. Seems America centric.
In NXP there are no emails on this.
DanH: Can set a baseline for new work. Retrospective action can be more
problematic in terms of specs but local documentation is easier. E.g.
branch names possible - but has impact.
AP: If some devices have named hardware registers changing it could be
problematic vs pure software. Also it’s a personal thing.
DanH: Have to consider company interest and also TF.org
JW: Don’t think this is going to go away. Look at the volume of projects
working on this. Believe we might as well get started now.
EF: Agree should be a difference between internal company and tf.org.
Similar situation in ST to NXP. No pressure from stakeholders.
AP: Believe we look to cover the spirit of this and then look at the
practicalities
JW: Internal terminology vs from outside. Don’t believe we should set
deadlines. Decide if want it for future submissions
DC: Makes sense going forward to implement the intention for anything new
and also to participate in arriving at some common new terminology in the
industry.
KS: Think this a political topic. If TF has a proposal then each members
can take it back to their company.
DC: I think we can accommodate better terminology moving forward.
AP: Propose to stop the agenda here and it will be on the agenda for the
next meeting.
DanH: Changes to coding guidelines will need to be in several places
AP: Wondering if have something similar to maintenance guideline on the wiki
KK: Many of the alternatives will translate back to the same words in
Chinese. Will take a proposal back to the company.
AP: Note TSC mailing list is a public archive
Project Release Strategy
JB: How to make TF the source of information for projects (releases,
roadmap etc)?
Groups.io
DanH: Expenditure approved in the Board
AP: Have information from e.g. Zephyr project that they moved their archive
to groups.io
Standard Hardware requirements
EF: Didn’t have the bandwidth to prepare something on this. Can close it
for now
Gitlab/Github
DanH: Raised Linaro Lab ticket for prototyping. Appears easy.
AP: Final decision based on a prototype?
DanH: Goal to provide more community friendly front end - simple pull
request mechanism. Everything would have a GitHub FE but Gerrit would be
the ‘truth’ with respect to reviews. Also gives integrated issue tracker.
AP: Current infrastructure seems ‘clunky’ to some people
DanH: Need to get a suitable GH organization account.
Website Improvements
BF: Have had several rounds of review from Shebu/Matteo. OK with the
current design. Want to synchronise the transition next week aligned with
Connect presentation.
BF: After it’s live, will be open for changes from members
BF: Preview is available for review now.
https://production-trustedfirmware-org-265.websitepreview.linaro.org/
Supporting X.519
AP: Proposal sent by Kevin at the start of the year.
DB: Also involvement with SDO work
AP: Generated a clear requirement on 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 All,
As Linaro Connect starts tomorrow, here are some pointers to sessions that
will be of interest related to trustedfirmware.org.
- *PSA Secure Partitions in OP-TEE*
- Tuesday, September 22nd (1:25-1:50pm UTC)
- Speaker: Miklos Balint
- Slides available here
<https://static.sched.com/hosted_files/lvc20/9a/LVC20-112_PSA_Secure_Partiti…>
- *Trusted Firmware Project update*
- Tuesday, Sept. 22nd (2:00-2:25pm UTC)
- Spreaders: Matteo Carlini, Shebu Kuriakose
- Slides available here
<https://static.sched.com/hosted_files/lvc20/1e/LVC20-113-Trusted-Firmware-p…>
- *Scalable Security Using Trusted Firmware-M Profiles*
- Wednesday September 23rd (11.45am – 12.10pm UTC)
- Speakers: Shebu Kuiakose, David Want
- Slides available here
<https://static.sched.com/hosted_files/lvc20/d0/ScalableSecurityUsingTrusted…>
- *Enable UEFI Secure Boot using OP-TEE as Secure Partition*
- Thursday September 24th (3.45-4.10pm UTC)
- Speakers: Sahil Malhotra, Ilias Apalodimas
- *Secure Partition Manager (SEL2 firmware) for Arm A-class devices*
- Thursday September 24th (4.15-4.40pm UTC)
- Speaker: Olivier Deprez
- Slides are available here
<https://static.sched.com/hosted_files/lvc20/09/LVC20-305-secure-partition-m…>
Some general pointers to sessions of potential interest:
- Security related topics can be viewed here
- Boot architecture topics can be viewed here
As a reminder, sign up for tomorrow's event is at Linaro Connect
Registration <https://connect.linaro.org/> and is free, so feel free to
forward this information on. :)
The overall schedule is available at the same link as registration in case
you may be interested in other sessions.
Best regards,
Don
Hi Andrej,
> Hope it's a joke.
> Are you going to create a list with "forbidden" worlds?
No, this is not a joke. This is a development that is happening all
over the industry, for example in Python
(https://bugs.python.org/issue34605) or Git
(https://sfconservancy.org/news/2020/jun/23/gitbranchname/) or MySQL
(https://mysqlhighavailability.com/mysql-terminology-updates/). You
can find a summary of the reasons in this IETF Memo
(https://tools.ietf.org/html/rfc7704), and there's also some
additional discussion and insight in the original patch submission
that added this to Linux (https://lkml.org/lkml/2020/7/4/229).
I know this is a pretty US-centric topic, and those words don't have
the same strongly charged connotations for everyone around the world
as they do for people who have been directly affected by the US'
unique history of slavery and ongoing racial injustice. But Trusted
Firmware is an international project with a substantial amount of
contributors from the US. So even though this issue may not affect
everyone, it may affect some of our contributors (and especially also
potential contributors) strongly enough that I think we owe it to them
to at least discuss options for improving the situation. We should
strive to be an inclusive and welcoming open-source project for
everyone.
> Just opened our chip User Manual:
> "master"- 1057 instances
> "slave" - 1011 instances
> We need to initialize "slave(s)" or "master(s)", so we have to use these words in our and Trusted Firmware code.
Yes, like I mentioned, I am well aware that there are practical
concerns with this. A lot of Trusted Firmware code is about accessing
hardware, and the terminology of that hardware was usually set in
stone when it was designed. In some cases these terms are even tied to
a common hardware standard, like for SPI or I2C busses. In those cases
the standard needs to change first before the hardware can change (and
there are attempts to do that for example for SPI:
https://www.oshwa.org/a-resolution-to-redefine-spi-signal-names), and
it will take years before those changes actually result in new
hardware avoiding these terms. I am not saying that we should stop
calling hardware registers by the name that's written in the manual in
the meantime -- we should absolutely make exceptions where necessary
to keep things practical. I am just proposing that we slowly get
started on this issue, put it in the style guide, clearly list the
remaining necessary exceptions, and maybe start looking for
low-hanging fruit where existing code uses these terms in cases that
are not tied to hardware or other external dependencies and could be
changed easily.
The Linux rules codified this as "Exceptions for introducing new usage
is to maintain a userspace ABI/API or when updating code for an
existing (as of 2020) hardware or protocol specification that mandates
those terms." -- I think we could aim for a similar guideline (minus
the userspace ABI part which doesn't really apply to us). We should
probably also consider exceptions for future hardware for a couple of
years since these things take a long time to change. The hope is that
over time companies will on their own start avoiding this terminology
in hardware designs, with Linux leading the way as a forcing function
that we can basically just follow (since it requires drivers for most
of the stuff we access too, at least for TF-A).
> Let's have the initial discussion in this week's meeting to create the context for everyone. Julius, hope you are ok to lead the discussion?
> We then add it to the agenda for next month's meeting which hopefully provides everyone enough time to look at the details, consult within their organizations and consider the implications for their teams.
Yes, sounds good. I totally understand that there may be practical
concerns about this, especially in areas where the existing
terminology is well-established. I don't intend to change the whole
codebase overnight or stop anyone's productivity dead in their tracks.
I just want to get a discussion started about first of all making a
decision whether we want this in general, and then trying to identify
the best ways to further that goal while keeping practicality in mind.
> Ideally, we would also have a summary of the current projects just to understand the amount of updates that may be required.
I grepped a few numbers from TF-A to get started:
- blacklist: 0
- whitelist: 1
- master: 403
- 242 in plat/
- 47 in plat/brcm
- 44 in plat/xilinx
- 35 in plat/imx
- 30 in plat/mediatek
- 28 in plat/arm
- 41 in docs/ (most of these talking about the Git branch, not
master/slave relationships)
- 62 in drivers/arm/ccn + includes
- 18 in drivers/arm/cci + includes
- 17 in drivers/brcm + includes
- slave: 246
- 155 in plat/
- 72 in plat/renesas
- 18 in plat/mediatek
- 15 in plat/xilinx
- 14 in plat/nvidia
- 14 in plat/rockchip
- 27 in drivers/arm/cci + includes
- 25 in drivers/mtd/spi_mem + includes
- 23 in drivers/renesas/rcar
Note that I don't necessarily expect we'd want to start a huge effort
to get all of those cleaned up, especially for old outdated platform
ports that understandably nobody wants to invest time in anymore.
Hardware support code naturally ages and becomes obsolete over time
anyway. I think establishing guidelines for future submissions is much
more important in the long run. If we do want to clean up existing
code, it would probably be most useful to focus on generic
(non-platform) code that can be expected to have a longer lifetime.
Hi Julius, All,
We are very supportive of the discussion related to inclusivity in the project.
At the same time, we don't know what would be the practical implications for contributors and users of the project so I suggest we take this discussion in stages.
Let's have the initial discussion in this week's meeting to create the context for everyone. Julius, hope you are ok to lead the discussion?
We then add it to the agenda for next month's meeting which hopefully provides everyone enough time to look at the details, consult within their organizations and consider the implications for their teams.
Ideally, we would also have a summary of the current projects just to understand the amount of updates that may be required.
Hope this is agreeable to everyone.
Thanks,
Abhishek
-----Original Message-----
From: TSC <tsc-bounces(a)lists.trustedfirmware.org> On Behalf Of Julius Werner via TSC
Sent: 14 September 2020 23:50
To: tsc(a)lists.trustedfirmware.org
Subject: [TF-TSC] Avoiding noninclusive language in Trusted Firmware code
Hi all,
I'd like to propose a short discussion topic for the next TSC meeting on Thursday. I've already brought this up in a recent board meeting with generally positive feedback, but we agreed that it's probably more of a topic for the TSC.
As some of you are probably aware, inspired by the recent and ongoing protests and societal discourse in the United States, many open source projects and platforms (from Python to GitHub) have started to reevaluate the terminology they use in code and documentation and updated their style guides to promote the use of inclusive terminology. Probably most closely related to our project, the Linux kernel recently merged a patch to deprecate the usage of the terms 'master' and 'slave' as well as 'blacklist' and 'whitelist' in their
codebase: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit?i…
I would like to propose that the Trusted Firmware projects (I'm primarily interested in TF-A, but this would probably be something worth coordinating across projects) follow suit and start working on a similar change. Since a lot of our developers are also active in Linux and it is facing many of the same challenges (particularly with terminology tied to specific hardware standards), my proposal would be to basically just follow Linux' guidance regarding affected terms and policy here. I of course do not expect that we'll instantly delete every instance of the word 'master' or 'slave' from the repository, especially since like Linux we have many drivers for hardware where this terminology is already present in register names or protocol standards. But I think it would be important to codify the intention in the style guide to get started and provide guidance for reviewers of new submissions, even though cleaning up existing code is a long-term task and some code will probably remain stuck on them due to external dependencies.
I hope we can have a quick discussion in the meeting to gauge overall opinion of this idea and, if positive, decide on the best approach to bring it to the individual projects.
Thanks,
Julius
Hi All,
Any agenda items to add?
Currently these are on my list:
* Avoiding noninclusive language in code and documentation.
* Ongoing items to close or discuss further -
* Project release strategy
* Groups.io
* Standard hardware requirements
* Gitlab/Github
* Website improvements
Thanks,
Abhishek
Hope it's a joke.
Are you going to create a list with "forbidden" worlds?
-----Original Message-----
From: TSC <tsc-bounces(a)lists.trustedfirmware.org> On Behalf Of Julius Werner via TSC
Sent: Tuesday, September 15, 2020 12:50 AM
To: tsc(a)lists.trustedfirmware.org
Subject: [TF-TSC] Avoiding noninclusive language in Trusted Firmware code
Hi all,
I'd like to propose a short discussion topic for the next TSC meeting on Thursday. I've already brought this up in a recent board meeting with generally positive feedback, but we agreed that it's probably more of a topic for the TSC.
As some of you are probably aware, inspired by the recent and ongoing protests and societal discourse in the United States, many open source projects and platforms (from Python to GitHub) have started to reevaluate the terminology they use in code and documentation and updated their style guides to promote the use of inclusive terminology. Probably most closely related to our project, the Linux kernel recently merged a patch to deprecate the usage of the terms 'master' and 'slave' as well as 'blacklist' and 'whitelist' in their
codebase: https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.kerne…
I would like to propose that the Trusted Firmware projects (I'm primarily interested in TF-A, but this would probably be something worth coordinating across projects) follow suit and start working on a similar change. Since a lot of our developers are also active in Linux and it is facing many of the same challenges (particularly with terminology tied to specific hardware standards), my proposal would be to basically just follow Linux' guidance regarding affected terms and policy here. I of course do not expect that we'll instantly delete every instance of the word 'master' or 'slave' from the repository, especially since like Linux we have many drivers for hardware where this terminology is already present in register names or protocol standards. But I think it would be important to codify the intention in the style guide to get started and provide guidance for reviewers of new submissions, even though cleaning up existing code is a long-term task and some code will probably remain stuck on them due to external dependencies.
I hope we can have a quick discussion in the meeting to gauge overall opinion of this idea and, if positive, decide on the best approach to bring it to the individual projects.
Thanks,
Julius
Hi all,
I'd like to propose a short discussion topic for the next TSC meeting
on Thursday. I've already brought this up in a recent board meeting
with generally positive feedback, but we agreed that it's probably
more of a topic for the TSC.
As some of you are probably aware, inspired by the recent and ongoing
protests and societal discourse in the United States, many open source
projects and platforms (from Python to GitHub) have started to
reevaluate the terminology they use in code and documentation and
updated their style guides to promote the use of inclusive
terminology. Probably most closely related to our project, the Linux
kernel recently merged a patch to deprecate the usage of the terms
'master' and 'slave' as well as 'blacklist' and 'whitelist' in their
codebase: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit?i…
I would like to propose that the Trusted Firmware projects (I'm
primarily interested in TF-A, but this would probably be something
worth coordinating across projects) follow suit and start working on a
similar change. Since a lot of our developers are also active in Linux
and it is facing many of the same challenges (particularly with
terminology tied to specific hardware standards), my proposal would be
to basically just follow Linux' guidance regarding affected terms and
policy here. I of course do not expect that we'll instantly delete
every instance of the word 'master' or 'slave' from the repository,
especially since like Linux we have many drivers for hardware where
this terminology is already present in register names or protocol
standards. But I think it would be important to codify the intention
in the style guide to get started and provide guidance for reviewers
of new submissions, even though cleaning up existing code is a
long-term task and some code will probably remain stuck on them due to
external dependencies.
I hope we can have a quick discussion in the meeting to gauge overall
opinion of this idea and, if positive, decide on the best approach to
bring it to the individual projects.
Thanks,
Julius
Attendees
Dan Handley (Arm)
Ashutosh Singh (Arm)
Eric Finco (ST)
Lionel Debieve (ST)
Kangkang (Futurewei)
Julius Werner (Google)
Joakim Bech (Linaro)
Erik Shreve (TI)
David Brown (Linaro)
Bill Fletcher (Linaro Community Projects)
Andrej Butok (NXP)
Dave Cocca (Renesas)
`
Minutes
Website UX
BF: (see slide).
Have set up a specific branch for the website code on GitHub that generates
a preview.
Would like project leads for each project to fill out the schema at the top
of each of the project pages with the key project-specific links to
code/review/documentation etc and a small amount of descriptive text. If
they push that to the new UX branch it will update the preview.
DH: Are approvals needed?
BF: Admins for the website code approve PRs, but this is still just a
preview, not the live site.
Landing CHERI/Morello enabled Hafnium
https://developer.arm.com/architectures/cpu-architecture/a-profile/morellohttps://www.cl.cam.ac.uk/research/security/ctsrd/cheri/cheri-morello.html
JB: Have an implementation of Hafnium that pre-dates TF. Consortium asking
if this is something that TF would be interested in. Have asked Robert from
Cambridge Uni if he would be able to give an overview of the project.
EF: Is there a specific usecase or is it just that it’s available?
JB: Nothing to prevent having Morello in any firmware component. This is a
proof of concept - not confirmed that it will become a product. Aim is to
kill big classes of security issues.
JB: Should we say it’s too early or ask Robert to present?
DH: Are others interested? Maybe it’s a bit early?
JB: Can still ask if Robert is available/interested to discuss.with us.
Ownership of project release strategy/execution, especially for OP-TEE
JB: For OP-TEE after transfer to TF, have been asked who is setting the
direction of the project. Still currently mainly Lenaro. Seems wrong that
Linaro Jira instance has details of when we are going to make releases.
Should we create some kind of tracking internally?
EF: Intent in transfer was to encourage other users of OP-TEE to become
more active in the community. Needs minimum infrastructure to show a live
forum. Seems a mandatory step to set this up.
DH: Seems a Product Management/Technology Management question. Could ask
Arm Technology Managers (Matteo/Shebu) to take on more of a role. Shebu is
looking at Arm’s contributions to OP-TEE.
JB: Main contributors are Linaro Members, Arm, non-members. Would be good
if could get these 3 groups closer together.
DH: For other projects intersection of collaborators is more complex. Feels
like we need a TF.org roadmap that coalesces each individual project
contribution.
JB: Would be nice to have some kind of reference implementation with
OP-TEE, TF, Mbed-TLS, Hafnium …
DH: That’s a ‘platform solutions’ problem (different team in Arm). Could
point to work done by the teams involved in that within Arm. Are we looking
for alignment and unified releases. Think projects would want to determine
their own cadence.
JB: Yes. But should be possible to find when the releases are happening
from tf.org.
DH: You were also talking about the resources to make the releases.
JB: We are rotating between Linaro staff to do the releases. Maybe just
showing how/when it will happen on the website project page. also get the
question a couple of times on LTS branches.
DH: Don’t think project teams would be able to manage additional LTS costs.
AS: Same for TF-M. No plan yet for TLS.
DH: Think LTS is something special. Primary customers are product vendors.
JB: Will think some more and come up with a proposal
Standard Hardware Requirements
EF: Minimum hardware requirements. Was discussed back in June. Abhishek
proposed to come back on it when I was available. When we discuss Level 3
isolation, what is the minimum number of descriptors needed. Was a
presentation on this in the Tech Forum. also discussion of different
profiles. Could TF-M specify the minimum requirements for HW to support the
features?
DH: Minimum number of MPU regions - function of the number of secure
services that need to be supported. Does it not follow from that? Does PSA
specify?
EF: Didn’t find it in the PSA document
DH: Probably not explicit but maybe it can be inferred.
EF: PSA doesn’t enforce implementation. Could provide SiPs with what the
profiles mean.
DH: If it’s missing (from PSA) then needs to be defined somewhere.
AS: Partly defined in PSA but doesn’t go to the granularity for e.g.
different profiles. Do see value but separate discussion as to where.
Number of descriptors doesn’t scale with number of regions since can
re-use. Do need to reserve a few for the core code. MPU is one hardware
piece but what about other bus masters?
DH: Seems like a need for some kind of hardware integration guide.
AS: would hope that someone from the user community can come up with a
starting point. Could be a topic for the Technical Forum and some initial
point for what makes sense for each of the profiles.
Groups.io discussion
DH: Considered a better interface than plain old mailman lists.
DB: Zephyr happy with it. Could use it and not realise it has the web
interface.
DH: Conclusion to migrate completely. Take a break or migrate domain
support. $1000/y for non-profits. If TSC think it’s ok then can just push
this to the Board.
BF: Current cost to the project for Linaro to maintain the mailman servers
(plus endless spam work)
DC: Sounds good. In favour.
JB: Agree (vs mailman)
GitHub/GitLab discussion
DH: Started with the reasons that OP-TEE should stay on GitHub (from
Joakim). Think Mbed-TLS would agree. Other projects in Arm looking at how
to upstream. Issue tracking and wiki is currently not used consistently.
Arm looking at GitLab internally. May not be the driving requirement for
TF. Point raised by Julius that GitHub code review is not ideal. Either
hybrid solution or some kind of plug in (to GitHub)
DB: Are projects that do Gerrit review on GitHub.
DH: There is ‘GerritHub’ but also possible plugins.
DB: Also the issue of ‘community’ in that it’s an expectation that embedded
work will happen on GitHub.
EF: Spoke to some of our developers had a very negative view of GitLab (may
be ST specific).
DH: Is self-hosting a requirement?
DB: Don’t have DoS issues
DH: Mbed TLS does use private repositories for security advisories.
DB: Can have private repositories on GitHub
JB: (Demonstrates security advisory/private repositories)
DH: Who owns https://github.com/TrustedFirmware ? (Action BF)
Action BF/DH to look at the hybrid solution
DH: MbedTLS will have to move since under an Arm/Mbed account. Bit worried
about lumping many projects under one organisation due to potential risks.
Like that OP-TEE is in it’s own org account.
--
[image: Linaro] <http://www.linaro.org/>
*Bill Fletcher* | *Field Engineering*
T: +44 7833 498336 <+44+7833+498336>
bill.fletcher(a)linaro.org | Skype: billfletcher2020
Sorry I missed Eric's topics. I've broadened the release topic to include LTS releases.
* Update on website rework (Bill)
* Landing CHERI enabled Hafnium (Joakim). Some background:
https://developer.arm.com/architectures/cpu-architecture/a-profile/morellohttps://www.cl.cam.ac.uk/research/security/ctsrd/cheri/cheri-morello.html
* Ownership of project release strategy/execution, including LTS releases (Joakim, at least for OP-TEE part)
* Standard HW requirements for TF-M, e.g. min number of MPU regions for level 3 isolation (Eric)
* Continuation of Groups.io discussion (Dan)
* Continuation of GitHub/GitLab discussion (Dan)
Regards
Dan
From: TSC <tsc-bounces(a)lists.trustedfirmware.org> On Behalf Of Dan Handley via TSC
Sent: 20 August 2020 14:52
To: tsc(a)lists.trustedfirmware.org
Subject: Re: [TF-TSC] Request for TSC agenda topics 2020-08-20
Hi all
Thanks for the additional topics. The current agenda is as follows (my proposed order):
* Update on website rework (Bill)
* Landing CHERI enabled Hafnium (Joakim). Some background:
https://developer.arm.com/architectures/cpu-architecture/a-profile/morellohttps://www.cl.cam.ac.uk/research/security/ctsrd/cheri/cheri-morello.html
* Ownership of project release strategy/execution, especially for OP-TEE (Joakim)
* Continuation of Groups.io discussion (Dan)
* Continuation of GitHub/GitLab discussion (Dan)
Regards
Dan.
From: Dan Handley
Sent: 17 August 2020 12:48
To: tsc(a)lists.trustedfirmware.org<mailto:tsc@lists.trustedfirmware.org>
Subject: Request for TSC agenda topics 2020-08-20
Hi all
I'll be chairing the TSC meeting this Thursday. Does anyone have any agenda topics for then?
So far I have:
* Continuation of Groups.io discussion
* Continuation of GitHub/GitLab discussion
Regards
Dan.
Hi all
I'll be chairing the TSC meeting this Thursday. Does anyone have any agenda topics for then?
So far I have:
* Continuation of Groups.io discussion
* Continuation of GitHub/GitLab discussion
Regards
Dan.
Hi,
On Wed, 19 Aug 2020 at 13:20, Dan Handley via TSC <
tsc(a)lists.trustedfirmware.org> wrote:
> Hi
>
>
>
> Regarding the CHERI adaptation of Hafnium, I think we'll need to
> understand the purpose, status and plans for this before we can consider
> the technical/legal aspects. Joakim – do you have that info?
>
Unfortunately I don't have that much background information, since there is
an agreement between the various companies that have been working with it
(Linaro is not one of them). So, I'm a bit of a messenger here in an early
stage, trying to start a discussion around it. Due to this I've already
discussed with Robert N. M. Watson (University of Cambridge) and I've
suggested that we could invite him to one of our TSC calls and he could
explain more about it and after that it should be easier to make a decision
whether this is something the TF TSC would consider being worked on or not.
But before inviting people outside the TSC I thought it'd be good to have a
brief discussion within the TSC itself.
Regards,
Joakim
>
>
> Regards
>
>
>
> Dan.
>
>
>
>
>
> *From:* TSC <tsc-bounces(a)lists.trustedfirmware.org> *On Behalf Of *Serban
> Constantinescu via TSC
> *Sent:* 19 August 2020 11:25
> *To:* Joakim Bech <joakim.bech(a)linaro.org>; Andrew Walbran <
> qwandor(a)google.com>
> *Cc:* tsc(a)lists.trustedfirmware.org
> *Subject:* Re: [TF-TSC] Request for TSC agenda topics 2020-08-20
>
>
>
> +Andrew Walbran <qwandor(a)google.com> in case he has any opinions on the
> CHERI proposal below.
>
>
>
> Hi Joakim,
>
>
>
> On Tue, Aug 18, 2020 at 6:01 PM Joakim Bech via TSC <
> tsc(a)lists.trustedfirmware.org> wrote:
>
> Hi,
>
>
>
> If there is enough time, then I would like to discuss OP-TEE release work,
> questions like: Who will make the release? When should it be done? Where
> should it be tracked? Currently, the answer to all of those are more or
> less "Linaro / Linaro decides", but our (Linaro's) impression is that we
> should try to get this transferred to TrustedFirmware in some way. Linaro
> will certainly be involved in that kind of work in the future also, but we
> believe that the directions should come from TrustedFirmware.org instead of
> Linaro. This might even be something to consider for all TF projects? I.e.,
> not only OP-TEE? But again .. if time permits, otherwise we can push it to
> another call.
>
>
>
> A second topic is related to CHERI [1] and Hafnium. People working with
> the CHERI project asked me whether TrustedFirmware would be interested
> in an open-source CHERI adaptation of Hafnium? So I'd like to get the
> opinion from the TSC with regards to that. If the TSC is positive to it,
> then we have a few other things to consider like where it should go,
> separate CHERI branch(es), official tree with compile time flags? How to
> staff the activity? Legal aspects? Etc.
>
>
>
> Leaving aside the legal aspects which Arm and TF should express a view on,
> I suggest we first review the CHERI changes.
>
>
>
> If they don't put in danger any of the product deadlines and do not
> increase the code significantly we could consider incorporating them as
> part of the official tree. However, I believe the changes are based on an
> old Hafnium fork and add a non-trivial amount of new code - if that's the
> case a separate branch is a better option to start with.
>
>
>
> Best,
>
> Serban
>
>
>
>
>
> [1] http://cheri-cpu.org/
>
>
> Regards,
>
> Joakim
>
>
>
>
>
> On Mon, 17 Aug 2020 at 15:55, Bill Fletcher via TSC <
> tsc(a)lists.trustedfirmware.org> wrote:
>
> Hi Dan
>
>
>
> I can give an update on the website rework.
>
>
>
> Regards
>
>
>
> Bill
>
>
>
> On Mon, 17 Aug 2020 at 12:47, Dan Handley via TSC <
> tsc(a)lists.trustedfirmware.org> wrote:
>
> Hi all
>
>
>
> I'll be chairing the TSC meeting this Thursday. Does anyone have any
> agenda topics for then?
>
>
>
> So far I have:
>
>
>
> * Continuation of Groups.io discussion
>
>
>
> * Continuation of GitHub/GitLab discussion
>
>
>
> Regards
>
>
> Dan.
>
>
>
> --
> TSC mailing list
> TSC(a)lists.trustedfirmware.org
> https://lists.trustedfirmware.org/mailman/listinfo/tsc
>
>
>
>
> --
>
>
>
> [image: Linaro] <http://www.linaro.org/>
>
> *Bill Fletcher* | *Field Engineering*
>
> T: +44 7833 498336 <+44+7833+498336>
> bill.fletcher(a)linaro.org | Skype: billfletcher2020
>
>
>
> --
> TSC mailing list
> TSC(a)lists.trustedfirmware.org
> https://lists.trustedfirmware.org/mailman/listinfo/tsc
>
> --
> TSC mailing list
> TSC(a)lists.trustedfirmware.org
> https://lists.trustedfirmware.org/mailman/listinfo/tsc
>
> --
> TSC mailing list
> TSC(a)lists.trustedfirmware.org
> https://lists.trustedfirmware.org/mailman/listinfo/tsc
>
Hi
Regarding the CHERI adaptation of Hafnium, I think we'll need to understand the purpose, status and plans for this before we can consider the technical/legal aspects. Joakim – do you have that info?
Regards
Dan.
From: TSC <tsc-bounces(a)lists.trustedfirmware.org> On Behalf Of Serban Constantinescu via TSC
Sent: 19 August 2020 11:25
To: Joakim Bech <joakim.bech(a)linaro.org>; Andrew Walbran <qwandor(a)google.com>
Cc: tsc(a)lists.trustedfirmware.org
Subject: Re: [TF-TSC] Request for TSC agenda topics 2020-08-20
+Andrew Walbran<mailto:qwandor@google.com> in case he has any opinions on the CHERI proposal below.
Hi Joakim,
On Tue, Aug 18, 2020 at 6:01 PM Joakim Bech via TSC <tsc(a)lists.trustedfirmware.org<mailto:tsc@lists.trustedfirmware.org>> wrote:
Hi,
If there is enough time, then I would like to discuss OP-TEE release work, questions like: Who will make the release? When should it be done? Where should it be tracked? Currently, the answer to all of those are more or less "Linaro / Linaro decides", but our (Linaro's) impression is that we should try to get this transferred to TrustedFirmware in some way. Linaro will certainly be involved in that kind of work in the future also, but we believe that the directions should come from TrustedFirmware.org instead of Linaro. This might even be something to consider for all TF projects? I.e., not only OP-TEE? But again .. if time permits, otherwise we can push it to another call.
A second topic is related to CHERI [1] and Hafnium. People working with the CHERI project asked me whether TrustedFirmware would be interested in an open-source CHERI adaptation of Hafnium? So I'd like to get the opinion from the TSC with regards to that. If the TSC is positive to it, then we have a few other things to consider like where it should go, separate CHERI branch(es), official tree with compile time flags? How to staff the activity? Legal aspects? Etc.
Leaving aside the legal aspects which Arm and TF should express a view on, I suggest we first review the CHERI changes.
If they don't put in danger any of the product deadlines and do not increase the code significantly we could consider incorporating them as part of the official tree. However, I believe the changes are based on an old Hafnium fork and add a non-trivial amount of new code - if that's the case a separate branch is a better option to start with.
Best,
Serban
[1] http://cheri-cpu.org/
Regards,
Joakim
On Mon, 17 Aug 2020 at 15:55, Bill Fletcher via TSC <tsc(a)lists.trustedfirmware.org<mailto:tsc@lists.trustedfirmware.org>> wrote:
Hi Dan
I can give an update on the website rework.
Regards
Bill
On Mon, 17 Aug 2020 at 12:47, Dan Handley via TSC <tsc(a)lists.trustedfirmware.org<mailto:tsc@lists.trustedfirmware.org>> wrote:
Hi all
I'll be chairing the TSC meeting this Thursday. Does anyone have any agenda topics for then?
So far I have:
* Continuation of Groups.io discussion
* Continuation of GitHub/GitLab discussion
Regards
Dan.
--
TSC mailing list
TSC(a)lists.trustedfirmware.org<mailto:TSC@lists.trustedfirmware.org>
https://lists.trustedfirmware.org/mailman/listinfo/tsc
--
[Linaro]<http://www.linaro.org/>
Bill Fletcher | Field Engineering
T: +44 7833 498336<tel:+44+7833+498336>
bill.fletcher(a)linaro.org<mailto:bill.fletcher@linaro.org> | Skype: billfletcher2020
--
TSC mailing list
TSC(a)lists.trustedfirmware.org<mailto:TSC@lists.trustedfirmware.org>
https://lists.trustedfirmware.org/mailman/listinfo/tsc
--
TSC mailing list
TSC(a)lists.trustedfirmware.org<mailto:TSC@lists.trustedfirmware.org>
https://lists.trustedfirmware.org/mailman/listinfo/tsc
+Andrew Walbran <qwandor(a)google.com> in case he has any opinions on the
CHERI proposal below.
Hi Joakim,
On Tue, Aug 18, 2020 at 6:01 PM Joakim Bech via TSC <
tsc(a)lists.trustedfirmware.org> wrote:
> Hi,
>
> If there is enough time, then I would like to discuss OP-TEE release work,
> questions like: Who will make the release? When should it be done? Where
> should it be tracked? Currently, the answer to all of those are more or
> less "Linaro / Linaro decides", but our (Linaro's) impression is that we
> should try to get this transferred to TrustedFirmware in some way. Linaro
> will certainly be involved in that kind of work in the future also, but we
> believe that the directions should come from TrustedFirmware.org instead of
> Linaro. This might even be something to consider for all TF projects? I.e.,
> not only OP-TEE? But again .. if time permits, otherwise we can push it to
> another call.
>
> A second topic is related to CHERI [1] and Hafnium. People working with
> the CHERI project asked me whether TrustedFirmware would be interested
> in an open-source CHERI adaptation of Hafnium? So I'd like to get the
> opinion from the TSC with regards to that. If the TSC is positive to it,
> then we have a few other things to consider like where it should go,
> separate CHERI branch(es), official tree with compile time flags? How to
> staff the activity? Legal aspects? Etc.
>
Leaving aside the legal aspects which Arm and TF should express a view on,
I suggest we first review the CHERI changes.
If they don't put in danger any of the product deadlines and do not
increase the code significantly we could consider incorporating them as
part of the official tree. However, I believe the changes are based on an
old Hafnium fork and add a non-trivial amount of new code - if that's the
case a separate branch is a better option to start with.
Best,
Serban
> [1] http://cheri-cpu.org/
>
> Regards,
> Joakim
>
>
> On Mon, 17 Aug 2020 at 15:55, Bill Fletcher via TSC <
> tsc(a)lists.trustedfirmware.org> wrote:
>
>> Hi Dan
>>
>> I can give an update on the website rework.
>>
>> Regards
>>
>> Bill
>>
>> On Mon, 17 Aug 2020 at 12:47, Dan Handley via TSC <
>> tsc(a)lists.trustedfirmware.org> wrote:
>>
>>> Hi all
>>>
>>>
>>>
>>> I'll be chairing the TSC meeting this Thursday. Does anyone have any
>>> agenda topics for then?
>>>
>>>
>>>
>>> So far I have:
>>>
>>>
>>>
>>> * Continuation of Groups.io discussion
>>>
>>>
>>>
>>> * Continuation of GitHub/GitLab discussion
>>>
>>>
>>>
>>> Regards
>>>
>>>
>>> Dan.
>>>
>>>
>>> --
>>> TSC mailing list
>>> TSC(a)lists.trustedfirmware.org
>>> https://lists.trustedfirmware.org/mailman/listinfo/tsc
>>>
>>
>>
>> --
>>
>> [image: Linaro] <http://www.linaro.org/>
>> *Bill Fletcher* | *Field Engineering*
>> T: +44 7833 498336 <+44+7833+498336>
>> bill.fletcher(a)linaro.org | Skype: billfletcher2020
>>
>> --
>> TSC mailing list
>> TSC(a)lists.trustedfirmware.org
>> https://lists.trustedfirmware.org/mailman/listinfo/tsc
>>
> --
> TSC mailing list
> TSC(a)lists.trustedfirmware.org
> https://lists.trustedfirmware.org/mailman/listinfo/tsc
>
Hi Dan and all,
I raised a topic for June TSC but looking at Abhishek minutes and as I was not able to join a couple of TSC meetings afterward, I propose to bring it back on the agenda:
-from June TSC minutes:
>Standard HW requirement for TF-M for PSA levels.
LD- Raising the topic based on Eric's email.
AP - As we have limited details possibly better to discuss next time when Eric joins.
May be TF-M tech forum comes up with proposal for TSC to ratify
-I also attached the email exchanged we had on the TSC list before June meeting on this topic
There was also in June a thread in the TF-A mailing list about an LTS version but I do not think the TSC discussed this topic and took a position on it so I propose to put on the agenda.
Regards,
Eric Finco
[Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: logo_big5]
Eric FINCO | Tel: +33 (0)2 4402 7154
MDG | Technical Specialist
From: TSC <tsc-bounces(a)lists.trustedfirmware.org> On Behalf Of Bill Fletcher via TSC
Sent: lundi 17 août 2020 15:56
To: Dan Handley <Dan.Handley(a)arm.com>
Cc: tsc(a)lists.trustedfirmware.org
Subject: Re: [TF-TSC] Request for TSC agenda topics 2020-08-20
Hi Dan
I can give an update on the website rework.
Regards
Bill
On Mon, 17 Aug 2020 at 12:47, Dan Handley via TSC <tsc(a)lists.trustedfirmware.org<mailto:tsc@lists.trustedfirmware.org>> wrote:
Hi all
I'll be chairing the TSC meeting this Thursday. Does anyone have any agenda topics for then?
So far I have:
* Continuation of Groups.io discussion
* Continuation of GitHub/GitLab discussion
Regards
Dan.
--
TSC mailing list
TSC(a)lists.trustedfirmware.org<mailto:TSC@lists.trustedfirmware.org>
https://lists.trustedfirmware.org/mailman/listinfo/tsc
--
[Linaro]<http://www.linaro.org/>
Bill Fletcher | Field Engineering
T: +44 7833 498336<tel:+44+7833+498336>
bill.fletcher(a)linaro.org<mailto:bill.fletcher@linaro.org> | Skype: billfletcher2020
On 8/18/2020 10:01 AM, Joakim Bech via TSC wrote:
> Hi,
>
> If there is enough time, then I would like to discuss OP-TEE release
> work, questions like: Who will make the release? When should it be done?
> Where should it be tracked? Currently, the answer to all of those are
> more or less "Linaro / Linaro decides", but our (Linaro's) impression is
> that we should try to get this transferred to TrustedFirmware in some
> way. Linaro will certainly be involved in that kind of work in the
> future also, but we believe that the directions should come from
> TrustedFirmware.org instead of Linaro. This might even be something to
> consider for all TF projects? I.e., not only OP-TEE? But again .. if
> time permits, otherwise we can push it to another call.
Thanks Joakim for bringing this up. I am interested in this topic.
If the proposal is to move the future direction role to TF.org, Would
like to understand how and if it will impact any decision making of the
OPTEE roadmap.
>
> A second topic is related to CHERI [1] and Hafnium. People working with
> the CHERI project asked me whether TrustedFirmware would be interested
> in an open-source CHERI adaptation of Hafnium? So I'd like to get the
> opinion from the TSC with regards to that. If the TSC is positive to it,
> then we have a few other things to consider like where it should go,
> separate CHERI branch(es), official tree with compile time flags? How to
> staff the activity? Legal aspects? Etc.
>
> [1] http://cheri-cpu.org/
>
> Regards,
> Joakim
>
>
> On Mon, 17 Aug 2020 at 15:55, Bill Fletcher via TSC
> <tsc(a)lists.trustedfirmware.org <mailto:tsc@lists.trustedfirmware.org>>
> wrote:
>
> Hi Dan
>
> I can give an update on the website rework.
>
> Regards
>
> Bill
>
> On Mon, 17 Aug 2020 at 12:47, Dan Handley via TSC
> <tsc(a)lists.trustedfirmware.org
> <mailto:tsc@lists.trustedfirmware.org>> wrote:
>
> Hi all____
>
> __ __
>
> I'll be chairing the TSC meeting this Thursday. Does anyone have
> any agenda topics for then?____
>
> __ __
>
> So far I have:____
>
> __ __
>
> * Continuation of Groups.io discussion____
>
> __ __
>
> * Continuation of GitHub/GitLab discussion____
>
> __ __
>
> Regards____
>
>
> Dan.____
>
> __ __
>
> --
> TSC mailing list
> TSC(a)lists.trustedfirmware.org <mailto:TSC@lists.trustedfirmware.org>
> https://lists.trustedfirmware.org/mailman/listinfo/tsc
>
>
>
> --
>
> Linaro <http://www.linaro.org/>
> *Bill Fletcher* | /Field Engineering/
> T: +44 7833 498336 <tel:+44+7833+498336>
> bill.fletcher(a)linaro.org <mailto:bill.fletcher@linaro.org> | Skype:
> billfletcher2020
>
>
> --
> TSC mailing list
> TSC(a)lists.trustedfirmware.org <mailto:TSC@lists.trustedfirmware.org>
> https://lists.trustedfirmware.org/mailman/listinfo/tsc
>
>
Hi,
If there is enough time, then I would like to discuss OP-TEE release work,
questions like: Who will make the release? When should it be done? Where
should it be tracked? Currently, the answer to all of those are more or
less "Linaro / Linaro decides", but our (Linaro's) impression is that we
should try to get this transferred to TrustedFirmware in some way. Linaro
will certainly be involved in that kind of work in the future also, but we
believe that the directions should come from TrustedFirmware.org instead of
Linaro. This might even be something to consider for all TF projects? I.e.,
not only OP-TEE? But again .. if time permits, otherwise we can push it to
another call.
A second topic is related to CHERI [1] and Hafnium. People working with the
CHERI project asked me whether TrustedFirmware would be interested in an
open-source CHERI adaptation of Hafnium? So I'd like to get the opinion
from the TSC with regards to that. If the TSC is positive to it, then we
have a few other things to consider like where it should go, separate CHERI
branch(es), official tree with compile time flags? How to staff the
activity? Legal aspects? Etc.
[1] http://cheri-cpu.org/
Regards,
Joakim
On Mon, 17 Aug 2020 at 15:55, Bill Fletcher via TSC <
tsc(a)lists.trustedfirmware.org> wrote:
> Hi Dan
>
> I can give an update on the website rework.
>
> Regards
>
> Bill
>
> On Mon, 17 Aug 2020 at 12:47, Dan Handley via TSC <
> tsc(a)lists.trustedfirmware.org> wrote:
>
>> Hi all
>>
>>
>>
>> I'll be chairing the TSC meeting this Thursday. Does anyone have any
>> agenda topics for then?
>>
>>
>>
>> So far I have:
>>
>>
>>
>> * Continuation of Groups.io discussion
>>
>>
>>
>> * Continuation of GitHub/GitLab discussion
>>
>>
>>
>> Regards
>>
>>
>> Dan.
>>
>>
>> --
>> TSC mailing list
>> TSC(a)lists.trustedfirmware.org
>> https://lists.trustedfirmware.org/mailman/listinfo/tsc
>>
>
>
> --
>
> [image: Linaro] <http://www.linaro.org/>
> *Bill Fletcher* | *Field Engineering*
> T: +44 7833 498336 <+44+7833+498336>
> bill.fletcher(a)linaro.org | Skype: billfletcher2020
>
> --
> TSC mailing list
> TSC(a)lists.trustedfirmware.org
> https://lists.trustedfirmware.org/mailman/listinfo/tsc
>
Hi Dan
I can give an update on the website rework.
Regards
Bill
On Mon, 17 Aug 2020 at 12:47, Dan Handley via TSC <
tsc(a)lists.trustedfirmware.org> wrote:
> Hi all
>
>
>
> I'll be chairing the TSC meeting this Thursday. Does anyone have any
> agenda topics for then?
>
>
>
> So far I have:
>
>
>
> * Continuation of Groups.io discussion
>
>
>
> * Continuation of GitHub/GitLab discussion
>
>
>
> Regards
>
>
> Dan.
>
>
> --
> TSC mailing list
> TSC(a)lists.trustedfirmware.org
> https://lists.trustedfirmware.org/mailman/listinfo/tsc
>
--
[image: Linaro] <http://www.linaro.org/>
*Bill Fletcher* | *Field Engineering*
T: +44 7833 498336 <+44+7833+498336>
bill.fletcher(a)linaro.org | Skype: billfletcher2020
Attendees
Abhishek Pandit (Arm)
Ashutosh Singh (Arm)
Kevin Townsend (Linaro)
Julius Werner (Google)
Erik Shreve (TI)
David Brown (Linaro)
Bill Fletcher (Linaro Community Projects)
Andrej Butok (NXP)
NB: there was not a quorum present. No binding decisions were made.
Agenda/Minutes
Migrating to GitLab - proposal
DB: Why GitLab (vs GitHub)
BF: Self hosting and some concerns vs GitHub direction
AP: Need to improve vs current infrastructure
Built-in docs, wiki and issue tracker vs current cgit
GitHub and GitLab
JW: How is the reviewing system on GitLab? Previously used GitHub and it
wasn’t great. Like Gerrit. Would be unfortunate to regress.
DB: Disadvantage vs GitHub - it’s (yet another) a separate system
KT: Same as for Gerrit today
DB: Is the aim for it to be an open source community project or just a
small group (mostly within Arm) just ‘dump it’ on the world?
Andrey: GitHub is a more popular choice for NXP for hosting open source -
SDK etc
Ashutosh: Most engineers like Gerrit. Only places we don’t like current
infrastructure is documentation and issue tracking.
DB: Split implementation is likely to be painful. Depends on what kind of a
community want to build.
AB: Internally NXP is using Jira for tracking but is moving projects to
GitHub
ES: Seems that we are missing requirements - have requirements for a code
review tool, issue tracking tool etc. If we resort to a survey to
developers, Arm view will outweigh everything else. From TI PoV, would not
recommend e.g. BitBucket. Code review is not good.
DB: Can’t make a decision unless we know what are the requirements and the
relative importance.
AP: Can set up a Phabricator page to collect and provide space to review
the requirements (action on Bill)
AOB
BF: Latest website mockup circulated based on previous feedback. Please
take a look. Will keep the window open for a few days for any comments
before we start implementing.
--
[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 All,
The next TF-A Tech Forum is scheduled for Thu 16th July 2020 16:00 – 17:00 (BST). A reoccurring meeting invite has been sent out to the subscribers of this TF-A mailing list. If you don’t have this please let me know.
Agenda:
* Secure EL2 SPM (Secure Partition Manager) Hafnium-based
* In this TF-A Tech Forum session we present the status and open roadmap for the Secure Partition Manager firmware development. The TF-A SPM is the reference open source implementation for the PSA FF-A (Platform Security Architecture Firmware Framework for A-class) specification in the Secure world. It leverages the Armv8.4-Secure EL2 extension bringing virtualization technology in the Secure world (S-EL2 exception level). The development derives originally from the Google Hafnium project, which has been recently transitioned to https://www.trustedfirmware.org/ under the BSD 3-Clause license.
* Optional TF-A Mailing List Topic Discussions
If TF-A contributors have anything they wish to present at any future TF-A tech forum please contact me to have that scheduled.
Previous sessions, both recording and presentation material can be found on the trustedfirmware.org TF-A Technical meeting webpage: https://www.trustedfirmware.org/meetings/tf-a-technical-forum/
A scheduling tracking page is also available to help track sessions suggested and being prepared: https://developer.trustedfirmware.org/w/tf_a/tf-a-tech-forum-scheduling/ Final decisions on what will be presented will be shared a few days before the next meeting and shared on the TF-A mailing list.
Thanks
Joanna
Attendees:
Dan Handley (Arm)
Ashutosh Singh (Arm)
Lionel Debieve (ST)
Julius Werner (Google)
Andrej Butok (NXP)
David Brown (Linaro)
Joakim Bech (Linaro)
Roman Baker (Cypress)
Mark Grosen (TI)
Abhishek Pandit (Arm)
Notes:
>Standard HW requirement for TF-M for PSA levels.
LD - Raising the topic based on Eric's email.
AP - As we have limited details possibly better to discuss next time when Eric joins.
May be TF-M tech forum comes up with proposal for TSC to ratify.
>Security Incident process update
AS - Logistics in place. Testing public and private keys. Process document on phabricator, about to open it and redirect website to point to it. Sub teams are ready to switch to new process.
AP - Does TSC come under Trusted stakeholder list?
DH - Member company's security teams may register as Trusted Stakeholders but not the TSC as a whole. As explained in the process, after the secondary embargo period but during the public embargo period, the embargoed information may be shared with others in the Trusted Stakeholders' organization. This would be the appropriate time to notify the TSC.
>Update on GP test suite.
JB - TF.org has purchased the GlobalPlatform test suite as agreed on a board vote earlier this year. Linaro will track enablement of the GP test suite in LOC-67 (https://projects.linaro.org/browse/LOC-67). End goal is to run both xtest and GP test automatically on every single patch sent to the OP-TEE project.
>Website improvement
AP - Offline update from Bill. Cost has been approved by board with a show of hands, and the attached slide contain the details of current status.
>Pending item / Coding standard
AP - TF-M coding conventions and industry standards related discussion.
MG - Coding standard should be influenced by industry standards that we want to target.
We should also discuss compiler support.
AP - Currently gcc, armclang and iar are supported. We need inputs from committee members.
LD - Coding convention, is there desire to have fully aligned conventions across projects?
JB - OPTEE follows Kernel
AP - Depends on the spec that we target but otherwise teams can decide.
AOB?
Hi all
The new TrustedFirmware.org security incident process is now live. This process is described here:
https://developer.trustedfirmware.org/w/collaboration/security_center/repor…
Initially the process will be used for the following projects: TF-A, TF-M, OP-TEE and Mbed TLS. The security documentation for each project will be updated soon to reflect this change.
If you are part of an organization that believes it should receive security vulnerability information before it is made public then please ask your relevant colleagues to register as Trusted Stakeholders as described here:
https://developer.trustedfirmware.org/w/collaboration/security_center/trust…
Note we prefer individuals in each organization to coordinate their registration requests with each other and to provide us with an email alias managed by your organization instead of us managing a long list of individual addresses.
Best regards
Dan.
(on behalf of the TrustedFirmware.org security team)
Hi Abhishek,
I would like to propose to discuss in the TSC the topic raised by ST during a TF-M open forum session and that I bring also in the TSC via the mailing list (see thread attached)
Unfortunately, I have a conflict between the TF TSC meeting tomorrow and another meeting that I cannot escape. Lionel will participate and represent ST also for TF-M topic.
Regards,
Eric Finco
[Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: logo_big5]
Eric FINCO | Tel: +33 (0)2 4402 7154
MDG | Technical Specialist
From: TSC <tsc-bounces(a)lists.trustedfirmware.org> On Behalf Of Abhishek Pandit via TSC
Sent: mardi 16 juin 2020 15:28
To: tsc(a)lists.trustedfirmware.org
Subject: [TF-TSC] TSC Agenda 18 Jun 2020
Hi All,
Any agenda items for the TSC meeting this week?
Thanks,
Abhishek
Hi Joanna,
> FYI I've moved the TF-A tech forum back an hour to biweekly Thursday 4-5pm UK time that I think allows the TSC to keep its current setup. TF-A and TF-M are on alternate weeks so folks should be able I hope to go to all three with no clashes. Next TF-A tech forum is this Thursday 18th June.
Thanks, for the heads up! I forgot that my calendar doesn't
auto-update for this one. Unfortunately that makes it very early for
US west coast but I guess that's what I get for rocking the boat. ;)
FYI I've moved the TF-A tech forum back an hour to biweekly Thursday 4-5pm UK time that I think allows the TSC to keep its current setup. TF-A and TF-M are on alternate weeks so folks should be able I hope to go to all three with no clashes. Next TF-A tech forum is this Thursday 18th June.
Hope this helps.
Joanna
On 16/06/2020, 23:00, "TSC on behalf of Julius Werner via TSC" <tsc-bounces(a)lists.trustedfirmware.org on behalf of tsc(a)lists.trustedfirmware.org> wrote:
Hi Abhishek,
I think in the last meeting I asked about trying to avoid the conflict
between the TSC meeting and the TF-A Tech Forum. Have you explored
further options in that regard?Maybe moving the TSC to a different
day... for example, the Board also moved its meetings from Thursday to
Wednesday now. Or we could shift it one week out and then make sure we
always keep either 4 or 6 weeks between meetings (still "monthly" on
average but with slightly irregular cadence).
Thanks,
Julius
--
TSC mailing list
TSC(a)lists.trustedfirmware.org
https://lists.trustedfirmware.org/mailman/listinfo/tsc
Hi Abhishek,
I think in the last meeting I asked about trying to avoid the conflict
between the TSC meeting and the TF-A Tech Forum. Have you explored
further options in that regard?Maybe moving the TSC to a different
day... for example, the Board also moved its meetings from Thursday to
Wednesday now. Or we could shift it one week out and then make sure we
always keep either 4 or 6 weeks between meetings (still "monthly" on
average but with slightly irregular cadence).
Thanks,
Julius
Hi Eric,
On Thu, 28 May 2020 at 08:50, Eric FINCO via TSC <
tsc(a)lists.trustedfirmware.org> wrote:
> Hi TF-TSC folks,
>
>
>
> I was on vacation last week so not able to join the TSC last week.
>
> ST raised a question during the TF-M open forum today concerning the min
> number of MPU descriptors (= min mumber of regions) to be supported in the
> SoC especially for of level 3 isolation support.
>
> Furthermore, putting it in perspective with the “measurement” API
> introduced in the HAL proposal presented in the open forum, one can extend
> the question: Do you think the TF-M TSC shall issue some recommendation for
> the minimal Hw configuration required for different features ?
>
This is something that the TSC should be able to do, but I wonder whether
this isn't already covered in various specifications etc created by Arm the
last couple of years. I'm thinking about for example TBSA-M that is part of
PSA. If MPU descriptors aren't already mentioned, then we could ask to get
it added.
> Somehow, small profile memory footprint is also pointing in the direction.
>
> There was a positive feedback from Ken (Liu) during the open forum slot
> but it could make sense to have the TSC reviewing and approving such thing.
> What do you think ?
>
>
>
> Regards,
>
>
>
> Eric Finco
>
Regards,
Joakim
Hi TF-TSC folks,
I was on vacation last week so not able to join the TSC last week.
ST raised a question during the TF-M open forum today concerning the min number of MPU descriptors (= min mumber of regions) to be supported in the SoC especially for of level 3 isolation support.
Furthermore, putting it in perspective with the "measurement" API introduced in the HAL proposal presented in the open forum, one can extend the question: Do you think the TF-M TSC shall issue some recommendation for the minimal Hw configuration required for different features ? Somehow, small profile memory footprint is also pointing in the direction.
There was a positive feedback from Ken (Liu) during the open forum slot but it could make sense to have the TSC reviewing and approving such thing. What do you think ?
Regards,
Eric Finco
[Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: logo_big5]
Eric FINCO | Tel: +33 (0)2 4402 7154
MDG | Technical Specialist
STMicroelectronics SA
9-11 rue Pierre-Felix Delarue | 72100 Le Mans | France
ST online: www.st.com<http://www.st.com/> | Follow us on twitter: @st_world<http://twitter.com/#!/ST_World>
This communication is confidential and intended solely for the addressee(s). If you are not the intended
recipient, you should not review, retain, copy or distribute the e-mail itself or the information it contains.
In such case, we kindly request you notify the sender by replying to this transmission and delete the
message without disclosing it. Thank you!
P Please consider the environment before printing this e-mail
Attendees
Ruchika Gupta (NXP)
Abhishek Pandit (Arm)
Ashutosh Singh (Arm)
Matteo Carlini (Arm)
Kevin Townsend (Linaro)
Dan Handley (Arm)
Julius Werner (Google)
Mark Grosen (TI)
Bill Mills (TI)
David Brown (Linaro)
Kangkang Shen (Futurewei)
Bill Fletcher (Linaro Community Projects)
Andrej Butok (NXP)
Agenda/Minutes
Website feedback
AP: Feedback from Arm folks - to be sent separately:
scrolling status.
Adding a footer per project.
Structuring the project information differently
TF-A workshop
MC: Possible engagement from members in the workshop e.g.
presentations/keynote
platform ports,
war stories,
project format & contributions,
user stories,
new features,
community development thoughts
KS: Everyone doesn’t attend everything at the same time. Also a panel
discussion could be interesting since more efficient in attendee time. Make
sessions available offline and allow people to contribute afterwards.
MC: Will feed these ideas to the Board
MC: The event format and size will depend on the range of contributions -
‘Arm show’ vs 7 or more companies participating. Not expecting to explore a
public CFP until we’ve explored the membership interest.
KS: Would like to see some discussion about secure variables.
Security incident handling
AS: Top-level mailing list and then a mailing list per project. Membership
of these lists is tightly controlled. Keep the disclosure limited. To allow
conversations to be encrypted we’re setting up PKI.
DH: Correct - we don’t insist on encryption
DB: Management of private keys needs to be spelled out. Once someone has
the private key, they always have it.
AS: Sub mailing lists can’t decrypt the top level mailing list. We need to
have a key revocation mechanism in place (not yet completely defined). Will
need to generate a key pair and have a signing ceremony. Is there a place
to host keys?
DB: Generally the assumption is that private keys are held by individuals.
AS: For the time being will keep it as a manual process unless someone has
a better suggestion.
DB: Will forward link to Stack Overflow page with expected way of doing
things.
AP: Is there a pre-existing guide?
AS: Is quite straightforward. Will be a short guide.
DB: Email client support?
DH: There is an Outlook plug in
AP: Dan sent out mail with process. Can we put it as a proposal on
Phabricator so that don’t need to find it in the email archive.
AS: Yes, will do this and then all the projects can link to Phabricator.
AP: Lack of top level reporting in tf.org is becoming a problem so we can
answer ‘yes’ to outside questions
DB: Think having multiple keys is going to be burdensome. Based on
experience in Zephyr and mcuboot, no one wants to work with PGP.
DH: If allow responses to be to individuals, only need top level key. Don’t
know if it’s acceptable to expose individuals
AP: Suggest offline discussion between Ashu, David and Dan
Forums
AB: Very difficult to follow historic email topics or reproduce a tree of
answers. Can’t check if something was asked previously.
AP: David provided a suggestion for groups.io
DB: Works ok for Zephyr project
DH: Orthogonal to having Slack, but needs some kind of instant messaging
BM: Yocto switched from mailman to groups.io. Think most people don’t know
there’s a forum.
DB: Does the best job of replacing a mail list server - just adds the
functionality of a forum.
BM: Helps an occasional person who doesn’t want to subscribe to do a better
job. Acceptable model for casual users.
AP: Where do archives live?
DB: On groups.io. The Linux Foundation (hosts Zephyr) is finding that it’s
easier to get groups.io to deal with spam.
AP: Suggest the someone could do a proof of concept and demo.
DH: Someone would need to administer it.
DB: 3 tiers of commercial terms. Would need to pay
BF: To talk to Linaro IT about any info on groups.io
AP: Interested to get feedback, thoughts from others. Don’t want to move to
this tool and find out it’s not what people want.
Coding Guidelines
AP: Need to follow up and send nominations of people. Need a couple more
people to make it sustainable.
AOB
JW: Can we avoid scheduling conflict with TF-A Tech Forum?
Action: Abhishek
DH: Threat models. Legal request going through Arm to relicense these under
creative commons.
--
[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 all,
Here's an updated website mockup ahead of today's TSC call taking into
account some of the early feedback (and fixing typos!).
Regards
Bill
On Tue, 19 May 2020 at 10:59, Anton Komlev via TSC <
tsc(a)lists.trustedfirmware.org> wrote:
> Hello,
>
>
>
> 2 items from me:
>
> 1. There was a plan for a project dashboard showing “run-time”
> information / statistics / KPI. If it is hidden somewhere then worth to
> bring it up to a project area.
> 2. The topics split below is a bit unclear to me and looks overlapped.
>
>
>
> Hope it helps,
>
> Anton
>
>
>
>
>
> *From:* TSC <tsc-bounces(a)lists.trustedfirmware.org> * On Behalf Of *Bill
> Fletcher via TSC
> *Sent:* 15 May 2020 18:08
> *To:* tsc(a)lists.trustedfirmware.org
> *Cc:* Jonathon Burcham <jon.burcham(a)linaro.org>; Stuart Waldron <
> stuart.waldron(a)linaro.org>; Kyle Kirkby <kyle.kirkby(a)linaro.org>
> *Subject:* [TF-TSC] Fwd: Trusted Firmware website redesign - proposed way
> forward
>
>
>
> Hi all,
>
>
>
> At the previous TF TSC we had an action to work on the TF.org website.
> Here is a mock up of a new website front page, and also a possible graphics
> template for an example per-project "mini-site" in the attached PDF. It
> could be useful to stimulate some discussion. The other piece of the puzzle
> is a schema representing all the data/links per project so we can have
> consistent links to content across the mini-sites. A mock up of this schema
> looks like this:
>
>
>
> Projects Schema:
>
> Project Title
>
> Project Description
>
> Project Documentation
>
> Project Code
>
> Project Mailing List
>
> Project Call to Actions
>
> Project Code Review
>
> Project Useful Links
>
>
>
> Any comments ahead of the meeting are welcome.
>
>
>
> Regards
>
>
>
> Bill
>
>
>
>
>
>
> --
>
>
>
> [image: Linaro] <http://www.linaro.org/>
>
> *Bill Fletcher* | *Field Engineering*
>
> T: +44 7833 498336 <+44+7833+498336>
> bill.fletcher(a)linaro.org | Skype: billfletcher2020
>
>
> --
> TSC mailing list
> TSC(a)lists.trustedfirmware.org
> https://lists.trustedfirmware.org/mailman/listinfo/tsc
>
--
[image: Linaro] <http://www.linaro.org/>
*Bill Fletcher* | *Field Engineering*
T: +44 7833 498336 <+44+7833+498336>
bill.fletcher(a)linaro.org | Skype: billfletcher2020
One consideration would be groups.io. Zephyr has had pretty good results
with it. For most users, it will behave just like a mailing list, but there
is also a web interface for those that prefer that format.
David
On Wed, May 20, 2020 at 1:21 AM Andrej Butok via TSC <
tsc(a)lists.trustedfirmware.org> wrote:
> Hi all,
>
>
>
> Please think about a possibility to add a TF on-line forum.
>
>
>
> Existing E-mail forum is not convenient to search and follow topics. It’s
> “archaic” 20-year old approach.
>
>
>
> Thanks,
>
> Andrej
>
>
>
> On Tue, 19 May 2020 at 16:09, Abhishek Pandit via TSC <
> tsc(a)lists.trustedfirmware.org> wrote:
>
> Hi All,
>
>
>
> Any agenda items for this week?
>
>
>
> We have following already:
>
> - Website improvements
> - TF-A workshop proposal
> - Security incident handling (update)
> - Pending action items
>
>
>
> Thanks,
>
> Abhishek
>
> --
> TSC mailing list
> TSC(a)lists.trustedfirmware.org
> https://lists.trustedfirmware.org/mailman/listinfo/tsc
> <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru…>
>
> --
> TSC mailing list
> TSC(a)lists.trustedfirmware.org
> https://lists.trustedfirmware.org/mailman/listinfo/tsc
>
Hi all,
Please think about a possibility to add a TF on-line forum.
Existing E-mail forum is not convenient to search and follow topics. It’s “archaic” 20-year old approach.
Thanks,
Andrej
On Tue, 19 May 2020 at 16:09, Abhishek Pandit via TSC <tsc(a)lists.trustedfirmware.org<mailto:tsc@lists.trustedfirmware.org>> wrote:
Hi All,
Any agenda items for this week?
We have following already:
* Website improvements
* TF-A workshop proposal
* Security incident handling (update)
* Pending action items
Thanks,
Abhishek
--
TSC mailing list
TSC(a)lists.trustedfirmware.org<mailto:TSC@lists.trustedfirmware.org>
https://lists.trustedfirmware.org/mailman/listinfo/tsc<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru…>
Hi,
Not strictly necessary and not sure if this is the right forum, but if
there is time left at the end of the meeting we might be able to discuss
configuration of our mailman lists (the new ones). The problem now is that
I get "you need to approve this and that" email almost on daily basis. I've
tried to add a couple of regexp sender filters etc. as a workaround. I just
want to get some feedback from you on how strict or open we shall be with
our mailman settings (for the "open" lists). Too relaxed settings means a
risk of spam and too strict means a risk of approval spam :)
// Regads
Joakim
On Tue, 19 May 2020 at 16:09, Abhishek Pandit via TSC <
tsc(a)lists.trustedfirmware.org> wrote:
> Hi All,
>
>
>
> Any agenda items for this week?
>
>
>
> We have following already:
>
> - Website improvements
> - TF-A workshop proposal
> - Security incident handling (update)
> - Pending action items
>
>
>
> Thanks,
>
> Abhishek
> --
> TSC mailing list
> TSC(a)lists.trustedfirmware.org
> https://lists.trustedfirmware.org/mailman/listinfo/tsc
>
Hi All,
Any agenda items for this week?
We have following already:
* Website improvements
* TF-A workshop proposal
* Security incident handling (update)
* Pending action items
Thanks,
Abhishek
Hello,
2 items from me:
1. There was a plan for a project dashboard showing “run-time” information / statistics / KPI. If it is hidden somewhere then worth to bring it up to a project area.
2. The topics split below is a bit unclear to me and looks overlapped.
[cid:image001.png@01D62DCC.5B74FC20]
Hope it helps,
Anton
From: TSC <tsc-bounces(a)lists.trustedfirmware.org> On Behalf Of Bill Fletcher via TSC
Sent: 15 May 2020 18:08
To: tsc(a)lists.trustedfirmware.org
Cc: Jonathon Burcham <jon.burcham(a)linaro.org>; Stuart Waldron <stuart.waldron(a)linaro.org>; Kyle Kirkby <kyle.kirkby(a)linaro.org>
Subject: [TF-TSC] Fwd: Trusted Firmware website redesign - proposed way forward
Hi all,
At the previous TF TSC we had an action to work on the TF.org website. Here is a mock up of a new website front page, and also a possible graphics template for an example per-project "mini-site" in the attached PDF. It could be useful to stimulate some discussion. The other piece of the puzzle is a schema representing all the data/links per project so we can have consistent links to content across the mini-sites. A mock up of this schema looks like this:
Projects Schema:
Project Title
Project Description
Project Documentation
Project Code
Project Mailing List
Project Call to Actions
Project Code Review
Project Useful Links
Any comments ahead of the meeting are welcome.
Regards
Bill
--
[Linaro]<http://www.linaro.org/>
Bill Fletcher | Field Engineering
T: +44 7833 498336<tel:+44+7833+498336>
bill.fletcher(a)linaro.org<mailto:bill.fletcher@linaro.org> | Skype: billfletcher2020
Few comments Arm shared with Linaro already:
- overall new layout/schema looks good.
- not quite sure about the colour distinction for projects (blue/green) on the main page --> maybe best to keep a single colour not to confuse people
- How about adding a Members section down below the main page with all the company logos?
- “Projects available from Trusted Firmware” reads a bit wordy --> suggests “Projects” or “Available Projects”
- “A bi-weekly Technical Forum call is held to discuss technical subjects" --> May be can provide link to Tech Forum page and mention invite available from mailing list?
- TF-A-Test is *probably* not worth a separate project page --> propose to move TF-A-Tests together with TF-A, in the same sub-page. Only TF-A button in the home page, then either 2 sections/tabs: one for TF-A and one for TF-A-Tests. Opinions?
Any other thought anyone??
Thanks
Matteo
From: TSC <tsc-bounces(a)lists.trustedfirmware.org> On Behalf Of Julius Werner via TSC
Sent: 15 May 2020 21:24
To: bill.fletcher(a)linaro.org
Cc: Jonathon Burcham <jon.burcham(a)linaro.org>; Kyle Kirkby <kyle.kirkby(a)linaro.org>; tsc(a)lists.trustedfirmware.org; Stuart Waldron <stuart.waldron(a)linaro.org>
Subject: Re: [TF-TSC] Fwd: Trusted Firmware website redesign - proposed way forward
I think there's an "n" missing in "Hafnium" in your mock.
On Fri, May 15, 2020 at 10:07 AM Bill Fletcher via TSC <tsc(a)lists.trustedfirmware.org<mailto:tsc@lists.trustedfirmware.org>> wrote:
Hi all,
At the previous TF TSC we had an action to work on the TF.org website. Here is a mock up of a new website front page, and also a possible graphics template for an example per-project "mini-site" in the attached PDF. It could be useful to stimulate some discussion. The other piece of the puzzle is a schema representing all the data/links per project so we can have consistent links to content across the mini-sites. A mock up of this schema looks like this:
Projects Schema:
Project Title
Project Description
Project Documentation
Project Code
Project Mailing List
Project Call to Actions
Project Code Review
Project Useful Links
Any comments ahead of the meeting are welcome.
Regards
Bill
--
[Image removed by sender. Linaro]<http://www.linaro.org/>
Bill Fletcher | Field Engineering
T: +44 7833 498336<tel:+44+7833+498336>
bill.fletcher(a)linaro.org<mailto:bill.fletcher@linaro.org> | Skype: billfletcher2020
--
TSC mailing list
TSC(a)lists.trustedfirmware.org<mailto:TSC@lists.trustedfirmware.org>
https://lists.trustedfirmware.org/mailman/listinfo/tsc
I think there's an "n" missing in "Hafnium" in your mock.
On Fri, May 15, 2020 at 10:07 AM Bill Fletcher via TSC <
tsc(a)lists.trustedfirmware.org> wrote:
> Hi all,
>
> At the previous TF TSC we had an action to work on the TF.org website.
> Here is a mock up of a new website front page, and also a possible graphics
> template for an example per-project "mini-site" in the attached PDF. It
> could be useful to stimulate some discussion. The other piece of the puzzle
> is a schema representing all the data/links per project so we can have
> consistent links to content across the mini-sites. A mock up of this schema
> looks like this:
>
> Projects Schema:
>
> Project Title
> Project Description
> Project Documentation
> Project Code
> Project Mailing List
> Project Call to Actions
> Project Code Review
> Project Useful Links
>
> Any comments ahead of the meeting are welcome.
>
> Regards
>
> Bill
>
>
>
> --
>
> [image: Linaro] <http://www.linaro.org/>
> *Bill Fletcher* | *Field Engineering*
> T: +44 7833 498336 <+44+7833+498336>
> bill.fletcher(a)linaro.org | Skype: billfletcher2020
>
> --
> TSC mailing list
> TSC(a)lists.trustedfirmware.org
> https://lists.trustedfirmware.org/mailman/listinfo/tsc
>
Hi all,
At the previous TF TSC we had an action to work on the TF.org website. Here
is a mock up of a new website front page, and also a possible graphics
template for an example per-project "mini-site" in the attached PDF. It
could be useful to stimulate some discussion. The other piece of the puzzle
is a schema representing all the data/links per project so we can have
consistent links to content across the mini-sites. A mock up of this schema
looks like this:
Projects Schema:
Project Title
Project Description
Project Documentation
Project Code
Project Mailing List
Project Call to Actions
Project Code Review
Project Useful Links
Any comments ahead of the meeting are welcome.
Regards
Bill
--
[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 all,
On 5/5/20 9:04 AM, Sandrine Bailleux via TF-A wrote:
> I've received very little feedback on version 2 of the proposal, which
> hints that we are reaching an agreement. Thus, I plan to finalize the
> proposal this week. This can then become part of our development flow
> for all trustedfirmware.org projects.
>
> Thanks again for all the inputs!
The project maintenance process is now live. The document has been moved
here (with a few minor edits to turn it from a proposal to an effective
process):
https://developer.trustedfirmware.org/w/collaboration/project-maintenance-p…
Thanks!
Regards,
Sandrine
Hi all,
I've received very little feedback on version 2 of the proposal, which
hints that we are reaching an agreement. Thus, I plan to finalize the
proposal this week. This can then become part of our development flow
for all trustedfirmware.org projects.
Thanks again for all the inputs!
Regards,
Sandrine Bailleux
Attendees
Ruchika Gupta (NXP)
Andrej Butok (NXP)
Abhishek Pandit (Arm)
Kevin Townsend (Linaro)
Joakim Bech (Linaro)
Christian Daudt (Cypress/Infineon)
Eric FInco (ST)
Julius Werner (Google)
Mark Grosen (TI)
Bill Mills (TI)
David Brown (Linaro)
Bill Fletcher (Linaro Community Projects)
Actions
AbhishekP: Action to follow up on TF hosting released PSA specification
AbhishekP: Action to check with Shebu if the roadmap included 1.0
BillF: Action to storyboard/mock up web page for next TSC
BillF: Action to check how to prepare the support of some member’s boards
in CI and come back to CD/EF
KevinT: Action/semi-volunteering to put some road-signs for helping people
moving from gitHub to gerrit
AbhishekP: Action to put the gerrit/GitHub issue on the agenda for next time
Notes
JB: Some practicalities around:
- Our mailinglists, Bill have created/enabled some already and I have a
discussion with Linux kernel developers regarding mailinglist for TEE
kernel discussions. I can give a 2 minute update on this.
- OP-TEE transition, I've tried to clean-up and redirect everything from
Linaro to TrustedFirmware.org. Yet another 2 minute update.
BF: All lists have been created - see TF.org/contact for all (public ones)
JB: Suggested there should also be a tee mailing list in the kernel.
DB: Vger list?
JB: yes
JB: also cleaned up OP-TEE.org to use new mailing list and mention trusted
firmware where relevant
AP: Maybe we need an ‘all’ mailing list for process, otherwise getting 3
mails every time?
DB: In the kernel people are good at cross posting.
CD: Suggest to wait if there are more of these things and see if we need a
top level list
DB: May be unintended consequences.
AP: Leave it for now
JB: Bill also created op-tee-security list. Need to describe membership/use
DB: Has been done for Zephyr.
JB: Not the same as what was agreed with Dan
JB: Sandrine's maintainer / process proposal, do we want to have a
follow-up discussion?
AP: Was a special TF-A Tech Forum call last week. Has incorporated the
suggestions from the list and forum. Would anyone want us not to formalize
it?
CD: In principle?
AP: Sandrine published the updates she got. Suggest she finalises with each
contributor rather than continuing to blast it to the list.
EF: -Some time ago, you asked for feedback on trustedfirmware.org website
and BillF created a wiki document to capture comments =
https://developer.trustedfirmware.org/w/collaboration/website/ I have
edited it with some comments and proposals.
EF: could have per project logos routing people to mini-sites per project
AP: Initial project landing pages often have member logos.
EF: Dashboard is confusing - not analytics. Also different between TF-A and
TF-M. Docs and wiki - not sure people visiting will understand the
difference.
EF: TF-M Wiki page is good. Could be mini-site entry point.
AP: Was looking at Apache since has multiple projects too
CD: Agree that the slicing is not good at the moment. People typically
coming in for a specific project. First item for each one could be a ‘start
here’ like Eric pointed out for TF-M
DB: Don’t want drop downs need to be clicked on - should just select by
hovering.
AB: The PSA Specification is still under Arm. Also requires registration
and doesn’t inform you if there’s a new version. Could it be moved to
TF.org?
AP: Will check with Arm
BF: Not sure we can host it
CD: It’s a public spec - so could host a copy
AP: release versions could be ok but draft versions may be via a closed
channel
AP: Action to follow up on TF hosting released PSA specification
BF: Action to storyboard/mock up web page for next TSC
EF: Furthermore, last time Dan proposed to discussed the tools used by the
projects (git, gerrit phabricator) and I see a link with the web site
improvement topic so if members of the TSC agree we may start discussing
this in today TSC
AP: Phabricator is becoming an overhead. Would be good if it was more based
on Sphinx/git. But some people do like the wiki.
RG: Any plans to shift op-tee from github to tf.org.
JB: Depends who - for me no.
RG: Expect any change?
DB: Gerrit seems to do better with long patch chains
JB: A lot of new stuff is being added on GitHub.
KT: Burden for new people getting a first patch in using Gerrit
CD: Standard ramp up for a new tool.
DB: But many more people using GitHub
KT: Could do a better job in the documentation (semi-volunteering to put
some road-signs)
AP: Put the gerrit/GitHub issue on the agenda for next time?
EF: As now the budget for the next phase to TF OpenCI has been voted, do we
have an update on the execution plan and further to it how to prepare the
support of some member’s board (Christian and I made raised a question
pointing to it while reviewing Linaro proposal)
BF: Action: will check this explicit step out and come back to CD/EF
AOB:
MG: How was the decision made to say TF-M is at 1.0?
AP: Think it was related to PSA specification.
MG: What’s the criteria for what is a version release?
AP: Action: Will check with Shebu since this would be published as the
roadmap. He joins the board but not the TSC. Think the roadmap included 1.0.
MG: Are we going to have a process for doing a release -
quality/features/bugs/benchmarks. Should be documented and reviewed before
a release.
JB: If nothing else need some kind of checklist so that it’s possible to
include new people’s participation in a release.
MG: Zephyr project has been looking at this quite a bit. Think we should
document a process for getting a release out. As people look at using this
in production.
AP: Cross-TF?
MG: Prefer not to do it 5 times (for each subproject). At least a baseline
common across projects.
JB: This is what exists for the OP-TEE project, we wanted to make some kind
of "checklist" at some point also, to actually check off various items:
https://optee.readthedocs.io/en/latest/general/releases.html#release-proced…
CD: There is the aspect what is the feature set - shebu has been putting it
together but don’t think we have a feature set to discuss/steer. i.e. what
is important. This is orthogonal to the release process checklist. Some
people sidestep this with a periodic release - either it made the release
or it didn’t.
EF: Semantic versioning?
AP: Was discussed but think we stayed with the TF-A versioning.
JB: Op-TEE follows semantic versioning.
AB: Difficulty to use Zoom from NXP. Have asked for an exception. Was
blocked today. Preference is MS Teams.
JB: Issue to find one tool that works for all. MS Teams is only free ‘for
now’.
BF: Hoping to progress on this in the coming days. Already other ongoing
discussions with NXP with respect to other Linaro meetings.
--
[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 Abhishek,
Sorry for the late feedback.
-Some time ago, you asked for feedback on trustedfirmware.org website and BillF created a wiki document to capture comments = https://developer.trustedfirmware.org/w/collaboration/website/ I have edited it with some comments and proposals. Futhermore, last time Dan proposed to discussed the tools used by the projects (git, gerrit phabricator) and I see a link with the web site improvement topic so if members of the TSC agree we may start discussing this in today TSC
-As now the budget for the next phase to TF OpenCI has been voted, do we have an update on the execution plan and further to it how to prepare the support of some member’s board (Christian and I made raised a question pointing to it while reviewing Linaro proposal)
Regards,
Eric Finco
[Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: logo_big5]
Eric FINCO | Tel: +33 (0)2 4402 7154
MDG | Technical Specialist
From: TSC <tsc-bounces(a)lists.trustedfirmware.org> On Behalf Of Joakim Bech via TSC
Sent: mercredi 15 avril 2020 17:25
To: Abhishek Pandit <Abhishek.Pandit(a)arm.com>
Cc: tsc(a)lists.trustedfirmware.org
Subject: Re: [TF-TSC] TSC Agenda 16 Apr 2020
Hi Abhishek,
Some practicalities around:
- Our mailinglists, Bill have created/enabled some already and I have a discussion with Linux kernel developers regarding mailinglist for TEE kernel discussions. I can give a 2 minute update on this.
- OP-TEE transition, I've tried to clean-up and redirect everything from Linaro to TrustedFirmware.org. Yet another 2 minute update.
Sandrine's maintainer / process proposal, do we want to have a follow-up discussion?
Regards,
Joakim
On Wed, 15 Apr 2020 at 17:04, Abhishek Pandit via TSC <tsc(a)lists.trustedfirmware.org<mailto:tsc@lists.trustedfirmware.org>> wrote:
Hi All,
Any agenda items for this week’s meeting?
Thanks,
Abhishek
--
TSC mailing list
TSC(a)lists.trustedfirmware.org<mailto:TSC@lists.trustedfirmware.org>
https://lists.trustedfirmware.org/mailman/listinfo/tsc
Hi Abhishek,
Some practicalities around:
- Our mailinglists, Bill have created/enabled some already and I have a
discussion with Linux kernel developers regarding mailinglist for TEE
kernel discussions. I can give a 2 minute update on this.
- OP-TEE transition, I've tried to clean-up and redirect everything from
Linaro to TrustedFirmware.org. Yet another 2 minute update.
Sandrine's maintainer / process proposal, do we want to have a follow-up
discussion?
Regards,
Joakim
On Wed, 15 Apr 2020 at 17:04, Abhishek Pandit via TSC <
tsc(a)lists.trustedfirmware.org> wrote:
> Hi All,
>
>
>
> Any agenda items for this week’s meeting?
>
>
>
> Thanks,
>
> Abhishek
> --
> TSC mailing list
> TSC(a)lists.trustedfirmware.org
> https://lists.trustedfirmware.org/mailman/listinfo/tsc
>
Hi all,
Thanks to all who have commented on this proposal so far. I've edited
the original document to try and incorporate all feedback gathered so
far (through the TSC meeting, this email thread and the TF-A tech call).
Please have another look and flag anything I might have missed:
https://developer.trustedfirmware.org/w/collaboration/project-maintenance-p…
The major changes are:
== Removed concept of self-review ==
This is proving too controversial, several people do not want to allow
self-review.
Roles of maintainer and code owner are still cumulative but cannot be
both exercised for the same patch.
The exact method of dealing with review bottleneck is still to be
decided. In addition to the current proposal of increasing the
maintainers pool, the most popular alternatives mentioned so far are:
- Set a minimum wait time for feedback before a patch can be merged
without any further delay.
- Mandate distinct reviewers for a patch.
== Enhanced the section "Patch contribution Guidelines" ==
Mentioned that patches should be small, on-topic, with comprehensive
commit messages.
== Added a note about how to deal with disagreement ==
If reviewers cannot find a common ground, the proposal is to call out a
3rd-party maintainer.
== Removed "out-of-date" platform state ==
Squashed it into "limited support" to reduce the number of states.
== Removed "orphan" state from platform support life cycle ==
This concept is orthogonal to the level of functionality.
Added a note in the "Code Owner" section instead.
== Per-project guidelines as a complementary document ==
Added a list of things that it would typically cover.
== Added requirement on fully supported platforms to document the
features they support ==
== Added todo mentioning that the proposal might cover branching
strategies in the future ==
The full diff may be seen here:
https://developer.trustedfirmware.org/phriction/diff/73/?l=4&r=5
This proposal is still open for discussion at this stage and further
feedback is most welcome!
Regards,
Sandrine