RE: [TF-A] Proposal: TF-A to adopt hand-off blocks (HOBs) for information passing between boot stages

[raghu.ncstate]

Julius, Simon,

 

It appears there are opinions you carry around UUID being complicated, bloated, 
code being an eyesore, parsing these lists early with MMU/Caches disabled, 
calculating checksums etc. While there is certainly a LOT of truth to those 
statements, these concerns need to be put into context and may not necessarily 
apply to all platforms running TF-A. Standardization and interoperability may 
be valued more on some platforms and some of the bloat and performance issues 
may be worth those tradeoffs. Some of these concerns may not even apply on 
powerful CPU’s and SoC’s with lots of memory. Also a quick grep for “uuid” in 
the TF-A repository shows that there is significant use of UUID’s for FIP, some 
SMC’s, secure partitions etc so use of UUID is not something new to TF-A.

 

While there are many ways to solve the same problem, there are also potential 
dis-advantages to something like the mechanism pointed out below. For example, 
this is yet another solution to an already solved problem. If we use UEFI 
hob’s, the code and problem has been solved for decades and there is code 
re-use possible and that *potentially*(opinions may vary) is better for 
security as there have been eyes on it for long and is more stable.(I’m very 
aware UEFI is not the gold standard for security, but again, it is a blanket 
statement to say all UEFI code is bad).

Does the method mentioned below allow you to create a dynamic list of arbitrary 
lengths and NOT lists of lengths decided at compile time? It appears that it is 
mainly being used on lists fixed at compile time.

What about interoperability with UEFI? Coreboot is great for 
platforms/companies that use it but what about platforms that *must* use UEFI 
for various reasons? Do we need a conversion from the method below to a UEFI 
HOB if BL33 is UEFI? Clearly the solution below was tailored to coreboot.

 

We can support multiple ways in the same code base through build and run time 
options and a platform should be free to make calls on whether the problems you 
mentioned below really apply or not. What is a pain to do(having co-ordination 
with multiple companies vs vendor defined tags/UUID’s) is also subjective and 
whether or not it is overstated is matter of opinion/context.

 

I think it may be best to discuss this in the call and understand the 
requirements fully. It may turn out that what you have proposed below works 
anyway 

 

 

Thanks

Raghu

 

From: TF-A  On Behalf Of Julius Werner 
via TF-A
Sent: Wednesday, March 24, 2021 7:44 PM
To: Simon Glass 
Cc: Harb Abdulhamid OS ; Boot Architecture 
Mailman List ; 
t...@lists.trustedfirmware.org; U-Boot Mailing List ; 
Paul Isaac's ; Ron Minnich 
Subject: Re: [TF-A] Proposal: TF-A to adopt hand-off blocks (HOBs) for 
information passing between boot stages

 

Just want to point out that TF-A currently already supports a (very simple) 
mechanism like this:

 

https://review.trustedfirmware.org/plugins/gitiles/TF-A/trusted-firmware-a/+/refs/heads/master/include/export/lib/bl_aux_params/bl_aux_params_exp.h

https://review.trustedfirmware.org/plugins/gitiles/TF-A/trusted-firmware-a/+/refs/heads/master/lib/bl_aux_params/bl_aux_params.c

https://review.trustedfirmware.org/plugins/gitiles/TF-A/trusted-firmware-a/+/refs/heads/master/plat/rockchip/common/params_setup.c

 

It's just a linked list of tagged elements. The tag space is split into 
TF-A-wide generic tags and SiP-specific tags (with plenty of room to spare if 
more areas need to be defined -- a 64-bit tag can fit a lot). This is currently 
being used by some platforms that run coreboot in place of BL1/BL2, to pass 
information from coreboot (BL2) to BL31.

 

I would echo Simon's sentiment of keeping this as simple as possible and 
avoiding complicated and bloated data structures with UUIDs. You usually want 
to parse something like this as early as possible in the passed-to firmware 
stage, particularly if the structure encodes information about the debug 
console (like it does for the platforms I mentioned above). For example, in 
BL31 this basically means doing it right after moving from assembly to C in 
bl31_early_platform_setup2() to get the console up before running anything 
else. At that point in the BL31 initialization, the MMU and caches are 
disabled, so data accesses are pretty expensive and you don't want to spend a 
lot of parsing effort or calculate complicated checksums or the like. You just 
want something extremely simple where you ideally have to touch every data word 
only once.

 

