September 2020 - TF-A - lists.trustedfirmware.org

Cancelled event with note: TF-A Tech Forum @ Thu 24 Sep 2020 16:00 - 17:00 (BST) (tf-a@lists.trustedfirmware.org)

by Bill Fletcher

This event has been cancelled with this note: "Due to conflicts with Linaro Connect this week we are cancelling this week’s TF-A Techforum on Thursday, 24th September 2020 at 16:00 – 17:00 BST. The next meeting will now be Thursday, 8th October 2020 at 16:00 – 17:00 BST" Title: TF-A Tech Forum We run an open technical forum call for anyone to participate and it is not restricted to Trusted Firmware project members. It will operate under the guidance of the TF TSC. Feel free to forward this invite to colleagues. Invites are via the TF-A mailing list and also published on the Trusted Firmware website. Details are here: https://www.trustedfirmware.org/meetings/tf-a-technical-forum/Tr… Firmware is inviting you to a scheduled Zoom meeting.Join Zoom Meetinghttps://zoom.us/j/9159704974Meeting ID: 915 970 4974One tap mobile+16465588656,,9159704974# US (New York)+16699009128,,9159704974# US (San Jose)Dial by your location        +1 646 558 8656 US (New York)        +1 669 900 9128 US (San Jose)        877 853 5247 US Toll-free        888 788 0099 US Toll-freeMeeting ID: 915 970 4974Find your local number: https://zoom.us/u/ad27hc6t7h   When: Thu 24 Sep 2020 16:00 – 17:00 United Kingdom Time Calendar: tf-a(a)lists.trustedfirmware.org Who: * Bill Fletcher- creator * marek.bykowski(a)gmail.com * okash.khawaja(a)gmail.com * tf-a(a)lists.trustedfirmware.org Invitation from Google Calendar: https://www.google.com/calendar/ You are receiving this courtesy email at the account tf-a(a)lists.trustedfirmware.org because you are an attendee of this event. To stop receiving future updates for this event, decline this event. Alternatively, you can sign up for a Google Account at https://www.google.com/calendar/ and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to send a response to the organiser and be added to the guest list, invite others regardless of their own invitation status or to modify your RSVP. Learn more at https://support.google.com/calendar/answer/37135#forwarding

5 years

1
0
0 0

Linaro Connect Sessions of Interest

by Don Harbin

Hi All, As Linaro Connect starts tomorrow, here are some pointers to sessions that will be of interest related to trustedfirmware.org. - *PSA Secure Partitions in OP-TEE* - Tuesday, September 22nd (1:25-1:50pm UTC) - Speaker: Miklos Balint - Slides available here <https://static.sched.com/hosted_files/lvc20/9a/LVC20-112_PSA_Secure_Partiti…> - *Trusted Firmware Project update* - Tuesday, Sept. 22nd (2:00-2:25pm UTC) - Spreaders: Matteo Carlini, Shebu Kuriakose - Slides available here <https://static.sched.com/hosted_files/lvc20/1e/LVC20-113-Trusted-Firmware-p…> - *Scalable Security Using Trusted Firmware-M Profiles* - Wednesday September 23rd (11.45am – 12.10pm UTC) - Speakers: Shebu Kuiakose, David Want - Slides available here <https://static.sched.com/hosted_files/lvc20/d0/ScalableSecurityUsingTrusted…> - *Enable UEFI Secure Boot using OP-TEE as Secure Partition* - Thursday September 24th (3.45-4.10pm UTC) - Speakers: Sahil Malhotra, Ilias Apalodimas - *Secure Partition Manager (SEL2 firmware) for Arm A-class devices* - Thursday September 24th (4.15-4.40pm UTC) - Speaker: Olivier Deprez - Slides are available here <https://static.sched.com/hosted_files/lvc20/09/LVC20-305-secure-partition-m…> Some general pointers to sessions of potential interest: - Security related topics can be viewed here - Boot architecture topics can be viewed here As a reminder, sign up for tomorrow's event is at Linaro Connect Registration <https://connect.linaro.org/> and is free, so feel free to forward this information on. :) The overall schedule is available at the same link as registration in case you may be interested in other sessions. Best regards, Don

