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

[Julius Werner]

Hi Raghu,


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

Granted, I understand that different platforms have different requirements,
and there may not be a one-size-fits-all solution for this. But if you have
a system with a powerful CPU and lots of memory that doesn't care that much
about boot speed, why wouldn't you just use FDT? I thought FDT is already
established on many platforms to pass information between TF-A boot stages
today, and it should certainly be flexible enough to fill your needs. Most
of the earlier discussion in this thread seemed to focus on people wanting
a different mechanism besides FDT because FDT is complex and not performant
enough for all use cases, but then why would we replace it with a different
mechanism that also has complexity and performance problems?

Basically, as far as I'm aware there are two established mechanisms to pass
data between boot stages in TF-A today (some platforms, like Rockchip's,
even support both of them at once): passing an FDT and the bl_aux_params
linked list. They are intentionally on opposite ends of the complexity
spectrum because different platforms can have different needs. The question
is really just whether we need to add a third one, and whether that offers
anything that the other two can't already cover. I guess we can support the
exact UEFI HOB format just to make things easier for UEFI users, and maybe
that's okay, but it does add maintenance burden to TF-A to support so many
different things and we should at least consider if the UEFI part couldn't
just translate its stuff into an FDT instead. But mainly, the way this
thread started it sounded more like "we want to standardize on a new HOB
format that will be used by everyone", and for that goal, I think sticking
with what we have would make a lot more sense for TF-A. If UEFI HOB support
was added in addition then I think only UEFI users would really gain any
benefit from that, and that mechanism would only end up getting used by
UEFI platforms (which again, maybe that's okay, but I'm just saying I don't
think this is going to become some great new "one HOB format to rule them
all" design if it doesn't do anything better than the established FDT
format already does).


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

The bl_aux_params list elements don't need to have a fixed size. The only
common thing about each element is the tag (and the next pointer),
everything else (including size) is tag-specific. You can just define a new
tag where the next uint64_t after the next pointer defines the size of the
rest of the element or something like that. Heck, you can even have the
list element contain pointers to other random stuff in memory that isn't
directly part of the list. (The whole thing is not consecutive in memory
anyway. It's not designed to be a serializable, persistent thing like an
FDT blob, just something that a calling bootloader stage can quickly
assemble in its own memory right before handoff and that will only stay
valid until the next stage is done parsing it and starts reusing available
memory for its own purposes.)


> Clearly the solution below was tailored to coreboot.
>
>
Not really, it was just the simplest flexible design I could come up with
at the point. The APIs upstream is in the TF-A repo and coreboot (and other
software) can include it from there.
___
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

[Simon Glass]

Hi Grant,
On Mon, 29 Mar 2021 at 23:19, Grant Likely  wrote:
>
>
>
> On 29/03/2021 08:42, Simon Glass wrote:
>  > Hi Raghu,
>  >
>  > On Sat, 27 Mar 2021 at 03:59,  wrote:
>  >
>  >> 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.
>  >>
>  >
>  > Fair enough. I hope, though, that if we can agree on a simple
>  > implementation like bloblist, then it becomes the standard and we can
> move
>  > away from the problems you mention with UUIDs.
>
> Ummm... I don't follow. How are UUIDs either complex or bloated? A UUIDs
> is simply a 128 bit number that is matched using a fixed length compare.
>
> What I like about the UUID scheme is it has collision avoidance built
> in, and it is adopted across multiple projects.

It's partly the UUIDs and partly the code that results (see earlier in
thread). But this is off-topic really, so I won't continue here.

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

Re: Glitching protection

[Joakim Bech]

