Hi Julius,
> On 13/06/2019, 18:58, "TSC on behalf of Julius Werner via TSC" <tsc-bounces(a)lists.trustedfirmware.org on behalf of tsc(a)lists.trustedfirmware.org> wrote:
>
> As a follow-up to what we just discussed in the meeting, here's how to
> set up email notifications on Gerrit:
>
> 1. Log in to review.trustedfirmware.org
> 2. Click on the little Settings gear on the top right (next to your name)
> 3. Scroll down to Notifications
> 4. Type the repo name (e.g. TF-A/trusted-firmware-a) into the Repo
> field (you have to wait for it to auto-complete and then select it,
> can't just copy&paste the full name in)
> 5. Type a search expression for things to monitor into the field on the right
> 6. Click Add
> 7. Repeat with as many expressions as you want to monitor
> 8. Select checkboxes for the events you want to monitor (e.g. I
> believe "Changes" just sends one email when it is first uploaded,
> "Patches" sends one for every new patch set)
> 9. Click Save Changes
>
> For the search expression I usually use something like
> path:"^plat/common/.*" or
> path:"^drivers/(arm/pl011|console|coreboot|delay_timer|gpio|ti).*" to
> monitor the subdirectories I'm interested in, but any valid Gerrit
> search expression works. You can try out the expression in the normal
> search field to make sure it detects all the changes you intended.
Thanks for the information, that's really useful :) I was aware of
project-specific notifications in general but had never noticed there
was a search filter to customize that further to specific files/directories!
As a number of people have asked about that in the past, I've captured
your instructions on the TF-A wiki here:
https://developer.trustedfirmware.org/w/tf_a/gerrit_notifications/
Regards,
Sandrine
I've heard back from the Zephyr infrastructure folks. It looks like the
Zephyr docs are hosted on an AWS instance. The docs are fetched each night,
and the docs regenerated. So it is automatic, but with possibly a one day
delay.
David
On Thu, Jun 13, 2019 at 9:12 AM Abhishek Pandit via TSC <
tsc(a)lists.trustedfirmware.org> wrote:
> The agenda for today looks like -
>
>
>
> - Pending action items
> - PSA L2 update for TF-M. Ashutosh Singh (Arm) will be joining to
> present.
> - Couple of misc items.
> - Documentation hosting on ReadTheDocs.
> - Gerrit hooks to inform specific maintainers of submitted patches.
> - AOB
>
>
>
> Thanks,
>
> Abhishek
>
>
>
> *From:* Abhishek Pandit
> *Sent:* 11 June 2019 23:13
> *To:* tsc(a)lists.trustedfirmware.org
> *Subject:* TSC Agenda 13 Jun 2019
>
>
>
> Hi All,
>
>
>
> Any agenda items for the next TSC meeting?
>
>
>
> Thanks,
>
> Abhishek
> --
> TSC mailing list
> TSC(a)lists.trustedfirmware.org
> https://lists.trustedfirmware.org/mailman/listinfo/tsc
>
Hi Julius,
On Thu, 13 Jun 2019 at 19:58, Julius Werner via TSC <
tsc(a)lists.trustedfirmware.org> wrote:
> As a follow-up to what we just discussed in the meeting, here's how to
> set up email notifications on Gerrit:
>
> 1. Log in to review.trustedfirmware.org
> 2. Click on the little Settings gear on the top right (next to your name)
> 3. Scroll down to Notifications
> 4. Type the repo name (e.g. TF-A/trusted-firmware-a) into the Repo
> field (you have to wait for it to auto-complete and then select it,
> can't just copy&paste the full name in)
> 5. Type a search expression for things to monitor into the field on the
> right
> 6. Click Add
> 7. Repeat with as many expressions as you want to monitor
> 8. Select checkboxes for the events you want to monitor (e.g. I
> believe "Changes" just sends one email when it is first uploaded,
> "Patches" sends one for every new patch set)
> 9. Click Save Changes
>
> For the search expression I usually use something like
> path:"^plat/common/.*" or
> path:"^drivers/(arm/pl011|console|coreboot|delay_timer|gpio|ti).*" to
> monitor the subdirectories I'm interested in, but any valid Gerrit
> search expression works. You can try out the expression in the normal
> search field to make sure it detects all the changes you intended.
>
> I also inquired about the coreboot documentation setup. They just use
> a cron job to rebuild the documentation in regular intervals, which I
> think would probably suffice for Trusted Firmware as well. (But if we
> really need it the moment the patch is merged, we could probably find
> a way to kick it off from Jenkins as well.)
>
Yes, that's an alternative way of dealing with it and I agree that having
updates
on daily basis is for sure good enough. The thing to strive for is to avoid
the
need for having a person doing the updates manually, so yes, the cron-job
way
of dealing with the docs absolutely works fine.
// Regards
Joakim
>
> coreboot runs the documentation server in a docker instance, the setup
> files for that can be found at
>
> https://review.coreboot.org/cgit/coreboot.git/tree/util/docker/doc.coreboot…
> . If we're also using docker in our infrastructure, we could probably
> almost directly copy those. If not, it's still just one time setup of
> a few pip packages and running make in a cron job.
> --
> TSC mailing list
> TSC(a)lists.trustedfirmware.org
> https://lists.trustedfirmware.org/mailman/listinfo/tsc
>
As a follow-up to what we just discussed in the meeting, here's how to
set up email notifications on Gerrit:
1. Log in to review.trustedfirmware.org
2. Click on the little Settings gear on the top right (next to your name)
3. Scroll down to Notifications
4. Type the repo name (e.g. TF-A/trusted-firmware-a) into the Repo
field (you have to wait for it to auto-complete and then select it,
can't just copy&paste the full name in)
5. Type a search expression for things to monitor into the field on the right
6. Click Add
7. Repeat with as many expressions as you want to monitor
8. Select checkboxes for the events you want to monitor (e.g. I
believe "Changes" just sends one email when it is first uploaded,
"Patches" sends one for every new patch set)
9. Click Save Changes
For the search expression I usually use something like
path:"^plat/common/.*" or
path:"^drivers/(arm/pl011|console|coreboot|delay_timer|gpio|ti).*" to
monitor the subdirectories I'm interested in, but any valid Gerrit
search expression works. You can try out the expression in the normal
search field to make sure it detects all the changes you intended.
I also inquired about the coreboot documentation setup. They just use
a cron job to rebuild the documentation in regular intervals, which I
think would probably suffice for Trusted Firmware as well. (But if we
really need it the moment the patch is merged, we could probably find
a way to kick it off from Jenkins as well.)
coreboot runs the documentation server in a docker instance, the setup
files for that can be found at
https://review.coreboot.org/cgit/coreboot.git/tree/util/docker/doc.coreboot…
. If we're also using docker in our infrastructure, we could probably
almost directly copy those. If not, it's still just one time setup of
a few pip packages and running make in a cron job.
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(a)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.
--
[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 Abhishek & all
Sorry for late input.
I would like to come back to the point I raised in BKK: guidance for coding style application for platform specific code.
The TF-M coding style includes a "##Consistent style "statement that indicates "The code needs to be consistent with itself, so if existing code in the file violates listed coding style rules then it is better to follow existing style in the file and not break consistency by following the rules listed here" , we propose to precise it applies typically for platform specific code and to add a requirement to put platform specific code (e.g HAL code) in a single folder.
To illustrate this in case of a ST STM32 platform:
-STM32 Platform specific HAL code will be in a single folder located under /platform<https://git.trustedfirmware.org/trusted-firmware-m.git/tree/platform>/ext<https://git.trustedfirmware.org/trusted-firmware-m.git/tree/platform/ext>/target<https://git.trustedfirmware.org/trusted-firmware-m.git/tree/platform/ext/ta…>
-Code using the STM32 HAL :
- Is matching the indentation style.
- Function calls to STM32 HAL are CamelCase to fit with STM32 HAL functions
Regards,
Eric Finco
[Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: logo_big5]
Eric FINCO | Tel: +33 (0)2 4402 7154
MDG/MCD | Technical Specialist
From: TSC <tsc-bounces(a)lists.trustedfirmware.org> On Behalf Of Abhishek Pandit via TSC
Sent: jeudi 2 mai 2019 16:39
To: tsc(a)lists.trustedfirmware.org
Cc: nd <nd(a)arm.com>
Subject: [TF-TSC] Next TSC meeting & Agenda
Hi All,
We didn't get to discuss the next meeting slot in our previous meeting but I would like to suggest Thursday 16th May 16:00 UK time. Hope that works.
>From June onwards, we can setup a regular call e.g. on every 2nd Thursday of the month. Let's discuss and finalize in the next call.
Any Agenda items that you would like to add for next meeting?
Thanks,
Abhishek
Hi TF TSC
This is a v0.2 update to the proposed tf.org security incident handling process, which I sent before the last TSC, incorporating comments I've had since then.
Changes since then:
* Clarified use of PGP.
* Clarified how ESSs get included in the process
* Other minor edits.
I've included some comment/rationale in square brackets to aid discussion. All comments welcome.
I've also jotted down the key points in the attached slides, which might be easier to digest. Hopefully we can discuss this more at Thursday TSC meeting.
Regards
Dan.
----
This security incident handling process proposal is broadly based on the kernel process [1], with influence from the existing TF-A [2] and OP-TEE [3] processes.
[DH: Note the contrast with the kernel process: mailto:security@kernel.org is exclusively about fixing the vulnerability; disclosure is delegated to mailto:linux-distros@vs.openwall.org [4]. This proposal combines these activities.]
Reporting
=========
If you think you have found a security vulnerability, then please send an email to the Trusted Firmware security team at mailto:security@trustedfirmware.org. This is a private team of security officers who will help verify the security vulnerability, develop and release a fix, and disclose the vulnerability details responsibly. Please give us time to implement the disclosure plan described in the next section before going public. We do our best to respond and fix any issues as soon as possible.
As with any bug, the more information you provide, the easier it is to diagnose and fix. If you already have a fix, please include it with your report, as that can speed up the process considerably. Any exploit code is very helpful. The security team may bring in extra help from area maintainers to understand and fix the vulnerability. The security team may share any information you provide with trusted third parties and eventually the public unless you request otherwise.
[DH: Note, mailto:security@kernel.org provides stronger confidentiality guarantees because it is only interested in fixes, not disclosure. In practice, I'd expect members of the security team to be sensitive with confidential information as with any other open source interactions, and to get explicit approval from the reporter for disclosure of sensitive information, e.g. identity, organization, product information,...]
You may using this PGP/GPG key [insert link] for encrypting the vulnerability information. This key is also available at http://keyserver.pgp.com and LDAP port 389 of the same server. The fingerprint for this key is:
[Insert Fingerprint]
If you would like replies to be encrypted, please provide your public key. Please note the Trusted Firmware security team cannot guarantee that encrypted information will remain encrypted when shared with trusted third parties.
[DH: Is this acceptable? It allows reporters to use encryption without adding too much admin burden on the security team. The alternative is to force everyone receiving embargoed information to provide an encryption key and decrypt/re-encrypt as information is passed around. I think this adds too much overhead without significant security benefit.]
If the security team consider the bug not to be a security vulnerability, you will be informed and the bug directed to the standard bug fixing process.
Disclosure
==========
The general security vulnerability disclosure plan is as follows:
1. For confirmed security vulnerabilities, develop a robust fix as soon as possible. During this time, information is only shared with the reporter, those needed to develop the fix and Especially Sensitive Stakeholders (ESSes). See the "ESS and Trusted Stakeholder registration" section below for more information about ESSes.
2. After a robust fix becomes available, our preference is to publicly release it as soon as possible. This will automatically happen if the vulnerability is already publicly known. However, release may be deferred if the reporter or an ESS requests it within 1 calendar day of the fix becoming available, and the security team agree the criticality of the vulnerability requires more time. The requested deferral period should be as short as possible and no more than 14 calendar days after the fix becomes available. The only valid reason for this release deferral is to accommodate deployment of the fix by ESSes. If it is immediately clear that ESSes are unaffected by the vulnerability then this stage is skipped. This 0-14 day deferral is the primary embargo period.
[DH: Note, this stage is only relevant for TF-A currently.]
[DH: I removed the nuance between 7 and 14 days used in the kernel process. I don't think it essentially changes the process.]
[DH: Note, this assumes that ESS security teams operate 7 days a week.]
3. After the primary embargo period, the fix and relevant vulnerability information are shared with registered Trusted Stakeholders (see below section). Fix release may be deferred further if a Trusted Stakeholder requests it within 1 working day (Monday to Friday) of being notified, and the security team agree the criticality of the vulnerability requires more time. The requested deferral period should be as short as possible and no more than 14 calendar days after the Trusted Stakeholder receives it. The only valid reason for this further release deferral is to accommodate deployment of the fix by a Trusted Stakeholder. This further 1-14 day deferral is the secondary embargo period.
Note, security fixes contain the minimum information required to fix the bug. The accompanying vulnerability details are disclosed later.
[DH: Note, I've slightly relaxed the Trusted Stakeholder required response time to 1 working day, as oppose to 1 calendar day. Is this reasonable?]
[DH: Note, this aggressive release of security fixes is aligned with the kernel process. The existing TF-A process allows for early release of fixes, which we generally do in practice, but that process doesn't really specify a fix embargo period. However it does specify a 4 week embargo on the subsequent security advisory. Also note that OP-TEE's fix embargo period is 90 days, which is aligned with Google's policy.]
4. After the fix is released, details of the security vulnerability are consolidated into a security advisory. This includes a CVE number and the security team will request one if not already done by the reporter. It also includes credit to the reporter unless they indicate otherwise. Drafts of the security advisory are circulated with the reporter, ESSes and Trusted Stakeholders as they become available.
[DH: Note, the existing TF-A process only shares information with Trusted Stakeholders in the form of security advisories. This proposal is more aligned with the kernel process and means we can focus on fix development by sharing raw vulnerability information in the early stages.]
5. 90 days after the vulnerability was reported, the security advisory is made public at https://www.trustedfirmware.org/. This 90 day window is the public embargo period.
[DH: This public embargo period aligns with Google and OP-TEE processes, although this proposal releases fixes earlier.]
In exceptional cases, the above disclosure plan may be extended in consultation with the reporter, ESSes and Trusted Stakeholders, for example if it is very difficult to develop or deploy a fix, or wider industry consultation is needed.
[DH: I'm accommodating for the Spectre/Meltdown case here]
Handling embargoed information
==============================
On receipt of embargoed information, you must not disclose any of the provided information beyond the group of people in your organization that need to know about it. During the primary and secondary embargo periods, that group of people should be limited to those entrusted to assess the impact of the vulnerability on your organization and deploy fixes to your products. After the secondary embargo period but during the public embargo period, that group of people may be expanded in order to prepare your organization's public response. The embargoed information must not be shared outside your organization during the public embargo period under any circumstances. If you think another individual/organization requires access to the embargoed information, then please ask them to register as a Trusted Stakeholder (see next section). If you believe there has been a leak of embargoed information then please notify the security team immediately.
[DH: This section is stronger than the existing TF-A and OP-TEE processes, but not as strong as the linux distros policy [4]. I hope I've struck the right balance here.]
The security team welcomes feedback on embargoed information at any time.
ESS and Trusted Stakeholder registration
========================================
[DH: This is broadly based on the OP-TEE policy.]
The security team maintains a vetted list of organizations and individuals who are considered ESSes and Trusted Stakeholders of Trusted Firmware security vulnerabilities. Contact <mailto:security@trustedfirmware.org> if you wish to be added to one of the lists, providing the following information:
1. Which list you want to be on. This will almost always be the Trusted Stakeholder list.
2. A justification of why you should be on the list. That is, why you should know about security vulnerabilities and have access to security fixes before they are made public. A valid reason to be on the Trusted Stakeholder list for example, is that you use Trusted Firmware in a deployed product. The ESS list is strictly limited to those organizations with large scale deployments of Trusted Firmware, providing bare-metal access on multi-tenancy systems.
3. An organization email address (not gmail, yahoo or similar addresses). It is preferable for each organization to provide an email alias that you can manage yourselves rather than providing a long list of individual addresses.
4. Confirmation that the individuals in your organization will handle embargoed information responsibly as described in the previous section.
Note, the security team reserves the right to deny registration or revoke membership to the Trusted Stakeholders list, for example if it has concerns about the confidentiality of embargoed information.
[DH: Note, becoming a Trusted Stakeholder in the current TF-A process requires having a valid NDA with Arm and requesting to be added via Arm account management. I propose that Arm send a mail to all existing stakeholders to invite them to register for the new process. Any objections?]
[DH: Note, I expect each TF project to maintain its own ESS/Trusted Stakeholder lists.]
[DH: Note, I've not included severity scoring in this proposal, as I think the only value of a score is helping to determine whether a bug is a security vulnerability or not, which in the end has a subjective element. I'm open to the idea of adding this to the process but I'd prefer it to be optional and aligned with CVSSv3 as used by CVE.]
[1] https://www.kernel.org/doc/html/latest/admin-guide/security-bugs.html
[2] https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/about/docs/secu…
[3] https://optee.readthedocs.io/general/disclosure.html
[4] https://oss-security.openwall.org/wiki/mailing-lists/distros#how-to-use-the…
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.
I'm good with either 16:00 or 17:00.
Thanks,
Christian.
________________________________
From: TSC <tsc-bounces(a)lists.trustedfirmware.org> on behalf of Abhishek Pandit via TSC <tsc(a)lists.trustedfirmware.org>
Sent: Wednesday, May 8, 2019 3:08 AM
To: Julius Werner; tsc(a)lists.trustedfirmware.org
Cc: nd
Subject: Re: [TF-TSC] Next TSC meeting & Agenda
I am okay with 17:00 but let's wait another day. If we don't hear any other preference for time then we can schedule at 17:00.
Thanks,
Abhishek
-----Original Message-----
From: Julius Werner <jwerner(a)google.com>
Sent: 02 May 2019 21:00
To: Abhishek Pandit <Abhishek.Pandit(a)arm.com>
Cc: tsc(a)lists.trustedfirmware.org; nd <nd(a)arm.com>
Subject: Re: [TF-TSC] Next TSC meeting & Agenda
> We didn’t get to discuss the next meeting slot in our previous meeting but I would like to suggest Thursday 16th May 16:00 UK time. Hope that works.
Any chance we could keep this at 17:00 like the previous calls?
Otherwise it becomes really early in California.
--
TSC mailing list
TSC(a)lists.trustedfirmware.org
https://lists.trustedfirmware.org/mailman/listinfo/tsc
This message and any attachments may contain confidential information from Cypress or its subsidiaries. If it has been received in error, please advise the sender and immediately delete this message.
> We didn’t get to discuss the next meeting slot in our previous meeting but I would like to suggest Thursday 16th May 16:00 UK time. Hope that works.
Any chance we could keep this at 17:00 like the previous calls?
Otherwise it becomes really early in California.
