- TSC - lists.trustedfirmware.org

Re: [TF-TSC] Avoiding noninclusive language in Trusted Firmware code

by Julius Werner

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

5 years, 4 months

1
0
0 0

Re: [TF-TSC] Avoiding noninclusive language in Trusted Firmware code

by Abhishek Pandit

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

5 years, 4 months

1
0
0 0

TSC Agenda 17 September 2020

by Abhishek Pandit

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

5 years, 4 months

1
0
0 0

Re: [TF-TSC] Avoiding noninclusive language in Trusted Firmware code

by Andrej Butok

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

5 years, 4 months

1
1
0 0

Avoiding noninclusive language in Trusted Firmware code

by Julius Werner

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

5 years, 4 months

1
0
0 0

Trusted Firmware TSC 20th August - Minutes

by Bill Fletcher

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/morello https://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

5 years, 5 months

1
0
0 0

Re: [TF-TSC] Request for TSC agenda topics 2020-08-20

by Bill Fletcher

Here's one slide on the website update Regards Bill On Thu, 20 Aug 2020 at 14:51, Dan Handley via TSC < tsc(a)lists.trustedfirmware.org> wrote: > 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/morello > > https://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 > *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. > > > -- > 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

5 years, 5 months

1
0
0 0

Re: [TF-TSC] Request for TSC agenda topics 2020-08-20

by Dan Handley

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/morello https://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/morello https://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.

5 years, 5 months

1
0
0 0

Request for TSC agenda topics 2020-08-20

by Dan Handley

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.

5 years, 5 months

1
1
0 0

Re: [TF-TSC] Request for TSC agenda topics 2020-08-20

by Joakim Bech

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 >

5 years, 5 months

1
0
0 0

2026

2025

2024

2023

2022

2021

2020

2019

TSC