Dear TSC,
I sent the summary below to the board yesterday and Dan suggested it would
be good to share with the TSC as well.
Let me know if you have any questions. :)
Best regards,
Don
---------- Forwarded message ---------
From: Don Harbin <don.harbin(a)linaro.org>
Date: Wed, 2 Dec 2020 at 16:18
Subject: New Blog posts / website updates FYI
To: <board(a)lists.trustedfirmware.org>
Hi all,
I wanted to make sure you all were aware of some new content on the website
and the Phabricator (wiki). Below are the items of note:
- TF-M 1.2 release blog here:
- https://www.trustedfirmware.org/blog/tfm-v1-2-blog/
- TF-A 2.4 release w/ Secure ELS here:
- https://www.trustedfirmware.org/blog/TF-A-and-Hafnium-v2.4-release/
- You will see the updated TF Member list on the website now including
our newest two members (NXM and OMP - Welcome!).
- https://www.trustedfirmware.org/
- I've had our public meeting calendar integrated into the top of the
meetings page.
- This calendar will improve over time as we get all TF projects
public meetings integrated in. It will also provide a quick way to get
up-to-date dial in info for the meetings (some members have had issues
getting the invites into their corporate email accounts)
- https://www.trustedfirmware.org/meetings/
- Finally, per the last Board meeting, I had an action to provide
Board access to the new Community Development project on Phabricator that
has been proposed. It took me a bit of time to get the content to a place
where it was ready to share; I think it's much closer now. Please take a
look
- Community Development Project Home:
https://developer.trustedfirmware.org/project/profile/24/
- Tasks currently tracking:
https://developer.trustedfirmware.org/maniphest/
- Wiki home page for this with content relevant to submitting and/or
getting involved in TF ecosystem tasks:
https://developer.trustedfirmware.org/w/collaboration/community_development/
NOTE: There were ~5 or so individuals subscribed to the TF Board maillist
that I couldn't map emails to github accounts needed to provide access. So
if you have problems accessing the above, just drop me a note with your
github credentials that you use to log into the phabricator/wiki and I can
add you.
Note also that I gave access to the members of the TSC as requested by Dan
H (again, only for those that I could find github credentials in
phabricator).
Please feel free to send me a note with any questions. We also have the
board meeting Dec 9th, so we can have related discussions at that time as
well (if time allows)
Best regards,
Don
Attendees:
Joakim Bech (Linaro)
Dan Handley (Arm)
Eric Finco (ST)
Abhishek Pandit (Arm)
David Brown (Linaro)
Ashutosh Singh (Arm)
Kevin Townsend (Linaro)
Andrej Butok (NXP)
Dave Cocca (Renesas)
KangKang Shen (FutureWei)
Julius Werner(Google)
Lionel Debieve (ST)
ACTION: AP to propose specific website updates to TSC that incorporates inclusive language text.
ACTION: All to review Joakim's security incident flow diagrams
ACTION: Dan to ask Don about opening up community project items in Phabricator
Minutes:
AP: Light agenda today. Just an update on previous approvals.
AP: Trusted Services project is approved by TSC. There are some pending Arm internal approvals that have nearly completed. Expect to push first patches in the coming week.
AP: Inclusive language proposal is approved by TSC.
AP: Propose to have code of conduct page on website. Could be based on another org's policy. Zephyr looks a good candidate.
AP: Also want to provide a short info about the organization structure on the main website
AP: Inclusive language draft can then be incorporated into those pages.
ACTION: AP to propose specific website updates to TSC that incorporates inclusive language text.
AP: Expectation then will be that project leads will add the text to their own project specific documentation (e.g. coding guidelines).
AP: AOB?
KKS: Was looking for public meeting link for tech forums. Couldn't find them.
AP: We can move the links somewhere more obvious if you want?
KKS: Actually the link in "News & Blogs" is good enough. Just need to get used to the new site.
https://www.trustedfirmware.org/meetings/
JB: We purchased GP test suite a while ago. Since about 3 weeks ago this is now integrated into OP-TEE CI system.
https://optee.readthedocs.io/en/latest/building/gits/optee_test.html#extend…
JB: Have been trying to supplement security incident process with diagrams. Have had early feedback from some (e.g. DH). Now would like to share with TSC for feedback.
https://people.linaro.org/~joakim.bech/tf/
JB: Think this is necessary as the text is quite complex.
https://developer.trustedfirmware.org/w/collaboration/security_center/repor…
DH: Agree. Really useful to show default flow in 1st diagram. Text is complicated due to lots of potential caveats. Each project could show their own specific flow if needed.
DH: Diagrams 2-3 are more linked to the process for security team members so could be added there
https://developer.trustedfirmware.org/w/collaboration/security_center/setup…
AP: Could also write a blog that uses these diagrams and explains the caveats in more detail.
DH/JB: Might need to look at colour scheme before integrating to website
ACTION: All to review Joakim's security incident flow diagrams
AP: 2 other in-progress items: Migration to groups.io and prototyping GitHub/Gerrit integration. Was hoping for update from Don on that.
DH: This and other board/TSC items are captured in Phabricator but visibility is limited at present. We should get those opened up, at least for all board/TSC members
ACTION: Dan to ask Don about opening up community project items in Phabricator
Hi All,
Any agenda items for this week's meeting?
Following are on my list currently
* Inclusive Language guidelines
* Trusted Services project
Thanks
Abhishek
Hi all,
Please find the mInutes from the October 15 TrusteFirmware TSC below.
Best regards,
Don Harbin
TrustedFirmware Community Manager
don.harbin(a)linaro.org
Trusted Firmware TSC 15 October - MinutesAttendees
*Abhishek (Arm)Julian Hall (Arm)Gyorgi Szing (Arm)Dan Handley (Arm)KangKang
(FutureWei)Julius Werner (Google)Joakim Bech (Linaro)David Brown
(Linaro)Don Harbin (Linaro)Andrew Butok (NXP)Dave Cocca (Renesas)Michael
Thomas(Renesas)*Actions:
*Abhishek: Send inclusive language email for voteAbhishek: Check to see if
can share Trusted Service Project use casesAbhishek: Gather vote on Trusted
Services Project request through emailDanH: Talk to Matteo / Shebu about
requirements for continued support of s/w stacks on new h/w (in particular
the 8.4 and beyond). Develop a migration plan.*Minutes:
Trusted Services Project request
-
TSC needs to approve. No budgetary impacts
-
JH: Shared overview slides of Trusted Services Project
-
JH: Ready to re-publish the work. A build system is in place. Tests in
place.
-
Need a public repo
-
Need tf.org front page update
-
Need Mail list
-
CI is a TBD
-
DanH: Plan to go to public CI from the start?
-
Gyorgy - an internal CI first would be easier.
-
DanH: Need to be aware of what upstream CI will require ahead of time
-
DC: How are CI requirements related to other ongoing projects
-
Gyorgy - currently no implementation, would need to do that and implement
-
DC: What about ongoing CI?
-
DanH: Should eventually migrate to TF CI
-
AB: Why not develop as part of TF-A Project?
-
Abhishek: Ideally would migrate TF-A services into this at some point.
-
JH: A stand-alone w/ dependencies makes sense
-
DanH: Within Arm, want to integrate the components in multiple
configurations.
-
Abhishek: Would help if clarify TF-A vs TF-M.
-
JB: Do we have use cases defined on how these will be used
-
JH: For crypto services, yes. Device Identity, Audit Logs, building
blocks to secure an IoT device are some examples.
-
JB: People ready to start using?
-
JH: Yes in the edge space
-
JB: Understanding the use cases on problem solving would be helpful
-
JH: Focus has been on Cortex A use cases
-
Abhishek: Will work to close this vote soon.
Inclusive Language
-
Abhishek: Looks like sufficient support.
-
No budget required, so no formal vote required. Want a vote?
-
DC: Vote here is ok.
-
Don: Destination of wording?
-
JW: Propose into coding style guides
-
Abhishek: Could also be a developer wiki page.
-
I.e. Duplicate in each coding guidelines plus a common section on the
wiki.
-
Maintainers would be asked to add these to the Projects Coding
Guidelines.
-
DanH: Proposing having it in one place and pointing to it.
-
Abhishek: Formalize the decision. Then can decide how to deploy.
-
Don: Where is exact wording?
-
Abhishek: Propose an email vote and the email will include the exact
wording in the email. Also that the maintainer for each project is
responsible to integrate into their coding guidelines
Arm V8 → 8.4 transition
-
JB: Member Companies have expressed concerns about Arm V8 and changes
required to 84.. What should we tell people?
-
DanH: Don’t have to change S/W on 8.4.
-
Abhishek: How does Hafnium leverage it?
-
JB: Don’t want to forget this when making changes. All changes may not
be backward compatible.
-
DanH: Take back to Matteo / Shebu a discussion about a migration plan
-
JB: Impacts to OP TEE components important to this.
<end>
Hello,
FYI:
NXP has just started Inclusive Language Project to review sensitive terms and update terminology in alignment with industry changes:
"After researching industry best practices, we've decided to replace the following words and to discontinue using them in documents.
* Master/Slave -> replace with Leader/Follower, Primary/Replica or Primary/Standby
* Blacklist/Whitelist -> replace with Denylist/Allowlist
Additionally,
* we will discontinue using other terms that are gender-related or discriminating in future materials, including technical, marketing and quality documents.
* we are also updating our NXP Style Guide accordingly."
So, according this new declaration, NXP supports the proposed TF Inclusive Language guideline.
Best regards,
Andrej Butok
From: TSC <tsc-bounces(a)lists.trustedfirmware.org<mailto:tsc-bounces@lists.trustedfirmware.org>> On Behalf Of Abhishek Pandit via TSC
Sent: mardi 13 octobre 2020 15:32
To: tsc(a)lists.trustedfirmware.org<mailto:tsc@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 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).