5 years

1
0
0 0

TF-A TechForum 24th Sept Cancelled

by Joanna Farley

Due to conflicts this week I am cancelling this week’s TF-A Techforum on Thursday, 24th September 2020 at 16:00 – 17:00 BST. The next meeting will now be Thursday, 8th October 2020 at 16:00 – 17:00 BST Apologies all. Joanna

5 years

1
0
0 0

Re: [TF-A] Tests to verify BP_OPTION

by Alexei Fedorov

Hi, Yes, there are fvp-pauth-pac-ret-leaf-sdei,fvp-pauth-standard:fvp-tftf-fip.tftf-aemv8a.8_5-debug fvp-pauth-pac-ret-leaf-tsp-sdei,fvp-pauth-standard:fvp-tftf-fip.tftf-aemv8a.8_5-debug configs in platform-ci/group/tftf-l2-fvp introduced by https://review.trustedfirmware.org/c/ci/tf-a-ci-scripts/+/5393 Alexei ________________________________ From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Varun Wadekar via TF-A <tf-a(a)lists.trustedfirmware.org> Sent: 17 September 2020 19:18 To: Kalyani Chidambaram Vaidyanathan <kalyanic(a)nvidia.com>; tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org> Subject: Re: [TF-A] Tests to verify BP_OPTION <Bump to get this email through> From: Kalyani Chidambaram Vaidyanathan <kalyanic(a)nvidia.com> Sent: Wednesday, September 16, 2020 11:54 AM To: tf-a(a)lists.trustedfirmware.org Cc: Varun Wadekar <vwadekar(a)nvidia.com> Subject: Tests to verify BP_OPTION Hi, Is there any test to verify the BP_OPTION feature set to “pac-ret+leaf” ? When BRANCH_PROTECTION is set to “3”, BP_OPTION is set to “pac-ret+leaf”. Reference code - https://github.com/ARM-software/arm-trusted-firmware/blob/master/Makefile Thanks, Kalyani

5 years

2
2
0 0

Re: [TF-A] Query TSPD behavior with EHF

by Soby Mathew