On Mon, Mar 29, 2021 at 03:02:21PM +0200, François Ozog wrote:
> On Mon, 29 Mar 2021 at 14:46, Heinrich Schuchardt 
> wrote:
> 
> > On 29.03.21 09:40, Joakim Bech wrote:
> > > Hi,
> > >
> > > On Fri, Mar 26, 2021 at 07:36:34PM +0100, Heinrich Schuchardt wrote:
> > >> 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
> > >>
> > > I agree and disagree. Hardware mitigations are probably better, but
> > > by applying software mitigations you can make it significantly harder to
> > > perform a successful SCA. Most glitching attacks use some kind of time
> > > offset from a known occurrence/event and then a single glitch. With
> > > software mitigations, you can introduce randomness and also write the
> > > code so it'd require multi-glitching attacks to make it a successful
> > > attack.
> > >
> > > The greatest challenge with this is to convince and educate maintainers
> > > that writing code that might look very weird actually makes sense in
> > > certain areas of the code base. SCA software mitigations is no silver
> > > bullet, but if you care deeply about security, then I think it's just
> > > yet another mitigation pattern that you should apply, just as everything
> > > else we're doing when it comes to trying to securing our products
> > > (signatures, ASLR, measured boot, canaries, constant time functions, etc
> > > etc ...).
> >
> > On devices that run the software completely from flash variables are a
> > main attack surface for power glitches.
> >
> > U-Boot and Linux run from memory. There the major attack surface are not
> > critical variables but the code itself.
> >
> > So while the approach taken on TF-M may fend off a significant
> > percentage of power glitch attacks on the devices using it this might
> > not hold true for U-Boot and Linux.
> >
> > Do any measurements analyzing the proportions of code, data, and CPU
> > involvement in successful power glitch attacks exist?
> >
> > Yes it was demoed by Riscure in a past Connect, I can't remember which
> one. Joakim may certainly be more specific.
> This demo triggered the concern with me and since then I have been
> monitoring advances in the topic. You may want to check
> https://www.riscure.com/uploads/2019/06/Riscure_Secure-Boot-Under-Attack-Simulation.pdf
> 

To give a real example, one of the first security issues reported [1] to
the OP-TEE project was the Bellcore attack [2] put in practice. Our
implementation wasn't using blinding [3], so the people reporting the
issue were able to recover the private key from OP-TEE running on the
HiKey device using SCA. They first scanned the device with different EM
probe antennas and when they found a location on the chip giving the
best signal they did an EM Fault Injection attack making the RSA-CRT
computations to give faulty signatures (with up to 50% repeatability).
With faulty signatures, a good signature and maths you'll be able to
recover the private key. The mitigation? A software mitigation. This was
running an Armv8-A where everything was up and running (including
Linux), i.e., certainly not a tiny M-class device running things from
flash.

Related to Riscure as Francois referred to. They held workshop days a
couple of months ago and majority of the talks was about glitching,
fault injection etc. I can't remember the details, but in one talk they
demoed a fault injection attack that had some percentage of success
rate. Then they introduced a couple of software mitigation patterns one
by one and at the end IIRC the success rate was almost zero (if not
zero).

I fully agree with Ard. Even though you can abstract certain things into
libraries and helper functions, it's in my opinion not a "create a lib
and enable it and you're secure" operation. I think software mitigation
patterns should be carefully applied around sensitive operations. But as
said it needs some education and motivation to why you should do it.
From a logical view on the code it doesn't make sense to do identical
"if" checks twice in the same function. But from a SCA mitigation point
of view it can actually make sense.

Re: Glitching protection

[François Ozog]

On Mon, 29 Mar 2021 at 15:23, Ard Biesheuvel  wrote:

> On Fri, 26 Mar 2021 at 19:36, Heinrich Schuchardt 
> wrote:
> >
> > 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
> >
>
> Of course it is more promising to do this on the hardware side, nobody
> is debating that. Whether it makes sense to harden the software as
> well is completely orthogonal to that: on hardened hardware, it adds
> another layer of protection, and on hardware that cannot be hardened
> for some reason (cost, or more often, the fact that it has already
> shipped), it adds a layer of protection where no protection whatsoever
> was available beforehand.
>
> However, I do share some of your skepticism: incorporation of these
> techniques is not trivial, and commoditizing it by dropping it into
> some library that you can link your software against is *not* what I
> would prefer to see. This only encourages a check the box mentality,
> where people either assume that having the library makes everything
> magically secure, or ($DEITY forbid), it gets sucked into the MISRAs
> or FIPSes of this world, and it becomes a certification requirement,
> and using the library is mandatory, regardless of whether there is a
> point to it, or whether it is being used in the right way.
>
> So I'd be more interested in seeing how the underlying methods can be
> applied more widely, and not how it gets shrinkwrapped and shipped
> with a .h file without any need on the part of the developer to
> understand what really goes on under the hood.
>
>  I also think this is first about guidelines with a set of helpers.

