Hi All,
The next TF-A Tech Forum is scheduled for Thu 16th July 2020 16:00 – 17:00 (BST). A reoccurring meeting invite has been sent out to the subscribers of this TF-A mailing list. If you don’t have this please let me know.
Agenda:
* Secure EL2 SPM (Secure Partition Manager) Hafnium-based
* In this TF-A Tech Forum session we present the status and open roadmap for the Secure Partition Manager firmware development. The TF-A SPM is the reference open source implementation for the PSA FF-A (Platform Security Architecture Firmware Framework for A-class) specification in the Secure world. It leverages the Armv8.4-Secure EL2 extension bringing virtualization technology in the Secure world (S-EL2 exception level). The development derives originally from the Google Hafnium project, which has been recently transitioned to https://www.trustedfirmware.org/ under the BSD 3-Clause license.
* Optional TF-A Mailing List Topic Discussions
If TF-A contributors have anything they wish to present at any future TF-A tech forum please contact me to have that scheduled.
Previous sessions, both recording and presentation material can be found on the trustedfirmware.org TF-A Technical meeting webpage: https://www.trustedfirmware.org/meetings/tf-a-technical-forum/
A scheduling tracking page is also available to help track sessions suggested and being prepared: https://developer.trustedfirmware.org/w/tf_a/tf-a-tech-forum-scheduling/ Final decisions on what will be presented will be shared a few days before the next meeting and shared on the TF-A mailing list.
Thanks
Joanna
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
