Hi TF TSC
This is a v0.5 update to the proposed tf.org security incident handling process, which I sent previously.
Changes:
* Expanded the Trusted Stakeholder embargo request period to 3 working days (in their timezone).
* Expanded the ESS definition to include suppliers to ESSes (e.g. distros).
* Allowed projects to optionally use severity scoring (CVSSv3 preferred but not mandated).
* Allowed for flexibility in disclosure plan to accommodate reporter's disclosure plan.
* Allowed for the fact that some projects cannot deliver vulnerability fixes to a restricted audience for export control reasons.
I've also included an internal facing process for the first time, mainly aimed at members of the security team(s) so they know how to execute the process.
I propose the next steps are:
* Discuss the latest changes in the 20th Feb TSC meeting.
* Set a date for approval of the external process (e.g. mid-March).
* Identify the right people to be on the security teams.
* Work with tf.org infra people and each project's security teams to propose a plan for when this process can be made active. Should we try to make this active for all projects at the same time or as each project is ready?
Regards
Dan.
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
Hi All,
Any agenda items for the TSC meeting this week?
There are some ongoing discussions from previous meetings which we can cover anyway.
Thanks,
Abhishek
Hi All,
In previous TSC meeting, we discussed the topic of reviewing the trustedfirmware.org website in terms of contents and structure. You can find some of the comments in the TSC meeting minutes. I took an action to kick off an email thread so that we can capture all the inputs in one place.
Can you please reply to this thread if you have any improvements suggestions?
Thanks,
Abhishek
Attendees
Abhishek Pandit (Arm)
Dan Handley (Arm)
David Brown (Linaro)
Kevin Townsend (Linaro)
Joakim Bech (Linaro)
Eric FInco (ST)
Julius Werner (Google)
Kangkang (Futurewei)
Bill Fletcher (Linaro Community Projects)
notes
AP: Reduce number of pending items.
Coding standard.
Decided we could have a couple of experienced SW guys in charge of
resolving any conflicts. Looking for a few volunteers who would clarify
(for TF-M) the standard.
EF: Timescale for closing this?
AP: No specific timeline but feel just need a small group who have the
judgement. They need prior experience with larger projects. Can send out an
email after to close nominations. Also have action to close coding
standards for platform (raised by ST).
EF: Will discuss with Michel - believe ST can contribute something here.
Maintainers
AP: Had long discussion last time for both TF-M and TF-A. How would people
prefer to close this topic? Otherwise ask one of the TF-A and TF-M
engineers from Arm to make a mailing list from a patch. Based on Dan’s
comment.
Security incident response process
DH: Stalling due to my time and discussion about Mbed TLS and Crypto
projects moving into the project. Can’t deliver patches to a small audience
for export control reasons. Still can have some sort of embargo on
reporting issue. Fix has to be available to anyone. Want them to decouple
fix from advisory. This is aligned to the link from JB - Google Project
Zero.
AP: First draft for open review - end of Jan?
DH: Have a draft ready now. Should be able to send it next week.
AP: Need to inform internal people at the same time.
DH: More of a problem at the moment for TF-M that doesn’t have a process.
OP-TEE etc should continue to follow their own process.
Regional differences for Crypto
KK: Example of TPM - TPM 2.0 allowed regional differences. Previous TPM was
banned in China. Should have an architecture that allows crypto
implementation to plug in.
DH: Hope that PSA crypto interface is suitable for anyone, even if the
underlying implementations are not. Generally should not have export
control issue. May be relying on feedback from Futurewei and other
contributors to say what is permissable in China.
KK: Suggest to review with Arm China.
DH: Need to improve the process before start on any feature improvements.
Provisioning
KT: Did not meet yet. Can put together an RFC by the end of the month.
DB: seeing a conflict between the academic view - X.509 too heavy vs Data
I/O saying everyone uses it even in the smallest devices. See what feedback
we get.
AP: Potentially raise it as a voting point, but have an open RFC discussion
first.
Trusted Firmware Website
AP: Have you browsed through the project website? See if there’s a need for
improvement. Main home page doesn’t have much information. A lot of the
material is via indirection (links?). TF-M needs more documentation. Also
people can’t find things on Phabricator.
JB: Always thought the font sizes are too big on all the project websites
that Linaro is creating. Have a problem with page layout
https://www.op-tee.org/security-advisories/
DB: Feel navigation text is too small and body text is too large.
JB: On OP-TEE website we got rid of a lot of information and just pointed
to readthedocs.
BF: Also have a staging website staging.trustedfirmware.org
AP: think first need some people to do some analysis first.
DB: Left hand navigation would be easier than dropdowns with 2 or 3 items.
KT: Think the documentation for TF-M has improved over the past couple of
months.
AP: Can find the docs via the dropdown. Discussing with Shebu, feel the
experience for getting started can be improved.
KT: People just want to know the git clone and CMake commands.
DB: There’s navigation of the sections of the doc, and there’s navigation
of the website. These are two different things.
KT: Have to click on user guide from getting started.
DB: Realise have to click on each level of the dropdown - make them just
mouse-over.
BF: Happy to collate data from a mailing list.
AP: Shall we share a document? On Phabricator there is a Q&A page. Anyone
object to mailing list? No.
Action on Abhishek to kick off the thread
Next meeting 20th Feb
--
[image: Linaro] <http://www.linaro.org/>
*Bill Fletcher* | *Field Engineering*
T: +44 7833 498336 <+44+7833+498336>
bill.fletcher(a)linaro.org | Skype: billfletcher2020
Thanks for forwarding, Joakim. I'm happy to say this seems aligned with my proposed TF disclosure policy (e.g. encourage a high quality fix ASAP but disclose after 90 days).
Regarding the status of the TF disclosure policy, I'm still making changes to this in the light of new information, e.g.
* The disclosure timeline is largely controlled by the reporter so we need some acknowledgement of that.
* In some cases it may not be possible to release a fix to a restricted audience for export control reasons. Although the incident can be discussed among a restricted audience, the fix may have to be issued publicly.
I can elaborate on this at the next TSC if needed.
Regards
Dan.
From: TSC <tsc-bounces(a)lists.trustedfirmware.org> On Behalf Of Joakim Bech via TSC
Sent: 07 January 2020 17:44
To: tsc(a)lists.trustedfirmware.org
Subject: [TF-TSC] Project Zero disclosure policy updates
Hi,
I thought this was interesting enough to share it with you guys, especially since we've had this up for discussion a couple of times.
https://googleprojectzero.blogspot.com/2020/01/policy-and-disclosure-2020-e…
Regards,
Joakim
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
Hi all,
Here are the minutes for yesterday's TSC call. Please could you share any
slides or other docs presented during the meeting to the list. Also, I was
not able to capture the links posted into the Zoom chat. Please could you
add them to the thread.
Attendees
Abhishek Pandit (Arm)
Christian Daudt (Cypress)
Dan Handley (Arm)
David Brown (Linaro)
Kevin Townsend (Linaro)
Joakim Bech (Linaro)
Mark Grosen (TI)
Bill Mills (TI)
Eric FInco (ST)
Lionel Debieve (ST)
Julius Werner (Google)
Bill Fletcher (Linaro Community Projects)
Notes
AP: Let’s start the maintainers topic.
(Christian Sharing slides)
CD : Dan described what TF-A does and We can just go with TF-A option!
CD, DB: There is different format to Kernel and github format
DB: No parseability with file names. Should we just fix that?
CD: See that people have merged things on TF-A where the maintainers list
has not kept up
DB: Could gerrit be updated from the maintainers file?
DH: Don’t know what happened in the transition to git that adds people to
reviews
CD: In TF-A gerrit reviews, people who merged the code in are not listed in
the maintainers file.
DH: That’s not good.
CD: No tooling to enforce any of this.
DH: Will take an action to fix this.Not clear how to trigger a gerrit
change based on this list.
CD: Make sure that in TF-M something reads the list of +2ers and compares
JW: Do we want to enforce touching every file? Could slow a lot down.
Already have a problem with patches sitting around for too long.
DB: That’s the difference with the GitHub rules - picks just one. With
kernel rules - you get everyone.
CD: When 3 people listed as maintainers for a file, means just one of them
has to approve it.
DB: If touch 5 files, does mean many maintainers involved.
DH: Yes but not enforced
CD: There are maintainers who oversee the whole tree.
JW: Don’t think we need to enforce - force every maintainers to look at
everything.
CD: But why is that person a maintainer.
DH: Maintainers choose when a patch has had enough reviews. Don’t have to
do all the reviewing themselves.
CD: Makes it hard when someone’s submitting a patch. Who decides to wait on
a given maintainers?
JW: Do it by time. If maintainer doesn’t respond in a few days and it
doesn’t break anyting, put it in.
JB: Is this really a big problem? It’s not a big project. Everyone knows
everyone.
CD: Agree let’s not overdo it. What agreement can we reach?
AP: Format seems agreeable to most. Can check with the team what they are
doing. Can come back if there’s already a solution in the works.
CD: Expect TFM to grow to something like TFA. 30-50 reviewers listed. Let’s
set how TFM evolves now.
AP: Take an action item to check what’s going on.
Coding Guidelnes
(Mark G Sharing spreadsheet)
AP: Seems we need access to the standards that Mark is talking about. Most
should have access to MISRA.
DB: It’s $15
MG: Most people should get access to MISRA C. 3 sources: Cert, JPL, MISRA.
DB: This is a spreadsheet on Zephyr. Not implemented yet.
MG: Variety of tools. TI using Clockwork.
DH: We did a years worth of work trying to improve MISRA compliance.
MG: If there’s a goal in mid to achieve compliance with an existing
standard. A lot of overlap between MISRA and other areas.
AP: Suggestion from Reinhard Keil is to stick just to MISRA. Need to nail
it down. If do more than MISRA will spend more time. Need to put somerthing
in place reasonably soon.
DH: TFA treated MISRA as a quality improvement exercise. Big cost to commit
to ongoing MISRA compliance. TFA is used in automotive. Have’nt made a
statemeent.
MG: With MISRA most important is to document what you’re doing. Can write
waivers and deviations.
DH: Get to where you want to and then maintain it at this point. Quite
expensive. Tools are also expensive.
MG: Can we add these rules to the Clang sanitizer? Then have an open source
tool. Talked to TI team. Don’t understand the legalities about how it would
be publishable.
DH: TFA spreadsheet is available on public link.
JB: Look where do we intend to use this code more than automotive.
DH: Probably a never ending set of standards. Should start with all the
opensource static analysers we can get. A lot is about undefined C
behaviour.
EF: Even outside automotiv, MISRA is being used. Agree we should find
something where tooling is available.
CD: More of a wish list than a hard requirement. Follow path of least
resistance. What can we do with open source tools? Then need a specific
requirement to go further.
AP: This all started with rules about e.g. weak symbols. Dan gave some
advice on this. Maybe we define one or two champions of coding standards
and if there’s a conflict then they can step in and resolve it. We need a
mechanism.
CD: OK with that. Don’t want to go down any rabbit holes.
AP: Anyone want to volunteer (now or later)
Provisioning
KT: Discussion in the Provisioning call centred around X.509 certificates.
What would it take to get support into TF-M. Have put together some quick
thoughts (and scripts)
DB: Examples with defaults don’t generate valid certificates
KT: Initial attestation service - want it to be a certificate chain. What
are some of the missing requirements on TFM To enable that workflow?
DB: Met with standards folks at Arm (Hannes, Brendan, +1). Also had a
presentation from DataI I/O. Have started some implementation in mcuboot.
Guessing it’s a bit heavyweight. Additional work to do.
EF: The standard is for attestation tokens
DB: RATS Working Group - EAT(S)
KT: Several problems in supporting certificates. Have secure storage as an
idea but should add some more plumbing for multiple private keys on secure
side.
DB: Will also need update mechanism. Expiring certificates - CSRs will
happen. Not just initial provisioning. Wonder what people are using for the
Subject field.
Build Environment
AP: cmd.exe is installed everywhere, or an alternative is some Zephyr
mechanism.
MG: Not sure would hold up Zephyr as a good Windows build example. CMake is
only part of the problem.
DB: There’s a lot of Python code in Zephyr for the build process.
BM: Is there an open source project that would be a better model?
MG: No good model.
AP: Suggest just pick a method that works for a good number of users. TFM
guys are going to update the documentation.
DB: Amazon FreeRTOS supports the expected IDE for whatever platform you are
building it for. Annoying if you want to work on multiple platforms.
IDEs
DB: Need the flow to be in the right direction. Not having the IDE driving.
AP: We agreed we need to create some separate repo (CMSIS PAK etc). Will
put on the agenda for January.
--
[image: Linaro] <http://www.linaro.org/>
*Bill Fletcher* | *Field Engineering*
T: +44 7833 498336 <+44+7833+498336>
bill.fletcher(a)linaro.org | Skype: billfletcher2020
Hi Christian,
On 12/12/19 4:35 PM, Christian Daudt via TSC wrote:
> On a separate topic, I'm looking through the TF-A recent merges, and it
> seems that code makes it in 'master' without being merged through gerrit
> (e.g. I can only find a merge into 'integration' in gerrit for the
> lastest commit in
> 'master': https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/commit/?id=ebff…https://review.trustedfirmware.org/q/I46b21573ed25a0ff222eac340e1e1fb93b040…).
> Did I miss it or is the flow different than submitting to master in
> gerrit for inclusion into TF-A?
That's right. In TF-A, once a patch has been reviewed,
1. We first merge it into the integration branch through Gerrit.
2. Then the integration branch goes through some more automated testing
overnight.
3. If no major problems are raised, we catch up the master branch with
the integration branch. Right now, we do that manually from command
line, i.e. not through Gerrit.
This process is described here:
https://trustedfirmware-a.readthedocs.io/en/latest/process/contributing.htm…
I hope that helps.
Regards,
Sandrine
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
For the agenda so far:
* Adding maintainers and merge rights in TF-M
* Coding guidelines
* Update from the provisioning discussion
Thanks,
Abhishek
From: TSC <tsc-bounces(a)lists.trustedfirmware.org> On Behalf Of Abhishek Pandit via TSC
Sent: 09 December 2019 16:56
To: tsc(a)lists.trustedfirmware.org
Subject: [TF-TSC] TSC Agenda 12 Dec 2019
Hi All,
Any topics for this week's meeting?
Thanks,
Abhishek