Hi Sandeep > Except during yielding SMC ‘disable_intr_rm_local(INTR_TYPE_NS, SECUE);’ is in effect. Intention is to avoid NS interrupt preempt secure execution (Fast SMC). > But I think that will also disable G0 interrupt as both NS interrupt and G0 interrupt are on FIQ. > EHF already ensures this by GIC PMR adjustment. So disabling routing model seems unnecessary in this case. > This is my understanding from the code please confirm if this is correct. The EL3 interrupts (G0 interrupts) should be able to pre-empt Fast SMC. Hence the usage of GIC PMR to mask the NS interrupts. As Dan says, the TSP_NS_INTR_ASYNC_PREEMPT predates the EHF design and it seems there is a problem as you describe. > EHF already ensures this by GIC PMR adjustment. So disabling routing model seems unnecessary in this case. > This is my understanding from the code please confirm if this is correct. You are right. Routing model manipulation is not required when EL3 interrupts are present as GIC PMR manipulation should take care of the required behaviour for yielding vs atomic SMC. You also need to ensure it works as expected when EL3 interrupts are not enabled and when EHF is disabled. Best Regards Soby Mathew > -----Original Message----- > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Sandeep > Tripathy via TF-A > Sent: 17 September 2020 16:53 > To: Dan Handley <Dan.Handley(a)arm.com> > Cc: tf-a(a)lists.trustedfirmware.org > Subject: Re: [TF-A] Query TSPD behavior with EHF > > Hi Dan, > I am not sure if this is mentioned anywhere in any documents but I think > EHF handlers should be able to preempt all execution contexts at lower ELs > and lower ELs should never be able to mask such interrupts. > If the behavioral expectation is set the implementation can be fixed. > > Thanks > Sandeep > > On Thu, Sep 17, 2020 at 7:57 PM Dan Handley via TF-A <tf- > a(a)lists.trustedfirmware.org> wrote: > > > > A correction... > > > > > -----Original Message----- > > > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Dan > > > Handley via TF-A > > > Sent: 17 September 2020 15:14 > > > > > > > > > > I want to handle something similar in OP-TEED along with EHF > > > > > depending on > > > > what is the expected behavior. > > > > > > > > Hmm, I thought OP-TEED was more like the > TSP_NS_INTR_ASYNC_PREEMPT=0 > > > case, where NS interrupts are routed to S-EL1 while processing a > > > yielding SMC in S- EL1? Perhaps that's a better TSPD config for you to > follow? > > > > > Sorry, if EL3_EXCEPTION_HANDLING=1 then obviously NS interrupts are > routed to EL3 first, but the TSPD re-enables NS interrupts before handing > over to the TSP to handle yielding calls, via a call to > ehf_allow_ns_preemption. > > > > Right, that is the case for yielding SMC handling where both NS interrupts > and EL3/G0 interrupts can preempt the S_EL1/S_EL2 context. > But I would expect the same routing model even for 'Fast SMC' unlike what is > happening in TSPD. > > > Dan. > > > > -- > > TF-A mailing list > > TF-A(a)lists.trustedfirmware.org > > https://lists.trustedfirmware.org/mailman/listinfo/tf-a > -- > TF-A mailing list > TF-A(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-a

5 years

1
0
0 0

Re: [TF-A] Build failure in OpenCI

by Joanna Farley

