September 2020 - TSC - lists.trustedfirmware.org

Trusted Firmware TSC 17th September - Minutes

by Bill Fletcher

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

3 years, 6 months

1
0
0 0

Linaro Connect Sessions of Interest

by Don Harbin

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

3 years, 6 months

1
0
0 0

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

by Julius Werner

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

3 years, 7 months

1
0
0 0

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.

3 years, 7 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

3 years, 7 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

3 years, 7 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

3 years, 7 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

3 years, 7 months

1
0
0 0

2024

2023

2022

2021

2020

2019

TSC September 2020