On Wed, Mar 24, 2021 at 5:06 PM Simon Glass via TF-A 
mailto:t...@lists.trustedfirmware.org> > wrote:

Hi Harb,

 

On Wed, 24 Mar 2021 at 11:39, Harb Abdulhamid OS 
mailto:abdulha...@os.amperecomputing.com> > 
wrote:

Hello Folks,

Appreciate the feedback and replies on this.  Glad to see that there is 
interest in this topic. 

 

I try to address the comments/feedback from Francois and Simon below….

 

 

RE: [TF-A] Proposal: TF-A to adopt hand-off blocks (HOBs) for information passing between boot stages

[Harb Abdulhamid OS]

Hello Folks,
Appreciate the feedback and replies on this.  Glad to see that there is 
interest in this topic. 

I try to address the comments/feedback from Francois and Simon below….

@François Ozog – happy to discuss this on a 
zoom call.  I will make that time slot work, and will be available to attend 
April 8, 4pm CT.

Note that I’m using the term “HOB” here more generically, as there are 
typically vendor specific structures beyond the resource descriptor HOB, which 
provides only a small subset of the information that needs to be passed between 
the boot phases.

The whole point here is to provide mechanism to develop firmware that we can 
build ARM Server SoC’s that support *any* BL33 payload (e.g. EDK2, AptioV, 
CoreBoot, and maybe even directly boot strapping LinuxBoot at some point).   In 
other-words, we are trying to come up with a TF-A that would be completely 
agnostic to the implementation of BL33 (i.e. BL33 is built completely 
independently by a separate entity – e.g. an ODM/OEM).

Keep in mind, in the server/datacenter market segment we are not building 
vertically integrated systems with a single entity compiling firmware/software 
stacks like most folks in TF-A have become use to.  There are two categories of 
higher level firmware code blobs in the server/datacenter model:

  1.  “SoC” or “silicon” firmware – in TF-A this may map to BL1, BL2, BL31, and 
*possibly* one or more BL32 instances
  2.  “Platform” or “board” firmware – in TF-A this may map to BL33 and 
*possibly* one or more BL32 instances.

Even the platform firmware stack could be further fragmented by having multiple 
entities involved in delivering the entire firmware stack: IBVs, ODMs, OEMs, 
CSPs, and possibly even device vendor code.

To support a broad range of platform designs with a broad range of memory 
devices, we need a crisp and clear contract between the SoC firmware that 
initializes memory (e.g. BL2) and how that platform boot firmware (e.g. BL33) 
gathers information about what memory that was initialized, at what speeds, 
NUMA topology, and many other relevant information that needs to be known and 
comprehended by the platform firmware and eventually by the platform software.

I understand the versatility of DT, but I see two major problems with DT:

  *   DT requires more complicated parsing to get properties, and even more 
complex to dynamically set properties – this HOB structures may need to be 
generated in boot phases where DDR is not available, and therefore we will be 
extremely memory constrained.
  *   DT is probably overkill for this purpose – We really just want a list of 
pointers to simple C structures that code cast (e.g. JEDEC SPD data blob)

I think that we should not mix the efforts around DT/ACPI specs with what we 
are doing here, because those specs and concepts were developed for a 
completely different purpose (i.e. abstractions needed for OS / RTOS software, 
and not necessarily suitable for firmware-to-firmware hand-offs).

Frankly, I would personally push back pretty hard on defining SMC’s for 
something that should be one way information passing.  Every SMC we add is 
another attack vector to the secure world and an increased burden on the folks 
that have to do security auditing and threat analysis.  I see no benefit in 
exposing these boot/HOB/BOB structures at run-time via SMC calls.

Please do let me know if you disagree and why.  Look forward to discussing on 
this thread or on the call.

@Simon Glass   - Thanks for the pointer to bloblist.  
 I briefly reviewed and it seems like a good baseline for what we may be 
looking for.

That being said, I would say that there is some benefit in having some kind of 
unique identifiers (e.g. UUID or some unique signature) so that we can tie 
standardized data structures (based on some future TBD specs) to a particular 
ID.  For example, if the TPM driver in BL33 is looking for the TPM structure in 
the HOB/BOB list, and may not care about the other data blobs.  The driver 
needs a way to identify and locate the blob it cares about.

