Attendees:
Dan Handley (Arm)
Ashutosh Singh (Arm)
Lionel Debieve (ST)
Julius Werner (Google)
Andrej Butok (NXP)
David Brown (Linaro)
Joakim Bech (Linaro)
Roman Baker (Cypress)
Mark Grosen (TI)
Abhishek Pandit (Arm)
Notes:
>Standard HW requirement for TF-M for PSA levels.
LD - Raising the topic based on Eric's email.
AP - As we have limited details possibly better to discuss next time when Eric joins.
May be TF-M tech forum comes up with proposal for TSC to ratify.
>Security Incident process update
AS - Logistics in place. Testing public and private keys. Process document on phabricator, about to open it and redirect website to point to it. Sub teams are ready to switch to new process.
AP - Does TSC come under Trusted stakeholder list?
DH - Member company's security teams may register as Trusted Stakeholders but not the TSC as a whole. As explained in the process, after the secondary embargo period but during the public embargo period, the embargoed information may be shared with others in the Trusted Stakeholders' organization. This would be the appropriate time to notify the TSC.
>Update on GP test suite.
JB - TF.org has purchased the GlobalPlatform test suite as agreed on a board vote earlier this year. Linaro will track enablement of the GP test suite in LOC-67 (https://projects.linaro.org/browse/LOC-67). End goal is to run both xtest and GP test automatically on every single patch sent to the OP-TEE project.
>Website improvement
AP - Offline update from Bill. Cost has been approved by board with a show of hands, and the attached slide contain the details of current status.
>Pending item / Coding standard
AP - TF-M coding conventions and industry standards related discussion.
MG - Coding standard should be influenced by industry standards that we want to target.
We should also discuss compiler support.
AP - Currently gcc, armclang and iar are supported. We need inputs from committee members.
LD - Coding convention, is there desire to have fully aligned conventions across projects?
JB - OPTEE follows Kernel
AP - Depends on the spec that we target but otherwise teams can decide.
AOB?
Hi all
The new TrustedFirmware.org security incident process is now live. This process is described here:
https://developer.trustedfirmware.org/w/collaboration/security_center/repor…
Initially the process will be used for the following projects: TF-A, TF-M, OP-TEE and Mbed TLS. The security documentation for each project will be updated soon to reflect this change.
If you are part of an organization that believes it should receive security vulnerability information before it is made public then please ask your relevant colleagues to register as Trusted Stakeholders as described here:
https://developer.trustedfirmware.org/w/collaboration/security_center/trust…
Note we prefer individuals in each organization to coordinate their registration requests with each other and to provide us with an email alias managed by your organization instead of us managing a long list of individual addresses.
Best regards
Dan.
(on behalf of the TrustedFirmware.org security team)
Hi Abhishek,
I would like to propose to discuss in the TSC the topic raised by ST during a TF-M open forum session and that I bring also in the TSC via the mailing list (see thread attached)
Unfortunately, I have a conflict between the TF TSC meeting tomorrow and another meeting that I cannot escape. Lionel will participate and represent ST also for TF-M topic.
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 | Technical Specialist
From: TSC <tsc-bounces(a)lists.trustedfirmware.org> On Behalf Of Abhishek Pandit via TSC
Sent: mardi 16 juin 2020 15:28
To: tsc(a)lists.trustedfirmware.org
Subject: [TF-TSC] TSC Agenda 18 Jun 2020
Hi All,
Any agenda items for the TSC meeting this week?
Thanks,
Abhishek
Hi Joanna,
> FYI I've moved the TF-A tech forum back an hour to biweekly Thursday 4-5pm UK time that I think allows the TSC to keep its current setup. TF-A and TF-M are on alternate weeks so folks should be able I hope to go to all three with no clashes. Next TF-A tech forum is this Thursday 18th June.
Thanks, for the heads up! I forgot that my calendar doesn't
auto-update for this one. Unfortunately that makes it very early for
US west coast but I guess that's what I get for rocking the boat. ;)
FYI I've moved the TF-A tech forum back an hour to biweekly Thursday 4-5pm UK time that I think allows the TSC to keep its current setup. TF-A and TF-M are on alternate weeks so folks should be able I hope to go to all three with no clashes. Next TF-A tech forum is this Thursday 18th June.
Hope this helps.
Joanna
On 16/06/2020, 23:00, "TSC on behalf of Julius Werner via TSC" <tsc-bounces(a)lists.trustedfirmware.org on behalf of tsc(a)lists.trustedfirmware.org> wrote:
Hi Abhishek,
I think in the last meeting I asked about trying to avoid the conflict
between the TSC meeting and the TF-A Tech Forum. Have you explored
further options in that regard?Maybe moving the TSC to a different
day... for example, the Board also moved its meetings from Thursday to
Wednesday now. Or we could shift it one week out and then make sure we
always keep either 4 or 6 weeks between meetings (still "monthly" on
average but with slightly irregular cadence).
Thanks,
Julius
--
TSC mailing list
TSC(a)lists.trustedfirmware.org
https://lists.trustedfirmware.org/mailman/listinfo/tsc
Hi Abhishek,
I think in the last meeting I asked about trying to avoid the conflict
between the TSC meeting and the TF-A Tech Forum. Have you explored
further options in that regard?Maybe moving the TSC to a different
day... for example, the Board also moved its meetings from Thursday to
Wednesday now. Or we could shift it one week out and then make sure we
always keep either 4 or 6 weeks between meetings (still "monthly" on
average but with slightly irregular cadence).
Thanks,
Julius
Hi Eric,
On Thu, 28 May 2020 at 08:50, Eric FINCO via TSC <
tsc(a)lists.trustedfirmware.org> wrote:
> Hi TF-TSC folks,
>
>
>
> I was on vacation last week so not able to join the TSC last week.
>
> ST raised a question during the TF-M open forum today concerning the min
> number of MPU descriptors (= min mumber of regions) to be supported in the
> SoC especially for of level 3 isolation support.
>
> Furthermore, putting it in perspective with the “measurement” API
> introduced in the HAL proposal presented in the open forum, one can extend
> the question: Do you think the TF-M TSC shall issue some recommendation for
> the minimal Hw configuration required for different features ?
>
This is something that the TSC should be able to do, but I wonder whether
this isn't already covered in various specifications etc created by Arm the
last couple of years. I'm thinking about for example TBSA-M that is part of
PSA. If MPU descriptors aren't already mentioned, then we could ask to get
it added.
> Somehow, small profile memory footprint is also pointing in the direction.
>
> There was a positive feedback from Ken (Liu) during the open forum slot
> but it could make sense to have the TSC reviewing and approving such thing.
> What do you think ?
>
>
>
> Regards,
>
>
>
> Eric Finco
>
Regards,
Joakim
Hi TF-TSC folks,
I was on vacation last week so not able to join the TSC last week.
ST raised a question during the TF-M open forum today concerning the min number of MPU descriptors (= min mumber of regions) to be supported in the SoC especially for of level 3 isolation support.
Furthermore, putting it in perspective with the "measurement" API introduced in the HAL proposal presented in the open forum, one can extend the question: Do you think the TF-M TSC shall issue some recommendation for the minimal Hw configuration required for different features ? Somehow, small profile memory footprint is also pointing in the direction.
There was a positive feedback from Ken (Liu) during the open forum slot but it could make sense to have the TSC reviewing and approving such thing. What do you think ?
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 | Technical Specialist
STMicroelectronics SA
9-11 rue Pierre-Felix Delarue | 72100 Le Mans | France
ST online: www.st.com<http://www.st.com/> | Follow us on twitter: @st_world<http://twitter.com/#!/ST_World>
This communication is confidential and intended solely for the addressee(s). If you are not the intended
recipient, you should not review, retain, copy or distribute the e-mail itself or the information it contains.
In such case, we kindly request you notify the sender by replying to this transmission and delete the
message without disclosing it. Thank you!
P Please consider the environment before printing this e-mail
Attendees
Ruchika Gupta (NXP)
Abhishek Pandit (Arm)
Ashutosh Singh (Arm)
Matteo Carlini (Arm)
Kevin Townsend (Linaro)
Dan Handley (Arm)
Julius Werner (Google)
Mark Grosen (TI)
Bill Mills (TI)
David Brown (Linaro)
Kangkang Shen (Futurewei)
Bill Fletcher (Linaro Community Projects)
Andrej Butok (NXP)
Agenda/Minutes
Website feedback
AP: Feedback from Arm folks - to be sent separately:
scrolling status.
Adding a footer per project.
Structuring the project information differently
TF-A workshop
MC: Possible engagement from members in the workshop e.g.
presentations/keynote
platform ports,
war stories,
project format & contributions,
user stories,
new features,
community development thoughts
KS: Everyone doesn’t attend everything at the same time. Also a panel
discussion could be interesting since more efficient in attendee time. Make
sessions available offline and allow people to contribute afterwards.
MC: Will feed these ideas to the Board
MC: The event format and size will depend on the range of contributions -
‘Arm show’ vs 7 or more companies participating. Not expecting to explore a
public CFP until we’ve explored the membership interest.
KS: Would like to see some discussion about secure variables.
Security incident handling
AS: Top-level mailing list and then a mailing list per project. Membership
of these lists is tightly controlled. Keep the disclosure limited. To allow
conversations to be encrypted we’re setting up PKI.
DH: Correct - we don’t insist on encryption
DB: Management of private keys needs to be spelled out. Once someone has
the private key, they always have it.
AS: Sub mailing lists can’t decrypt the top level mailing list. We need to
have a key revocation mechanism in place (not yet completely defined). Will
need to generate a key pair and have a signing ceremony. Is there a place
to host keys?
DB: Generally the assumption is that private keys are held by individuals.
AS: For the time being will keep it as a manual process unless someone has
a better suggestion.
DB: Will forward link to Stack Overflow page with expected way of doing
things.
AP: Is there a pre-existing guide?
AS: Is quite straightforward. Will be a short guide.
DB: Email client support?
DH: There is an Outlook plug in
AP: Dan sent out mail with process. Can we put it as a proposal on
Phabricator so that don’t need to find it in the email archive.
AS: Yes, will do this and then all the projects can link to Phabricator.
AP: Lack of top level reporting in tf.org is becoming a problem so we can
answer ‘yes’ to outside questions
DB: Think having multiple keys is going to be burdensome. Based on
experience in Zephyr and mcuboot, no one wants to work with PGP.
DH: If allow responses to be to individuals, only need top level key. Don’t
know if it’s acceptable to expose individuals
AP: Suggest offline discussion between Ashu, David and Dan
Forums
AB: Very difficult to follow historic email topics or reproduce a tree of
answers. Can’t check if something was asked previously.
AP: David provided a suggestion for groups.io
DB: Works ok for Zephyr project
DH: Orthogonal to having Slack, but needs some kind of instant messaging
BM: Yocto switched from mailman to groups.io. Think most people don’t know
there’s a forum.
DB: Does the best job of replacing a mail list server - just adds the
functionality of a forum.
BM: Helps an occasional person who doesn’t want to subscribe to do a better
job. Acceptable model for casual users.
AP: Where do archives live?
DB: On groups.io. The Linux Foundation (hosts Zephyr) is finding that it’s
easier to get groups.io to deal with spam.
AP: Suggest the someone could do a proof of concept and demo.
DH: Someone would need to administer it.
DB: 3 tiers of commercial terms. Would need to pay
BF: To talk to Linaro IT about any info on groups.io
AP: Interested to get feedback, thoughts from others. Don’t want to move to
this tool and find out it’s not what people want.
Coding Guidelines
AP: Need to follow up and send nominations of people. Need a couple more
people to make it sustainable.
AOB
JW: Can we avoid scheduling conflict with TF-A Tech Forum?
Action: Abhishek
DH: Threat models. Legal request going through Arm to relicense these under
creative commons.
--
[image: Linaro] <http://www.linaro.org/>
*Bill Fletcher* | *Field Engineering*
T: +44 7833 498336 <+44+7833+498336>
bill.fletcher(a)linaro.org | Skype: billfletcher2020