FYI we are trying to get the OpenCI to use a different label (Validation-Bot-Review) which is not part our of day to day workflow for patch approvals but standard plugins being used don't seem to support non standard labels so they are working on an alternative approach. Hopefully it will be fixed soon so we don't have to manually remove the OpenCI bot setting on the CR label. Joanna On 18/09/2020, 09:30, "TF-A on behalf of Yann GAUTIER via TF-A" <tf-a-bounces(a)lists.trustedfirmware.org on behalf of tf-a(a)lists.trustedfirmware.org> wrote: Hi Olivier, Thanks for your answer. I was not particularly worried when I saw what the error was. And I understand it can take time to stabilize such infrastructure. It is nice that we can have access to it now. Regards, Yann -----Original Message----- From: Olivier Deprez <Olivier.Deprez(a)arm.com> Sent: vendredi 18 septembre 2020 10:22 To: tf-a(a)lists.trustedfirmware.org; Yann GAUTIER <yann.gautier(a)st.com> Subject: Re: Build failure in OpenCI Hi Yann, The OpenCI is under enablement/works, and I think you can safely ignore those CR-1/Verified-1 from the bot. Current CI strategy is still about maintainers applying Allow-CI+1/2 (resulting in Verified+1 on success). Sorry for the trouble it causes presently. Regards, Olivier. ________________________________________ From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Yann GAUTIER via TF-A <tf-a(a)lists.trustedfirmware.org> Sent: 18 September 2020 09:33 To: tf-a(a)lists.trustedfirmware.org Subject: [TF-A] Build failure in OpenCI Hi, I've pushed some series of patches this morning, but none of them passes the OpenCI builds and tests. For all of them, the error is the same, Lava cannot find a file: http://ci.trustedfirmware.org/job/tf-a-builder//ws/custom_lava_job_definiti…<http://ci.trustedfirmware.org/job/tf-a-builder/ws/custom_lava_job_definitio…> See for example: https://ci.trustedfirmware.org/job/post-build-lava/3941/console Do you know what's wrong with this file? And if it will be corrected soon? Thanks, Yann -- TF-A mailing list TF-A(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a

5 years

1
0
0 0

Re: [TF-A] Build failure in OpenCI

by Olivier Deprez

Hi Yann, The OpenCI is under enablement/works, and I think you can safely ignore those CR-1/Verified-1 from the bot. Current CI strategy is still about maintainers applying Allow-CI+1/2 (resulting in Verified+1 on success). Sorry for the trouble it causes presently. Regards, Olivier. ________________________________________ From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Yann GAUTIER via TF-A <tf-a(a)lists.trustedfirmware.org> Sent: 18 September 2020 09:33 To: tf-a(a)lists.trustedfirmware.org Subject: [TF-A] Build failure in OpenCI Hi, I’ve pushed some series of patches this morning, but none of them passes the OpenCI builds and tests. For all of them, the error is the same, Lava cannot find a file: http://ci.trustedfirmware.org/job/tf-a-builder//ws/custom_lava_job_definiti…<http://ci.trustedfirmware.org/job/tf-a-builder/ws/custom_lava_job_definitio…> See for example: https://ci.trustedfirmware.org/job/post-build-lava/3941/console Do you know what’s wrong with this file? And if it will be corrected soon? Thanks, Yann

5 years

2
1
0 0

Build failure in OpenCI

by Yann GAUTIER

Hi, I've pushed some series of patches this morning, but none of them passes the OpenCI builds and tests. For all of them, the error is the same, Lava cannot find a file: http://ci.trustedfirmware.org/job/tf-a-builder//ws/custom_lava_job_definiti…<http://ci.trustedfirmware.org/job/tf-a-builder/ws/custom_lava_job_definitio…> See for example: https://ci.trustedfirmware.org/job/post-build-lava/3941/console Do you know what's wrong with this file? And if it will be corrected soon? Thanks, Yann

5 years

1
0
0 0

Tests to verify BP_OPTION

by Kalyani Chidambaram Vaidyanathan

Hi, Is there any test to verify the BP_OPTION feature set to "pac-ret+leaf" ? When BRANCH_PROTECTION is set to "3", BP_OPTION is set to "pac-ret+leaf". Reference code - https://github.com/ARM-software/arm-trusted-firmware/blob/master/Makefile Thanks, Kalyani

5 years

2
1
0 0

Re: [TF-A] Query TSPD behavior with EHF

by Sandeep Tripathy

Hi Dan, I am not sure if this is mentioned anywhere in any documents but I think EHF handlers should be able to preempt all execution contexts at lower ELs and lower ELs should never be able to mask such interrupts. If the behavioral expectation is set the implementation can be fixed. Thanks Sandeep On Thu, Sep 17, 2020 at 7:57 PM Dan Handley via TF-A <tf-a(a)lists.trustedfirmware.org> wrote: > > A correction... > > > -----Original Message----- > > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Dan Handley > > via TF-A > > Sent: 17 September 2020 15:14 > > > > > > > > I want to handle something similar in OP-TEED along with EHF > > > > depending on > > > what is the expected behavior. > > > > > > Hmm, I thought OP-TEED was more like the TSP_NS_INTR_ASYNC_PREEMPT=0 case, > > where NS interrupts are routed to S-EL1 while processing a yielding SMC in S- > > EL1? Perhaps that's a better TSPD config for you to follow? > > > Sorry, if EL3_EXCEPTION_HANDLING=1 then obviously NS interrupts are routed to EL3 first, but the TSPD re-enables NS interrupts before handing over to the TSP to handle yielding calls, via a call to ehf_allow_ns_preemption. > Right, that is the case for yielding SMC handling where both NS interrupts and EL3/G0 interrupts can preempt the S_EL1/S_EL2 context. But I would expect the same routing model even for 'Fast SMC' unlike what is happening in TSPD. > Dan. > > -- > TF-A mailing list > TF-A(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-a

5 years

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

TF-A September 2020