Agenda

Binary Policy Security Incident handling Guidance for coding style application for platform specific code. OP-TEE update

Notes

Binary Policy Went through Gerrit review process. Some wording and structural changes. Has been applied to new TF binaries repository. Also an update to the TF-A contribution guidelines. Other projects can update their contribution guidelines if they need this process in future.. Should we have a statement saying that we welcome binary contributions? Not really ‘welcome’ - it’s a fall-back option. Expect most of the contributions to be open source and this is the exceptional process. Security Incident handling (sharing slides). Align with kernel process. List of sensitive stakeholders - is it fixed? What are the criteria? Have another slide that covers in a bit more detail. 90-day process is manual. Don’t have a policy to automate it. Only a small number of advisories to manage. Also depends when you start the countdown. Had a situation where we got a file and then a meeting 2 weeks later. Countdown starts from receipt of the report. Can also be changed in exceptional circumstances but this is the default case. Same for HW (SW fix) and SW vulnerabilities Yes. Also may need to comment when TF is not impacted by a vulnerability. Would not wait 90 days. Action: DH look for 90 day period automation (doesn’t gate the process) Doesn’t Zephyr use JIRA to track vulnerabilities? Believe they were using private JIRA. Propose to send mail to migrate people from the old to the new process. Can you give an example of companies that might be on the list? AWS, MS Azure, Google Embargo request deadline is 1 working day from being informed. For us it’s very difficult to roll out fixes and keep them embargoed. Are these negotiable and leave the exceptional cases for longer embargo. Could tighten the language. Want to pull in the default period. Go back to the kernel wording - 7 days except in exceptional circumstances. Afraid that if the default is 14 days and we will give it every time. How to distinguish At least decision is on our end. If only 1 day to respond, people may be conservative and ask for the maximum. Still at the discretion of the security team. Could make them work for the embargo - ask for a report every day. Potentially default 7 and then company needs to come back after that. Agreed better not to encourage a longer embargo. Will check internally and re-insert kernel-type wording in next version. Encryption has been optional for us. Some use it, some not. Still have concern about 90 days on the first slide. Why is it 90 days and how much can we say before it is up. Could release a shortened advisory immediately and a full description after 90 days. Hard to say what the boundaries are between the shortened and the full. An informed partner should be able to infer the implications for a fix. Shouldn’t need to spell it out publicly. Can we change wording so that trusted partners are allowed to say there is a security issue without saying what it is. Action DH to clarify what can be said before the 90 days.

Guidance for coding style application for platform specific code. How to manage upstreaming ST platform and the proposed coding style. Coding styles are quite pragmatic. To avoid ambiguiity, should detail that it applies for platform-specific code and limit the platform code to a single folder. Can someone from ST make a patch? Someone from ST is in discussion with the TF-M team. Any objections?

OP-TEE update Feel free to send email directly to joakim.bech@linaro.org.

AOB TSC public mailing list members - this is a closed meeting. No specified list of TSC representatives. Would like to get a list of specified reps. Feel important for voting. Suggest primary & secondary but also scope because people will also be assigned TF-M or TF-A (and possibly OP-TEE). Add that request in the ask for the emails.

Meetings cadence: second Thursday at 1600 UTC. Next meeting will be 16th June.