Hi,
Slides that I presented in the last TSC meeting attached, happy to answer further questions.
Thanks,
Ashu
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,
Here are the minutes from the TSC call last week. Please let me know any
additions or corrections.
Best regards
Bill
Attendees
AbhishekP - Arm
DavidB - Linaro
MarkG - TI
VickyJ - Linaro
EricF - ST
BillM - TI
ChristianD -Cypress
JoakimB - Linaro
JuliusW - Google
AshutoshS - Arm
Agenda
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
Notes
Pending action items
AP: Any specific input on security reporting. Otherwise please raise with
Dan on email.
JB: Have a few points but will raise by mail.
AP: By mid-July meeting should try to reach Beta level
AP: Coding guidelines patch
EF: Should hopefully be next week
AP: Static analysis and functional safety - please could everyone think
about this. Both TF teams are doing static analysis.
JB: Functional safety came up in BKK19 - MISRA C
AP: TSC Members - some members have not identified.
May need to have invitation-only closed discussions
CD: OP-TEE is going to add an extra row to the matrix of interest
Representative discussion: Proposal generally agreed - 2 reps, expertise
partitioned as member company desired. Ideally designated primary and
secondary, either but not both can vote.
PSA L2 update for TF-M
AS: For v8m, isolation is through hardware. For dual cpu cortex-m each side
has separate interrupts and no leakage of information through interrupts
JB: Not much information in the document 18/19 pages. Interested in 5.6.
What is the list of supported crypto expected.
AS: Has not been listed. Should support the crypto currently used in TF-M
DB: Secure storage TBD?
AS: Crypto shouldn’t allow visibility of the key for secure storage. Have
to close this. Action item later in slides.
JB: Who is ‘The Lab’ in the slides?
AS: 6-7 around the world. Partners have already gone for level 1
certification. Link here:
https://www.psacertified.org/security-certification/test-labs/
EF: Foresee any work on mcuboot?
AS: Have a fork in TF-M. Can’t comment on open source project.
EF: Wondering if TF-M and upstream fork could converge
AP: Could happen. Need to look at what it would take. DavidB discussing
with TF-M team.
JB: Any plans to do (external) security audits
AP: Only in early stages. Who would be interested?
JB, DB
AP: Action: AP will contact JB., DB before next TSC about audits
Documentation hosting on ReadTheDocs.
AP: Agreed to do this. Joakim has demonstrated how to do this. Free option?
JB: Works fine.
AP: Any objection from TSC? Otherwise will raise the request to Linaro
infrastructure to publish from Gerrit.
JB: Ad free - as low as $5. Commercial support is $50-150/month.
JW: Do we need an external service? Can we just run Sphinx? Since already
asking for engineering effort.
DB: Doubt to be able to do it for $5/month
Action Bill to find out about cost of internal Sphinx hosting.
JW: Coreboot is already doing this. (docs.coreboot.org
<https://doc.coreboot.org/>)
DB: Can also look into what Zephyr are doing.
Gerrit hooks to inform specific maintainers of submitted patches.
AP: Just have to update some guidelines
AOB
MG: is there a longer term roadmap for e.g. Level 3?
--
[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 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