For instance, lets consider:

if (checkstuff(input)==0)
{
dostuff();
}

It Can be transformed into something like (yet insufficient to be really
protected but that's gives an idea, more to be read in the TFM code and
readme.md)
/* SUCCESS is an arbitrary value != 0 as 0 is a typical value of a register
when glitched */
if (checkstuff(input, ) == SUCCESS)
{
letwaitarandomdelay();
if (doublecheck_successful_result(input, result) == SUCCESS)
{
/* this code is not protected against PC attacks */
dostuff();
}

-- 
> Ard.
>


-- 
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: Glitching protection

[Heinrich Schuchardt]

On 29.03.21 15:02, François Ozog wrote:
>
>
> On Mon, 29 Mar 2021 at 14:46, Heinrich Schuchardt  > wrote:
>
> On 29.03.21 09:40, Joakim Bech wrote:
> > Hi,
> >
> > On Fri, Mar 26, 2021 at 07:36:34PM +0100, Heinrich Schuchardt wrote:
> >> 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
> >>
> > I agree and disagree. Hardware mitigations are probably better, but
> > by applying software mitigations you can make it significantly
> harder to
> > perform a successful SCA. Most glitching attacks use some kind of time
> > offset from a known occurrence/event and then a single glitch. With
> > software mitigations, you can introduce randomness and also write the
> > code so it'd require multi-glitching attacks to make it a successful
> > attack.
> >
> > The greatest challenge with this is to convince and educate
> maintainers
> > that writing code that might look very weird actually makes sense in
> > certain areas of the code base. SCA software mitigations is no silver
> > bullet, but if you care deeply about security, then I think it's just
> > yet another mitigation pattern that you should apply, just as
> everything
> > else we're doing when it comes to trying to securing our products
> > (signatures, ASLR, measured boot, canaries, constant time
> functions, etc
> > etc ...).
>
> On devices that run the software completely from flash variables are a
> main attack surface for power glitches.
>
> U-Boot and Linux run from memory. There the major attack surface are not
> critical variables but the code itself.
>
> So while the approach taken on TF-M may fend off a significant
> percentage of power glitch attacks on the devices using it this might
> not hold true for U-Boot and Linux.
>
> Do any measurements analyzing the proportions of code, data, and CPU
> involvement in successful power glitch attacks exist?
>
> Yes it was demoed by Riscure in a past Connect, I can't remember which
> one. Joakim may certainly be more specific.
> This demo triggered the concern with me and since then I have been
> monitoring advances in the topic. You may want to
> check 
> https://www.riscure.com/uploads/2019/06/Riscure_Secure-Boot-Under-Attack-Simulation.pdf
> 

Thanks for the reference.

The slides (75, 121) indicate that the major attack surface is changed
code not changed variables.

The TF-M patches mentioned above focus on validating variables and
introducing random delays when accessing them.

Riscures' emphasis on simulation suggests that it is not trivial to
design code that is resilient to power glitches. Some design principles
are provided in
https://www.riscure.com/uploads/2018/11/201708_Riscure_Whitepaper_Side_Channel_Patterns.pdf.

Best regards

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

Re: Glitching protection

[Ard Biesheuvel]

On Fri, 26 Mar 2021 at 19:36, Heinrich Schuchardt  wrote:
>
> 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
>

Of course it is more promising to do this on the hardware side, nobody
is debating that. Whether it makes sense to harden the software as
well is completely orthogonal to that: on hardened hardware, it adds
another layer of protection, and on hardware that cannot be hardened
for some reason (cost, or more often, the fact that it has already
shipped), it adds a layer of protection where no protection whatsoever
was available beforehand.

However, I do share some of your skepticism: incorporation of these
techniques is not trivial, and commoditizing it by dropping it into
some library that you can link your software against is *not* what I
would prefer to see. This only encourages a check the box mentality,
where people either assume that having the library makes everything
magically secure, or ($DEITY forbid), it gets sucked into the MISRAs
or FIPSes of this world, and it becomes a certification requirement,
and using the library is mandatory, regardless of whether there is a
point to it, or whether it is being used in the right way.

So I'd be more interested in seeing how the underlying methods can be
applied more widely, and not how it gets shrinkwrapped and shipped
with a .h file without any need on the part of the developer to
understand what really goes on under the hood.

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

Re: Glitching protection

[François Ozog]

On Mon, 29 Mar 2021 at 14:46, Heinrich Schuchardt 
wrote:

> On 29.03.21 09:40, Joakim Bech wrote:
> > Hi,
> >
> > On Fri, Mar 26, 2021 at 07:36:34PM +0100, Heinrich Schuchardt wrote:
> >> 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
> >>
> > I agree and disagree. Hardware mitigations are probably better, but
> > by applying software mitigations you can make it significantly harder to
> > perform a successful SCA. Most glitching attacks use some kind of time
> > offset from a known occurrence/event and then a single glitch. With
> > software mitigations, you can introduce randomness and also write the
> > code so it'd require multi-glitching attacks to make it a successful
> > attack.
> >
> > The greatest challenge with this is to convince and educate maintainers
> > that writing code that might look very weird actually makes sense in
> > certain areas of the code base. SCA software mitigations is no silver
> > bullet, but if you care deeply about security, then I think it's just
> > yet another mitigation pattern that you should apply, just as everything
> > else we're doing when it comes to trying to securing our products
> > (signatures, ASLR, measured boot, canaries, constant time functions, etc
> > etc ...).
>
> On devices that run the software completely from flash variables are a
> main attack surface for power glitches.
>
> U-Boot and Linux run from memory. There the major attack surface are not
> critical variables but the code itself.
>
> So while the approach taken on TF-M may fend off a significant
> percentage of power glitch attacks on the devices using it this might
> not hold true for U-Boot and Linux.
>
> Do any measurements analyzing the proportions of code, data, and CPU
> involvement in successful power glitch attacks exist?
>
> Yes it was demoed by Riscure in a past Connect, I can't remember which
one. Joakim may certainly be more specific.
This demo triggered the concern with me and since then I have been
monitoring advances in the topic. You may want to check
https://www.riscure.com/uploads/2019/06/Riscure_Secure-Boot-Under-Attack-Simulation.pdf

Best regards
>
> Heinrich
>


-- 
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: Glitching protection

[Heinrich Schuchardt]

On 29.03.21 09:40, Joakim Bech wrote:
> Hi,
>
> On Fri, Mar 26, 2021 at 07:36:34PM +0100, Heinrich Schuchardt wrote:
>> 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
>>
> I agree and disagree. Hardware mitigations are probably better, but
> by applying software mitigations you can make it significantly harder to
> perform a successful SCA. Most glitching attacks use some kind of time
> offset from a known occurrence/event and then a single glitch. With
> software mitigations, you can introduce randomness and also write the
> code so it'd require multi-glitching attacks to make it a successful
> attack.
>
> The greatest challenge with this is to convince and educate maintainers
> that writing code that might look very weird actually makes sense in
> certain areas of the code base. SCA software mitigations is no silver
> bullet, but if you care deeply about security, then I think it's just
> yet another mitigation pattern that you should apply, just as everything
> else we're doing when it comes to trying to securing our products
> (signatures, ASLR, measured boot, canaries, constant time functions, etc
> etc ...).

On devices that run the software completely from flash variables are a
main attack surface for power glitches.

U-Boot and Linux run from memory. There the major attack surface are not
critical variables but the code itself.

So while the approach taken on TF-M may fend off a significant
percentage of power glitch attacks on the devices using it this might
not hold true for U-Boot and Linux.

Do any measurements analyzing the proportions of code, data, and CPU
involvement in successful power glitch attacks exist?

Best regards

Heinrich
___
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

[Grant Likely]

On 29/03/2021 08:42, Simon Glass wrote:
> Hi Raghu,
>
> On Sat, 27 Mar 2021 at 03:59,  wrote:
>
>> 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.
>>
>
> Fair enough. I hope, though, that if we can agree on a simple
> implementation like bloblist, then it becomes the standard and we can
move
> away from the problems you mention with UUIDs.

Ummm... I don't follow. How are UUIDs either complex or bloated? A UUIDs
is simply a 128 bit number that is matched using a fixed length compare.

What I like about the UUID scheme is it has collision avoidance built
in, and it is adopted across multiple projects.

g.
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
boot-architecture mailing list
boot-architecture@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/boot-architecture

RE: [TF-A] Firmware FuSa workshop

[Miklos Balint]

To += op-...@lists.trustedfirmware.org

From: TF-A  On Behalf Of François Ozog 
via TF-A
Sent: 26 March 2021 19:08
To: Heinrich Schuchardt 
Cc: t...@lists.trustedfirmware.org; Boot Architecture Mailman List 
; Ilias Apalodimas 

Subject: Re: [TF-A] Firmware FuSa workshop



Le ven. 26 mars 2021 à 18:42, Heinrich Schuchardt 
mailto:xypron.g...@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
>
> 
>-
>
>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=download]
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: [TF-A] Proposal: TF-A to adopt hand-off blocks (HOBs) for information passing between boot stages

