> 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
>