I guess we can achieve this with the tag, but the problem with tag when you 
have eco-system with a lot of parties doing parallel development, you can end 
up with tag collisions and folks fighting about who has rights to what tag 
values.  We would need some official process for folks to register tags for 
whatever new structures we define, or maybe some tag range for vendor specific 
structures.  This comes with a lot of pain and bureaucracy.  On the other hand, 
UUID has been a proven way to make it easy to just define your own blobs with 
*either* standard or vendor specific structures without worry of ID collisions 
between vendors.

We can probably debate whether there is any value in GUID/UUID or not during 
the call… but again, boblist seems like a reasonable starting point as an 
alternative to HOB.

Thanks,
--Harb

From: François Ozog 

Re: Glitching protection

[Heinrich Schuchardt]

On 26.03.21 15:12, François Ozog 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).

Power glitches can induce changes in data, in code, and in CPU state.
Signing selected variables cannot be a sufficient counter-measure.

If you want to protect against power glitches, it seems more promising
to do so on the hardware side, e.g.

* provide circuitry that resets the board if a power-glitch or an
  electromagnetic interference is detected
* use ECC RAM

Best regards

Heinrich

>
> Are there any efforts planned around this ?
>
> Is it feasible to have a "library" that could be integrated in
> different projects?
>
> Cheers
>
> FF
> ___
> boot-architecture mailing list
> boot-architecture@lists.linaro.org
> https://lists.linaro.org/mailman/listinfo/boot-architecture
>

___
boot-architecture mailing list
boot-architecture@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/boot-architecture

Re: Firmware FuSa workshop

[François Ozog]

Le ven. 26 mars 2021 à 18:42, Heinrich Schuchardt  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-5XzbFkodXsiVNJJLUN88BgkiBu__D5KeE/edit
> >
> >-
> >
> >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.o...@linaro.org | Skype: ffozog
___
boot-architecture mailing list
boot-architecture@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/boot-architecture

Re: Firmware FuSa workshop

[Heinrich Schuchardt]

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.

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

___
boot-architecture mailing list
boot-architecture@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/boot-architecture

Re: [TF-A] Glitching protection

[Joanna Farley]

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" 
 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
t...@lists.trustedfirmware.org
https://lists.trustedfirmware.org/mailman/listinfo/tf-a

___
boot-architecture mailing list
boot-architecture@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/boot-architecture

Re: [TF-A] Proposal: TF-A to adopt hand-off blocks (HOBs) for information passing between boot stages

[Julius Werner]

Just want to point out that TF-A currently already supports a (very simple)
mechanism like this:

https://review.trustedfirmware.org/plugins/gitiles/TF-A/trusted-firmware-a/+/refs/heads/master/include/export/lib/bl_aux_params/bl_aux_params_exp.h
https://review.trustedfirmware.org/plugins/gitiles/TF-A/trusted-firmware-a/+/refs/heads/master/lib/bl_aux_params/bl_aux_params.c
https://review.trustedfirmware.org/plugins/gitiles/TF-A/trusted-firmware-a/+/refs/heads/master/plat/rockchip/common/params_setup.c

It's just a linked list of tagged elements. The tag space is split into
TF-A-wide generic tags and SiP-specific tags (with plenty of room to spare
if more areas need to be defined -- a 64-bit tag can fit a lot). This is
currently being used by some platforms that run coreboot in place of
BL1/BL2, to pass information from coreboot (BL2) to BL31.

I would echo Simon's sentiment of keeping this as simple as possible and
avoiding complicated and bloated data structures with UUIDs. You usually
want to parse something like this as early as possible in the passed-to
firmware stage, particularly if the structure encodes information about the
debug console (like it does for the platforms I mentioned above). For
example, in BL31 this basically means doing it right after moving from
assembly to C in bl31_early_platform_setup2() to get the console up before
running anything else. At that point in the BL31 initialization, the MMU
and caches are disabled, so data accesses are pretty expensive and you
don't want to spend a lot of parsing effort or calculate complicated
checksums or the like. You just want something extremely simple where you
ideally have to touch every data word only once.

On Wed, Mar 24, 2021 at 5:06 PM Simon Glass via TF-A <
t...@lists.trustedfirmware.org> wrote:

> Hi Harb,
>
> On Wed, 24 Mar 2021 at 11:39, Harb Abdulhamid OS <
> abdulha...@os.amperecomputing.com> wrote:
>
>> Hello Folks,
>>
>> Appreciate the feedback and replies on this.  Glad to see that there is
>> interest in this topic. 
>>
>>
>>
>> I try to address the comments/feedback from Francois and Simon below….
>>
>>
>>
>> @François Ozog  – happy to discuss this on a
>> zoom call.  I will make that time slot work, and will be available to
>> attend April 8, 4pm CT.
>>
>>
>>
>> Note that I’m using the term “HOB” here more generically, as there are
>> typically vendor specific structures beyond the resource descriptor HOB,
>> which provides only a small subset of the information that needs to be
>> passed between the boot phases.
>>
>>
>>
>> The whole point here is to provide mechanism to develop firmware that we
>> can build ARM Server SoC’s that support **any** BL33 payload (e.g. EDK2,
>> AptioV, CoreBoot, and maybe even directly boot strapping LinuxBoot at some
>> point).   In other-words, we are trying to come up with a TF-A that would
>> be completely agnostic to the implementation of BL33 (i.e. BL33 is built
>> completely independently by a separate entity – e.g. an ODM/OEM).
>>
>>
>>
>> Keep in mind, in the server/datacenter market segment we are not building
>> vertically integrated systems with a single entity compiling
>> firmware/software stacks like most folks in TF-A have become use to.  There
>> are two categories of higher level firmware code blobs in the
>> server/datacenter model:
>>
>>1. “SoC” or “silicon” firmware – in TF-A this may map to BL1, BL2,
>>BL31, and **possibly** one or more BL32 instances
>>2. “Platform” or “board” firmware – in TF-A this may map to BL33 and *
>>*possibly** one or more BL32 instances.
>>
>>
>>
>> Even the platform firmware stack could be further fragmented by having
>> multiple entities involved in delivering the entire firmware stack: IBVs,
>> ODMs, OEMs, CSPs, and possibly even device vendor code.
>>
>>
>>
>> To support a broad range of platform designs with a broad range of memory
>> devices, we need a crisp and clear contract between the SoC firmware that
>> initializes memory (e.g. BL2) and how that platform boot firmware (e.g.
>> BL33) gathers information about what memory that was initialized, at what
>> speeds, NUMA topology, and many other relevant information that needs to be
>> known and comprehended by the platform firmware and eventually by the
>> platform software.
>>
>>
>>
>> I understand the versatility of DT, but I see two major problems with DT:
>>
>>- DT requires more complicated parsing to get properties, and even
>>more complex to dynamically set properties – this HOB structures may need
>>to be generated in boot phases where DDR is not available, and therefore 
>> we
>>will be extremely memory constrained.
>>- DT is probably overkill for this purpose – We really just want a
>>list of pointers to simple C structures that code cast (e.g. JEDEC SPD 
>> data
>>blob)
>>
>>
>>
>> I think that we should not mix the efforts around DT/ACPI specs with what
>> we are doing here, because those specs and concepts were developed for a
>> 

Re: [TF-A] Proposal: TF-A to adopt hand-off blocks (HOBs) for information passing between boot stages

[Bill Fletcher]

Adding Andrea

On Wed, 24 Mar 2021 at 13:55, Joanna Farley via TF-A <
t...@lists.trustedfirmware.org> wrote:

> Hi Harb and others,
>
>
>
> This thread is now multi-mailing list and I can see some broader needs and
> opinions on aspects not directly defined by the TF-A project such as
> differing information exchange formats. However, this is definitely
> something the TF-A project can try and help provide enablement for to help
> with the goal of supplying support for single or common TF-A binaries builds
> for different images. TF-A already have some limited support in this space
> and are considering how this can be extended given some of the needs
> expressed here. Folks on the TF-A project are studying the below and will
> propose soon some ideas on how TF-A could provide more versatile enablement
> in this space shortly.
>
>
>
> Thanks
>
>
>
> Joanna
>
>
>
> *From: *TF-A  on behalf of
> François Ozog via TF-A 
> *Reply to: *François Ozog 
> *Date: *Wednesday, 24 March 2021 at 08:34
> *To: *Harb Abdulhamid OS 
> *Cc: *"t...@lists.trustedfirmware.org" ,
> Simon Glass , Boot Architecture Mailman List <
> boot-architecture@lists.linaro.org>, Paul Isaac's ,
> Ron Minnich 
> *Subject: *Re: [TF-A] Proposal: TF-A to adopt hand-off blocks (HOBs) for
> information passing between boot stages
>
>
>
>
>
>
>
> On Tue, 23 Mar 2021 at 23:39, Harb Abdulhamid OS <
> abdulha...@os.amperecomputing.com> wrote:
>
> Hello Folks,
>
> Appreciate the feedback and replies on this.  Glad to see that there is
> interest in this topic. 
>
>
>
> I try to address the comments/feedback from Francois and Simon below….
>
>
>
> @François Ozog  – happy to discuss this on a
> zoom call.  I will make that time slot work, and will be available to
> attend April 8, 4pm CT.
>
>
>
> Note that I’m using the term “HOB” here more generically, as there are
> typically vendor specific structures beyond the resource descriptor HOB,
> which provides only a small subset of the information that needs to be
> passed between the boot phases.
>
>
>
> The whole point here is to provide mechanism to develop firmware that we
> can build ARM Server SoC’s that support **any** BL33 payload (e.g. EDK2,
> AptioV, CoreBoot, and maybe even directly boot strapping LinuxBoot at some
> point).   In other-words, we are trying to come up with a TF-A that would
> be completely agnostic to the implementation of BL33 (i.e. BL33 is built
> completely independently by a separate entity – e.g. an ODM/OEM).
>
>
>
> Keep in mind, in the server/datacenter market segment we are not building
> vertically integrated systems with a single entity compiling
> firmware/software stacks like most folks in TF-A have become use to.  There
> are two categories of higher level firmware code blobs in the
> server/datacenter model:
>
>1. “SoC” or “silicon” firmware – in TF-A this may map to BL1, BL2,
>BL31, and **possibly** one or more BL32 instances
>2. “Platform” or “board” firmware – in TF-A this may map to BL33 and *
>*possibly** one or more BL32 instances.
>
>
>
> Even the platform firmware stack could be further fragmented by having
> multiple entities involved in delivering the entire firmware stack: IBVs,
> ODMs, OEMs, CSPs, and possibly even device vendor code.
>
>
>
> To support a broad range of platform designs with a broad range of memory
> devices, we need a crisp and clear contract between the SoC firmware that
> initializes memory (e.g. BL2) and how that platform boot firmware (e.g.
> BL33) gathers information about what memory that was initialized, at what
> speeds, NUMA topology, and many other relevant information that needs to be
> known and comprehended by the platform firmware and eventually by the
> platform software.
>
>
>
> I understand the versatility of DT, but I see two major problems with DT:
>
>- DT requires more complicated parsing to get properties, and even
>more complex to dynamically set properties – this HOB structures may need
>to be generated in boot phases where DDR is not available, and therefore we
>will be extremely memory constrained.
>- DT is probably overkill for this purpose – We really just want a
>list of pointers to simple C structures that code cast (e.g. JEDEC SPD data
>blob)
>
>
>
> I think that we should not mix the efforts around DT/ACPI specs with what
> we are doing here, because those specs and concepts were developed for a
> completely different purpose (i.e. abstractions needed for OS / RTOS
> software, and not necessarily suitable for firmware-to-firmware hand-offs).
>
>
>
> Frankly, I would personally push back pretty hard on defining SMC’s for
> something that should be one way information passing.  Every SMC we add is
> another attack vector to the secure world and an increased burden on the
> folks that have to do security auditing and threat analysis.  I see no
> benefit in exposing these boot/HOB/BOB structures at run-time via SMC
> calls.
>
>
>
> Please do let me know if you 

Re: [TF-A] Proposal: TF-A to adopt hand-off blocks (HOBs) for information passing between boot stages

[Joanna Farley]

Hi Harb and others,

This thread is now multi-mailing list and I can see some broader needs and 
opinions on aspects not directly defined by the TF-A project such as differing 
information exchange formats. However, this is definitely something the TF-A 
project can try and help provide enablement for to help with the goal of 
supplying support for single or common TF-A binaries builds for different 
images. TF-A already have some limited support in this space and are 
considering how this can be extended given some of the needs expressed here. 
Folks on the TF-A project are studying the below and will propose soon some 
ideas on how TF-A could provide more versatile enablement in this space shortly.

