- 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

4 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

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

4 years, 6 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.

4 years, 6 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

4 years, 6 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

4 years, 6 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

4 years, 6 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

4 years, 6 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

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

4 years, 7 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

TSC