Thanks to all those who attended the Tech Forum today!
It’s become apparent that the initial 2 week deadline for alternative proposals or implementations is too short, so – as agreed – we’ll push the deadline for the investigation period to the end of March. This period is dedicated to evaluating the changelog automation proposal made, or to identifying alternative solutions. If you have an alternative proposal, any proof-of-concept tooling would be highly appreciated so we can get a clear idea of what sort of work and maintenance is going to be involved.
If you do find a solution you wish to propose, please give it just a short name (e.g. “Update it manually”) and make it obvious you want to propose it formally – I’ll collect up the proposals made on the mailing list thread at the end of March and set up a Wiki poll so we can get a clear picture of where the community wants to take this.
Chris
From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Chris Kay via TF-A <tf-a(a)lists.trustedfirmware.org>
Reply to: Chris Kay <Chris.Kay(a)arm.com>
Date: Thursday, 11 February 2021 at 13:59
To: "tf-a(a)lists.trustedfirmware.org" <tf-a(a)lists.trustedfirmware.org>
Subject: [TF-A] Adoption of Conventional Commits
Hi all,
Recently we had an internal discussion on the merits of introducing semantics to commit messages pushed to the main TF-A repository, the conclusion being that we would look to adopting the Conventional Commits<https://www.conventionalcommits.org/en/v1.0.0/> specification in the near future. There was one major reason for this, which was to help us in automating the changelog in future releases, but it might also help us to dramatically reduce the overall amount of work needed to make a formal release in the future.
This requires some buy-in (or buy-out, in this case) from maintainers because - even though it’s to only a relatively minor extent - it does involve an adjustment to everybody’s workflow. Notably, commit messages will be expected to adopt the structure defined by the specification, which will be enforced by the CI. Most commits that go upstream today adhere to “something that looks like Conventional Commits”, so the change is not exactly sweeping, but any change has the potential be an inconvenience.
With that in mind, I propose the following:
* We collectively adopt the specification, enforced only for @arm.com contributors until such a time that the majority of maintainers are familiar with the new demands
* We suggest - in the prerequisites documentation - the installation of two helper tools:
* Commitizen<https://github.com/commitizen/cz-cli>
* Commitlint<https://github.com/conventional-changelog/commitlint>
Installation of these tools will be optional, but I believe they can help with the transition. In the patches currently in review, they are installed as Git hooks automatically upon execution of npm install, so it requires no manual installation or configuration (other than a relatively up-to-date Node.js installation).
You’ll find the patches here<https://review.trustedfirmware.org/q/topic:%22ck%252Fconventional-commits%2…>, and specifically the changes to the prerequisites documentation here<https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/8224/1/docs/…>. Feel free to review these changes if you have comments specifically on their implementation.
Let me know if you have any questions or concerns. If everybody’s on board, we can look to have this upstreamed shortly.
Chris
Hi
Trusted Firmware M recently introduced protection against glitching at
key decision points:
https://github.com/mcu-tools/mcuboot/pull/776
To me this is a key mitigation element for companies that target PSA
level 3 compliance which means hardware attacks resilience.
I believe similar techniques need to be used in different projects
involved in Linux secure booting (TF-A, OP-TEE, U-Boot, Linux kernel).
Are there any efforts planned around this ?
Is it feasible to have a "library" that could be integrated in
different projects?
Cheers
FF
To += op-tee(a)lists.trustedfirmware.org<mailto:op-tee@lists.trustedfirmware.org>
From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of François Ozog via TF-A
Sent: 26 March 2021 19:08
To: Heinrich Schuchardt <xypron.glpk(a)gmx.de>
Cc: tf-a(a)lists.trustedfirmware.org; Boot Architecture Mailman List <boot-architecture(a)lists.linaro.org>; Ilias Apalodimas <ilias.apalodimas(a)linaro.org>
Subject: Re: [TF-A] Firmware FuSa workshop
Le ven. 26 mars 2021 à 18:42, Heinrich Schuchardt <xypron.glpk(a)gmx.de<mailto:xypron.glpk@gmx.de>> a écrit :
On 26.03.21 16:05, François Ozog wrote:
> Hi,
>
>
> Linaro is conducting an opportunity assessment to make OP-TEE ready for
> functional safety sensitive environments. The goal is to present a plan to
> Linaro members by the end of July 2021.
>
> The scope of the research is somewhat bigger because we can’t think of
> OP-TEE without thinking of Trusted Firmware and Hafnium. The plan will
> though not address those (unless we recognize we have to). We don’t think
> U-Boot shall be part of the picture but we are welcoming contradictory
> points of views.
Hello François,
Some boards boot via SPL->TF-A->U-Boot. Here U-Boot's SPL is relevant
for OP-TEE's security.
U-Boot can save variables via OP-TEE (implemented by Ilias). In this
case OP-TEE has an implication on secure boot.
I fully understand that these scenarios are not in the focus of the
workshop.
it may if companies have this particular flow in mind for safety certification. Our goal is not to make all boot flows safety ready but to identify which ones we need to consider. And the workshop may help in this identification.
Best regards
Heinrich
>
> We are organizing a 2 hours workshop on April 15th 9am CET to mostly hear
> about use cases and ideas about Long Term Support requirements . We will
> present the state of the research.
>
> The first use case is booting a safety certified type-1 hypervisor (open
> source or commercial is irrelevant).
>
> But we know there are many more: please be ready to contribute.
>
> We think of more radical use cases: a safety payload is actually loaded as
> a Secure Partition on top of Hafnium with OP-TEE or Zephyr used as a device
> backends. In other words, Trust Zone hosts both safety and security worlds
> , EL3 being the « software root of trust » pivot world. In those cases,
> some cores never go out of secure state…
>
>
> Agenda (to be refined)
>
> -
>
> Vision
> -
>
> State of the research
> <https://docs.google.com/presentation/u/0/d/1jWqu39gCF-5XzbFkodXsiVNJJLUN88B…>
> -
>
> Use cases discussion
> -
>
> What is the right scope?
> -
>
> “Who do what” discussion (LTS, archiving...)
> -
>
> Safety personnel (Linaro and contractors) discussion
> -
>
> Other considerations from participants?
> -
>
> Community organizations and funding?
> -
>
> Closing and next steps
>
>
> Should you want to participate and have not yet received an invite, please
> contact me directly.
>
> Cordially,
>
> François-Frédéric
>
> PS: Please reach out should you want another date with a time compatible
> with more time zones. This alternate date is not guaranteed though.
>
>
--
[https://drive.google.com/a/linaro.org/uc?id=0BxTAygkus3RgQVhuNHMwUi1mYWc&ex…]
François-Frédéric Ozog | Director Linaro Edge & Fog Computing Group
T: +33.67221.6485
francois.ozog(a)linaro.org<mailto:francois.ozog@linaro.org> | Skype: ffozog
Hi Everyone,
I wanted to give an update on the availability of the TF-A OpenCI. Recognised projects contributors can now invoke the OpenCI on patches they submit or patches they review through Gerrit and so view results and fix any issues identified without an Arm reviewer having to intercede and start the Open CI for them.
This is achieved in Gerrit patches (https://review.trustedfirmware.org/p/TF-A/trusted-firmware-a/+/dashboard/si…) by setting the Allow-CI label with +1 or +2 where +1 is a light level of testing and +2 includes additional tests on top of the +1 tests. Results are linked to in the Gerrit patch comments.
Recognised projects contributors is currently seeded as everybody listed in https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tree/docs/about… including all maintainers and code-owners. The intent going forward is to include others when vouched for by other recognised projects contributors. In this way we hope to be open to all project contributors to have access to the OpenCI while providing some protection to the OpenCI back end resources.
The plan is to have another TF-A Tech-Forum session on the OpenCI on 8th April 2021 where more of the details of the OpenCI can be shared, discussed and questions can be taken.
For now please experiment with the OpenCI through your patch submissions or reviews. Please be aware this is a shared resource and use when appropriate during the patch review and be tolerant if its not quite perfect yet. Please rest assured the existing Legacy CI is still available during this transition to the OpenCI where needed to help ensure patches are adequately tested to maintain repository quality levels.
I’ll like to say a big thanks to the Linaro team working in the background to provide the OpenCI service to the TF-A project.
Cheers
Joanna
Hi,
Linaro is conducting an opportunity assessment to make OP-TEE ready for
functional safety sensitive environments. The goal is to present a plan to
Linaro members by the end of July 2021.
The scope of the research is somewhat bigger because we can’t think of
OP-TEE without thinking of Trusted Firmware and Hafnium. The plan will
though not address those (unless we recognize we have to). We don’t think
U-Boot shall be part of the picture but we are welcoming contradictory
points of views.
We are organizing a 2 hours workshop on April 15th 9am CET to mostly hear
about use cases and ideas about Long Term Support requirements . We will
present the state of the research.
The first use case is booting a safety certified type-1 hypervisor (open
source or commercial is irrelevant).
But we know there are many more: please be ready to contribute.
We think of more radical use cases: a safety payload is actually loaded as
a Secure Partition on top of Hafnium with OP-TEE or Zephyr used as a device
backends. In other words, Trust Zone hosts both safety and security worlds
, EL3 being the « software root of trust » pivot world. In those cases,
some cores never go out of secure state…
Agenda (to be refined)
-
Vision
-
State of the research
<https://docs.google.com/presentation/u/0/d/1jWqu39gCF-5XzbFkodXsiVNJJLUN88B…>
-
Use cases discussion
-
What is the right scope?
-
“Who do what” discussion (LTS, archiving...)
-
Safety personnel (Linaro and contractors) discussion
-
Other considerations from participants?
-
Community organizations and funding?
-
Closing and next steps
Should you want to participate and have not yet received an invite, please
contact me directly.
Cordially,
François-Frédéric
PS: Please reach out should you want another date with a time compatible
with more time zones. This alternate date is not guaranteed though.
--
François-Frédéric Ozog | *Director Linaro Edge & Fog Computing Group*
T: +33.67221.6485
francois.ozog(a)linaro.org | Skype: ffozog
Hi,
Recently the same fault injection protection code what is used in MCUboot was added to TF-M project.
https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/7468
It is a library which can be reused in any project to harden the critical call path and condition checks, which are crucial from device security point of view.
BR,
Tamas Ban
Hi François,
The TF-A team members have thought about trying to explore the use of more mitigations for Side Channel attacks along the lines of "Canary In the Coalmine" type techniques to as you say build additional resilience and as you can expect the techniques used by our peer TF-M project are one we would like to explore. I would not say this is a plan as such but definitely something already listed on our backlog. As to if the TF-M code can be reused that would need to be explored more.
Cheers
Joanna
On 26/03/2021, 14:12, "TF-A on behalf of François Ozog via TF-A" <tf-a-bounces(a)lists.trustedfirmware.org on behalf of tf-a(a)lists.trustedfirmware.org> wrote:
Hi
Trusted Firmware M recently introduced protection against glitching at
key decision points:
https://github.com/mcu-tools/mcuboot/pull/776
To me this is a key mitigation element for companies that target PSA
level 3 compliance which means hardware attacks resilience.
I believe similar techniques need to be used in different projects
involved in Linux secure booting (TF-A, OP-TEE, U-Boot, Linux kernel).
Are there any efforts planned around this ?
Is it feasible to have a "library" that could be integrated in
different projects?
Cheers
FF
--
TF-A mailing list
TF-A(a)lists.trustedfirmware.org
https://lists.trustedfirmware.org/mailman/listinfo/tf-a
Hi Sandeep,
I just noticed that your PR is abandoned. Will you resend your PR?
Thanks,
Peng.
________________________________
From: OP-TEE <op-tee-bounces(a)lists.trustedfirmware.org> on behalf of Peng Fan via OP-TEE <op-tee(a)lists.trustedfirmware.org>
Sent: Tuesday, March 23, 2021 10:14 AM
To: Sandeep Tripathy <sandeep.tripathy(a)broadcom.com>
Cc: tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org>; op-tee(a)lists.trustedfirmware.org <op-tee(a)lists.trustedfirmware.org>
Subject: RE: [TF-A] EHF + OPTEE on ARM64
Hi Sandeep
> Subject: Re: [TF-A] EHF + OPTEE on ARM64
>
> Hi Peng,
>
> 1-Asynchronous preemption of SP:
> The long route is to make changes in the dispatcher and the
> corresponding SPD implementation to have synchronous preemption.
> ie: OP-TEE dispatcher will implement a G1NS (fiq) handler and invoke
> an entry of OP-TEE synchronously. OP-TEE will save the thread context
> and return.
> I did some POC but the complexity and effort to generalise was not
> justified by our requirement at that point especially envisioning the
> movement to SPMD in future.
>
> 2-Synchronous preemption of SP:
> ref:
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr…
>
> I used this approach instead to unblock OP-TEE work alongside EHF.
> This serves the purpose without changing the routing model with a
> limitation that non yielding/fast SMC can
> not be preempted. And ofcourse OP-TEE can mask G0 interrupt in
> anycase. But I think this is sufficient for your purpose.
>
> Please feedback if the above patch works for you.
I was trying using #ifndef SPD_opteed to wrap the secure stuff. Thanks
for your patch. I test on i.MX8MM-EVK, it works well.
Thanks,
Peng.
>
> Thanks
> Sandeep
>
> On Mon, Mar 22, 2021 at 2:43 PM Peng Fan via TF-A
> <tf-a(a)lists.trustedfirmware.org> wrote:
> >
> > Hi Achin,
> >
> >
> >
> > We are using SDEI for Jailhouse hypervisor to minimize interrupt latency,
> however we also wanna use OP-TEE when SDEI enabled.
> >
> >
> >
> > So I wanna how to make both work together.
> >
> >
> >
> > Thanks,
> >
> > Peng.
> >
> >
> >
> > From: Achin Gupta [mailto:Achin.Gupta@arm.com]
> > Sent: 2021年3月17日 17:59
> > To: Peng Fan <peng.fan(a)nxp.com>; Jens Wiklander
> <jens.wiklander(a)linaro.org>
> > Cc: op-tee(a)lists.trustedfirmware.org; tf-a(a)lists.trustedfirmware.org
> > Subject: Re: EHF + OPTEE on ARM64
> >
> >
> >
> > Hi Peng,
> >
> >
> >
> > +TF-A folk.
> >
> >
> >
> > My 0.02$.
> >
> >
> >
> > What is the problem you are trying to solve? Why do you need to run
> OP-TEE and EHF together? EHF was originally written to support a S-EL0 SP
> that is managed directly by TF-A in EL3 (TF-A folk can chime in).
> >
> >
> >
> > The SP could perform RAS error handling for which it needs the EHF. The EHF
> triages asynchronous exceptions and hands RAS errors to the SP for further
> handling.
> >
> >
> >
> > This is just one use case but there is no Trusted OS in these configurations.
> >
> >
> >
> > So, it would help to understand the requirement.
> >
> >
> >
> > cheers,
> >
> > Achin
> >
> >
> >
> > ________________________________
> >
> > From: OP-TEE <op-tee-bounces(a)lists.trustedfirmware.org> on behalf of
> Jens Wiklander via OP-TEE <op-tee(a)lists.trustedfirmware.org>
> > Sent: 17 March 2021 09:23
> > To: Peng Fan <peng.fan(a)nxp.com>
> > Cc: op-tee(a)lists.trustedfirmware.org <op-tee(a)lists.trustedfirmware.org>
> > Subject: Re: EHF + OPTEE on ARM64
> >
> >
> >
> > On Wed, Mar 17, 2021 at 9:43 AM Peng Fan <peng.fan(a)nxp.com> wrote:
> > >
> > > > Subject: Re: EHF + OPTEE on ARM64
> > > >
> > > > On Wed, Mar 17, 2021 at 9:02 AM Peng Fan <peng.fan(a)nxp.com>
> wrote:
> > > > >
> > > > > > Subject: Re: EHF + OPTEE on ARM64
> > > > > >
> > > > > > On Wed, Mar 17, 2021 at 8:41 AM Peng Fan <peng.fan(a)nxp.com>
> wrote:
> > > > > > >
> > > > > > > > Subject: Re: EHF + OPTEE on ARM64
> > > > > > > >
> > > > > > > > On Tue, Mar 16, 2021 at 11:08 AM Peng Fan
> <peng.fan(a)nxp.com>
> > > > wrote:
> > > > > > > > >
> > > > > > > > > Hi,
> > > > > > > > >
> > > > > > > > > In bl31/ehf.c, there are following two lines, per my
> > > > > > > > > understanding, when cpu is in secure world, the non-secure
> > > > > > > > > interrupt as FIQ(GICv3) will be directly catched by EL3, not
> S-EL1
> > > > > > > > > /* Route EL3 interrupts when in Secure and
> Non-secure.
> > > > */
> > > > > > > > > set_interrupt_rm_flag(flags, NON_SECURE);
> > > > > > > > > set_interrupt_rm_flag(flags, SECURE);
> > > > > > > > >
> > > > > > > > > So this will conflict with OP-TEE, because OP-TEE needs catch
> > > > > > > > > NS-interrupt as FIQ in S-EL1 world.
> > > > > > > >
> > > > > > > > In the case of GICv3, OP-TEE is configured to receive the
> > > > > > > > non-secure interrupts as FIQ and secure interrupts as IRQ. See
> > > > CFG_ARM_GICV3.
> > > > > > >
> > > > > > > But EHF needs NS-interrupt FIQ be catched by EL3 if I understand
> > > > > > > correct, per " set_interrupt_rm_flag(flags, SECURE);"
> > > > > > >
> > > > > > > So currently EHF could not work together with OP-TEE, right?
> > > > > >
> > > > > > To be honest, I'm not completely sure what EHF does. From OP-TEE
> > > > > > point of view we expect to receive the non-secure interrupts as a
> > > > > > way of doing a controlled exit. This allows OP-TEE to resume
> > > > > > execution with a different core on re-entry. If EL3 takes the
> > > > > > non-secure interrupts directly it will have to make sure to only
> re-enter
> > > > OP-TEE on this core as a return from exception.
> > > > >
> > > > > Is this easy to be achieved?
> > > >
> > > > I don't know, it depends on what you intend to do with this non-secure
> > > > interrupt. If it's handled at EL3 and then there's a return from exception
> back
> > > > to S-EL1 there's likely no harm done. But if there's a world switch
> involved
> > > > there might be trouble, OP-TEE might not be in a suitable state for a
> world
> > > > switch.
> > > >
> > > > >
> > > > > Or by using opteed_sel1_interrupt_handler, could we have similar
> > > > > behavior to allow the other core resume execution?
> > > >
> > > > Only OP-TEE itself can make a controlled exit as there's an internal state
> to
> > > > maintain. Currently that's signalled with a non-secure interrupt.
> > >
> > >
> > > Per EHF,
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftrustedfi…
> andling.html?highlight=Exception%20Handling%20Framework
> > > On GICv3 systems, when executing in S-EL1, pending Non-secure
> interrupts of
> > > sufficient priority are signalled as FIQs, and therefore will be routed to
> EL3.
> > > As a result, S-EL1 software cannot expect to handle Non-secure interrupts
> at S-EL1.
> > > Essentially, this deprecates the routing mode described as CSS=0, TEL3=0.
> > >
> > > In order for S-EL1 software to handle Non-secure interrupts while having
> EHF enabled,
> > > the dispatcher must adopt a model where Non-secure interrupts are
> received at EL3,
> > > but are then synchronously handled over to S-EL1.
> > >
> > > The issue to me here how to synchronously handled over to S-EL1 and not
> break optee.
> >
> > I understand. OP-TEE is masking interrupts in some critical sections,
> > while in such a state OP-TEE cannot handle any asynchronous interrupt.
> > Temporarily masking interrupts is normally a quick operation so we do
> > it in quite a few places.
> > So the crux of the problem is to make sure that OP-TEE is in a state
> > where it can make a controlled exit. I don't have any good ideas for
> > this right now.
> >
> > Cheers,
> > Jens
> >
> > --
> > TF-A mailing list
> > TF-A(a)lists.trustedfirmware.org
> > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru…