Thanks

Joanna

From: TF-A  on behalf of François Ozog 
via TF-A 
Reply to: François Ozog 
Date: Wednesday, 24 March 2021 at 08:34
To: Harb Abdulhamid OS 
Cc: "t...@lists.trustedfirmware.org" , Simon 
Glass , Boot Architecture Mailman List 
, Paul Isaac's , 
Ron Minnich 
Subject: Re: [TF-A] Proposal: TF-A to adopt hand-off blocks (HOBs) for 
information passing between boot stages



On Tue, 23 Mar 2021 at 23:39, Harb Abdulhamid OS 
mailto:abdulha...@os.amperecomputing.com>> 
wrote:
Hello Folks,
Appreciate the feedback and replies on this.  Glad to see that there is 
interest in this topic. 

I try to address the comments/feedback from Francois and Simon below….

@François Ozog – happy to discuss this on a 
zoom call.  I will make that time slot work, and will be available to attend 
April 8, 4pm CT.

Note that I’m using the term “HOB” here more generically, as there are 
typically vendor specific structures beyond the resource descriptor HOB, which 
provides only a small subset of the information that needs to be passed between 
the boot phases.

The whole point here is to provide mechanism to develop firmware that we can 
build ARM Server SoC’s that support *any* BL33 payload (e.g. EDK2, AptioV, 
CoreBoot, and maybe even directly boot strapping LinuxBoot at some point).   In 
other-words, we are trying to come up with a TF-A that would be completely 
agnostic to the implementation of BL33 (i.e. BL33 is built completely 
independently by a separate entity – e.g. an ODM/OEM).

Keep in mind, in the server/datacenter market segment we are not building 
vertically integrated systems with a single entity compiling firmware/software 
stacks like most folks in TF-A have become use to.  There are two categories of 
higher level firmware code blobs in the server/datacenter model:

  1.  “SoC” or “silicon” firmware – in TF-A this may map to BL1, BL2, BL31, and 
*possibly* one or more BL32 instances
  2.  “Platform” or “board” firmware – in TF-A this may map to BL33 and 
*possibly* one or more BL32 instances.

Even the platform firmware stack could be further fragmented by having multiple 
entities involved in delivering the entire firmware stack: IBVs, ODMs, OEMs, 
CSPs, and possibly even device vendor code.

To support a broad range of platform designs with a broad range of memory 
devices, we need a crisp and clear contract between the SoC firmware that 
initializes memory (e.g. BL2) and how that platform boot firmware (e.g. BL33) 
gathers information about what memory that was initialized, at what speeds, 
NUMA topology, and many other relevant information that needs to be known and 
comprehended by the platform firmware and eventually by the platform software.

I understand the versatility of DT, but I see two major problems with DT:

  *   DT requires more complicated parsing to get properties, and even more 
complex to dynamically set properties – this HOB structures may need to be 
generated in boot phases where DDR is not available, and therefore we will be 
extremely memory constrained.
  *   DT is probably overkill for this purpose – We really just want a list of 
pointers to simple C structures that code cast (e.g. JEDEC SPD data blob)

I think that we should not mix the efforts around DT/ACPI specs with what we 
are doing here, because those specs and concepts were developed for a 
completely different purpose (i.e. abstractions needed for OS / RTOS software, 
and not necessarily suitable for firmware-to-firmware hand-offs).

Frankly, I would personally push back pretty hard on defining SMC’s for 
something that should be one way information passing.  Every SMC we add is 
another attack vector to the secure world and an increased burden on the folks 
that have to do security auditing and threat analysis.  I see no benefit in 
exposing these boot/HOB/BOB structures at run-time via SMC calls.

Please do let me know if you disagree and why.  Look forward to discussing on 
this thread or on the call.

I am not tied to a particular data representation and using SMC to just pass 
data structures is overkill as you say. The SMC model seems useful to do 
complex things like device assignment to secure world. Or something else we 
don't have yet an idea.
Let's say there is one 

Firmware FuSa workshop

[François Ozog]

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
   

   -

   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.o...@linaro.org | Skype: ffozog
___
boot-architecture mailing list
boot-architecture@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/boot-architecture

Glitching protection

[François Ozog]

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
___
boot-architecture mailing list
boot-architecture@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/boot-architecture