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.
Hi Sandeep
> -----Original Message-----
> From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Sandeep
> Tripathy via TF-A
> >
> > EHF activates the routing model for ‘INTR_TYPE_EL3’ CSS = 0 , TEL3 = 1
> ie FIQ trapped to EL3 and not visible and not mask-able to lower ELs.
> >
> > Which means G0 interrupts (all EHF interrupts) expected to preempt any
> > execution context. And secure state cannot mask such interrupts
> >
> > eg: critical error interrupts. Sort of NMI behavior.
> >
> > However from TSPD code I see ‘TSP_NS_INTR_ASYNC_PREEMPT’ enforces a
> slightly different behavior. G0 interrupt cannot preempt a fast smc handler
> in SPD.
> >
> > Except during yielding SMC ‘disable_intr_rm_local(INTR_TYPE_NS, SECURE);’
> 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.
I haven't double checked but that sounds correct.
> > 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 TSPD's TSP_NS_INTR_ASYNC_PREEMPT functionality predates the EHF, which probably explains why NS interrupts are disabled in 2 ways in this config (i.e. when both TSP_NS_INTR_ASYNC_PREEMPT and EL3_EXCEPTION_HANDLING equal 1). I guess it's possible that the call to disable the routing model can be safely removed in this config but it would require some thorough code review and testing. I'm not sure if this config is tested much at all.
> >
> >
> > Do we think it is not aligned with G0 interrupt preemption rule. Or do we
> treat Fast SMC at S_EL1/EL2 as non interruptible.
> >
I think G0 interrupts should be handled in this case but I'm not sure if this is easy to fix in the TSPD.
> >
> >
> > 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?
Regards
Dan.
Updated..
On Wed, Sep 16, 2020 at 10:51 AM Sandeep Tripathy via TF-A
<tf-a(a)lists.trustedfirmware.org> wrote:
>
> Hi,
>
> EHF activates the routing model for ‘INTR_TYPE_EL3’ CSS = 0 , TEL3 = 1 ie FIQ trapped to EL3 and not visible and not mask-able to lower ELs.
>
> Which means G0 interrupts (all EHF interrupts) expected to preempt any execution context. And secure state cannot mask such interrupts
>
> eg: critical error interrupts. Sort of NMI behavior.
>
>
>
> However from TSPD code I see ‘TSP_NS_INTR_ASYNC_PREEMPT’ enforces a slightly different behavior. G0 interrupt cannot preempt a fast smc handler in SPD.
>
> Except during yielding SMC ‘disable_intr_rm_local(INTR_TYPE_NS, SECURE);’ 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.
>
>
>
> Do we think it is not aligned with G0 interrupt preemption rule. Or do we treat Fast SMC at S_EL1/EL2 as non interruptible.
>
>
>
> I want to handle something similar in OP-TEED along with EHF depending on what is the expected behavior.
>
>
>
> Thanks
>
> Sandeep
>
>
>
> --
> TF-A mailing list
> TF-A(a)lists.trustedfirmware.org
> https://lists.trustedfirmware.org/mailman/listinfo/tf-a
Hi,
EHF activates the routing model for ‘INTR_TYPE_EL3’ CSS = 0 , TEL3 = 1
ie FIQ trapped to EL3 and not visible and not mask-able to lower ELs.
Which means G0 interrupts (all EHF interrupts) expected to preempt any
execution context. And secure state cannot mask such interrupts
eg: critical error interrupts. Sort of NMI behavior.
However from TSPD code I see ‘TSP_NS_INTR_ASYNC_PREEMPT’ enforces a
slightly different behavior. G0 interrupt cannot preempt a fast smc handler
in SPD.
Except during yielding SMC ‘disable_intr_rm_local(INTR_TYPE_NS, SECURE);’
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.
This is my understanding from the code please confirm if this is correct.
Do we think it is not aligned with G0 interrupt preemption rule. Or do we
treat Fast SMC at S_EL1/EL2 as non interruptible.
I want to handle something similar in OP-TEED along with EHF depending on
what is the expected behavior.
Thanks
Sandeep
Hello,
ATF currently uses non-portable printf format specifiers for fixed width types defined in stdint.h
In addition, ATF redefines types defined in gcc for stdint.h with its own custom types causing additional issues.
This causes compilation issues when porting code to/from ATF.
AND, generates coverity parse errors as int64_t and uint64_t are incorrectly defined in ATF vs. gcc for aarch64.
The printf format specifiers in inttypes.h are to be used for the proper format specifiers.
And, uint64_t/int64_t should be defined the same as in gcc.
I tried fixing up all the instances of int64 printf format specifiers by introducing inttypes.h and redefined the stdint types correctly here:
https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/5437
We have checked the change into our local tree so that everything compiles and runs in our system. Please accept change upstream.
Regards,
Scott
On Thu, 11 Jun 2020 at 23:42, Varun Wadekar via TF-A <
tf-a(a)lists.trustedfirmware.org> wrote:
> Hello Matteo,
>
> Apologies for still using an outdated term. I have trained myself to get
> used to "TF-A" - looks like I am still not there.
>
> >> The idea has also been just raised to the Trusted Firmware project
> Board for initial consideration and we will be all very keen to understand
> how much interest there is from the wider TF-A community of adopters and
> external (non-Arm) maintainers
>
> That is good to hear. For the exact scope, I think we can assume the usual
> expectations from any LTS software stack - stability, performance,
> security, bug fixes along with maintenance support. We are open to
> discussing the cadence and any other operational commitments.
>
> @Francois, from the description of Trusted Substrate looks like you also
> expect the sub-projects to provide LTS versions for the project as a whole
> to succeed (?)
>
> Yes. I assume relevant tf.org projects decide to branch LTSes so that we
can extend the scope to selected OP-TEE TAs for the Trusted Substrate LTS
and may be extend duration of support for the tf.org LTSes. (just to make
sure: this is just early open thinking to understand what it would mean to
build such a service on the Linaro side should there be tf.org LTSes).
-Varun
>
>
> -----Original Message-----
> From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Matteo
> Carlini via TF-A
> Sent: Thursday, June 11, 2020 4:25 AM
> To: tf-a(a)lists.trustedfirmware.org
> Subject: Re: [TF-A] ATF LTS version
>
> External email: Use caution opening links or attachments
>
>
> Hi Francois,
>
> > I'd be happy to know more about what you see as TFA LTS: exact scope,
> number of versions, duration, operational commitments (zero-day...).
> > Do you have other firmware LTS needs?
>
> Agree. That’s precisely what I was hinting to Varun, when mentioning
> concrete requirements for the LTS scheme.
>
> > Trusted Substrate is the aggregation of { TFA, OP-TEE, some TEE apps
> such as firmwareTPM, U-Boot }.
> > Trusted Substrate effort is led by Linaro members and is going to be set
> up as a more open project.
>
> First time I heard about it. Good to know, but I guess we'll need to
> discuss the intersection and collaboration with the Trusted Firmware
> project at some point.
> Having a LTS versioning scheme for the Trusted Firmware hosted projects
> should be theoretically either in the scope of the Project itself or, if
> the Board agrees, appointed to some other project/entity.
>
> > Our end goal is to enable unified, transactional, robust (anti-bricking,
> anti rollback) UEFI OTA on both U-Boot and EDK2.
>
> Fair, but IMHO this has little to do with Arm Secure world software LTS
> releases (TF-A/Hafnium/OP-TEE/TAs, TF-M)...probably best to discuss aside,
> this is not in scope of what Varun is raising.
>
> Thanks
> Matteo
>
> --
> 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
>
--
François-Frédéric Ozog | *Director Linaro Edge & Fog Computing Group*
T: +33.67221.6485
francois.ozog(a)linaro.org | Skype: ffozog
Hi All,
The next TF-A Tech Forum is scheduled for Thu 10th September 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:
* Proposal for a LTS (Long Term Support) Release Option for TF-A
* Presented by Varun Wadekar
* Long-term support is a lifecycle management policy in which a stable release is maintained for a period of time
* 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
Hi again,
After further check, it looks gcc 9.2 already supports the appropriate option.
Maybe you missed ARM_ARCH_MINOR on the build command line depending on whether you need PAuth (Armv8.3) and/or BTI (Armv8.5).
BRANCH_PROTECTION=2 or 3 => need ARM_ARCH_MINOR=3 (at least)
BRANCH_PROTECTION=1 or 4 => need ARM_ARCH_MINOR=5
Regards,
Olivier.
________________________________________
From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Olivier Deprez via TF-A <tf-a(a)lists.trustedfirmware.org>
Sent: 03 September 2020 09:47
To: Kalyani Chidambaram Vaidyanathan; tf-a(a)lists.trustedfirmware.org; Varun Wadekar
Subject: Re: [TF-A] GCC compiler option to support "xpaci" instruction
Hi Kalyani,
According to https://trustedfirmware-a.readthedocs.io/en/latest/getting_started/build-op…
you need a compiler supporting the -mbranch-protection option.
This seems to be the case from gcc 9.3 onwards: https://gcc.gnu.org/onlinedocs/gcc-9.3.0/gcc/AArch64-Options.html#AArch64-O…
Notice a GCC10.2 cross-compiler release is planned by end of this year according to this page:
https://community.arm.com/developer/tools-software/tools/b/tools-software-i…
Regards,
Olivier.
________________________________________
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: 03 September 2020 04:08
To: Kalyani Chidambaram Vaidyanathan; tf-a(a)lists.trustedfirmware.org
Subject: Re: [TF-A] GCC compiler option to support "xpaci" instruction
<Dummy response to get the email through to the mailing list>
From: Kalyani Chidambaram Vaidyanathan <kalyanic(a)nvidia.com>
Sent: Wednesday, September 2, 2020 3:43 PM
To: tf-a(a)lists.trustedfirmware.org
Cc: Varun Wadekar <vwadekar(a)nvidia.com>
Subject: GCC compiler option to support "xpaci" instruction
Hi,
We are using gcc-arm-9.2 toolchain and see that this is not supporting the “xpaci” instruction.
Is there any compiler flag that has to be included to support this?
Reference code that uses “xpaci” when PAUTH is enabled -
https://github.com/ARM-software/arm-trusted-firmware/blob/master/bl31/aarch…
Thanks,
Kalyani
--
TF-A mailing list
TF-A(a)lists.trustedfirmware.org
https://lists.trustedfirmware.org/mailman/listinfo/tf-a
Hi Kalyani,
According to https://trustedfirmware-a.readthedocs.io/en/latest/getting_started/build-op…
you need a compiler supporting the -mbranch-protection option.
This seems to be the case from gcc 9.3 onwards: https://gcc.gnu.org/onlinedocs/gcc-9.3.0/gcc/AArch64-Options.html#AArch64-O…
Notice a GCC10.2 cross-compiler release is planned by end of this year according to this page:
https://community.arm.com/developer/tools-software/tools/b/tools-software-i…
Regards,
Olivier.
________________________________________
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: 03 September 2020 04:08
To: Kalyani Chidambaram Vaidyanathan; tf-a(a)lists.trustedfirmware.org
Subject: Re: [TF-A] GCC compiler option to support "xpaci" instruction
<Dummy response to get the email through to the mailing list>
From: Kalyani Chidambaram Vaidyanathan <kalyanic(a)nvidia.com>
Sent: Wednesday, September 2, 2020 3:43 PM
To: tf-a(a)lists.trustedfirmware.org
Cc: Varun Wadekar <vwadekar(a)nvidia.com>
Subject: GCC compiler option to support "xpaci" instruction
Hi,
We are using gcc-arm-9.2 toolchain and see that this is not supporting the “xpaci” instruction.
Is there any compiler flag that has to be included to support this?
Reference code that uses “xpaci” when PAUTH is enabled -
https://github.com/ARM-software/arm-trusted-firmware/blob/master/bl31/aarch…
Thanks,
Kalyani
