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
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
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
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
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
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
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
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.
Dan.