[Simon Glass]

Hi Raghu,

On Sat, 27 Mar 2021 at 03:59,  wrote:

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

Fair enough. I hope, though, that if we can agree on a simple
implementation like bloblist, then it becomes the standard and we can move
away from the problems you mention with UUIDs.

I do find it odd, but even the latest SoCs often seem to start up in a mode
with limited memory and not at full speed. I also find that many projects
don't care a whit about boot speed, but others care a lot.


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

I've not looked at UEFI code recently...I think it was 6 years ago. It
really was not something I wondered to get involved in. I suspect it has
improved a lot. The HOB data structure is not that complicated (apart from
the UUIDs) and not all that different to bloblist. But turning it around,
wouldn't you prefer to use some simple code that is easy to read and has a
good set of unit tests?


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

Well the API does allow any length to be created:

void *bloblist_add(uint tag, int size, int align);

Typically the data structures are defined across boundaries though, such
that (e.g.) a C struct is shared. I suppose the length might change if you
are passing a console log.


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

Turning that around, must all open-source platforms use UEFI
features, APIs, data structures, etc? It could be useful for UEFI to learn
a bit about interoperability and fit in with some of the open-source
solutions. BTW the bloblist is actually a U-Boot thing, although yes indeed
it is inspired by open-source.


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

Yes OK. I am not sure I can attend tomorrow's call, but we'll see.

Regards,
Simon

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

Re: Glitching protection

[Joakim Bech]

Hi,

On Fri, Mar 26, 2021 at 07:36:34PM +0100, Heinrich Schuchardt wrote:
> 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
> 
I agree and disagree. Hardware mitigations are probably better, but
by applying software mitigations you can make it significantly harder to
perform a successful SCA. Most glitching attacks use some kind of time
offset from a known occurrence/event and then a single glitch. With
software mitigations, you can introduce randomness and also write the
code so it'd require multi-glitching attacks to make it a successful
attack.

The greatest challenge with this is to convince and educate maintainers
that writing code that might look very weird actually makes sense in
certain areas of the code base. SCA software mitigations is no silver
bullet, but if you care deeply about security, then I think it's just
yet another mitigation pattern that you should apply, just as everything
else we're doing when it comes to trying to securing our products
(signatures, ASLR, measured boot, canaries, constant time functions, etc
etc ...).

Regards,
Joakim

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