[U-Boot] U-Boot, cache speculation side channel attacks and ARM

[U-Boot] U-Boot, cache speculation side channel attacks and ARM

[Tom Rini]

Hey all,

So, now that things have quieted down a little bit in this area, I've
been wondering about something.  Over on the U-Boot side of things, are
there changes we need to make in order to support the kernel side of the
various mitigations properly?  I know that for example currently
https://developer.arm.com/support/security-update talks about ATF
patches, in the context of AArch64 however.  But on the other hand for
variant 2, there's nothing listed on the Linux side for 32bit ARM, but
there is for non-Linux OSes.

And, in the event I'm also missing something else entirely that we need
to do here, is there something that we need to be doing?  Or is it still
too early at this point in time to know?

Thanks all!

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20180119/265738b6/attachment.sig>

[U-Boot] U-Boot, cache speculation side channel attacks and ARM

[Mark Kettenis]

> Date: Fri, 19 Jan 2018 16:56:14 -0500
> From: Tom Rini <trini@konsulko.com>
> 
> Hey all,
> 
> So, now that things have quieted down a little bit in this area, I've
> been wondering about something.  Over on the U-Boot side of things, are
> there changes we need to make in order to support the kernel side of the
> various mitigations properly?  I know that for example currently
> https://developer.arm.com/support/security-update talks about ATF
> patches, in the context of AArch64 however.  But on the other hand for
> variant 2, there's nothing listed on the Linux side for 32bit ARM, but
> there is for non-Linux OSes.
> 
> And, in the event I'm also missing something else entirely that we need
> to do here, is there something that we need to be doing?  Or is it still
> too early at this point in time to know?

I think that for AArch32, the following bit advice is relevant:

  For Cortex-A15, set ACTLR[0]==1 from early initialization of the
  processor, and invalidate the branch predictor by performing an
  ICIALLU instruction.

For now OpenBSD assumes that "the firmware" sets ACTLR[0] since this
register may be read-only in non-secure mode.  And unless I missed
something Linux makes the same assumption.

If U-Boot provides the PSCI implementation it should probably flush
the BTB on affected 32-bit processors and should defenitely flush on
64-bit processors.

[U-Boot] U-Boot, cache speculation side channel attacks and ARM

[Nishanth Menon]

On 01/19/2018 04:21 PM, Mark Kettenis wrote:
>> Date: Fri, 19 Jan 2018 16:56:14 -0500
>> From: Tom Rini <trini@konsulko.com>
>>
>> Hey all,
>>
>> So, now that things have quieted down a little bit in this area, I've
>> been wondering about something.  Over on the U-Boot side of things, are
>> there changes we need to make in order to support the kernel side of the
>> various mitigations properly?  I know that for example currently
>> https://developer.arm.com/support/security-update talks about ATF
>> patches, in the context of AArch64 however.  But on the other hand for
>> variant 2, there's nothing listed on the Linux side for 32bit ARM, but
>> there is for non-Linux OSes.
>>
>> And, in the event I'm also missing something else entirely that we need
>> to do here, is there something that we need to be doing?  Or is it still
>> too early at this point in time to know?
> 
> I think that for AArch32, the following bit advice is relevant:
> 
>    For Cortex-A15, set ACTLR[0]==1 from early initialization of the
>    processor, and invalidate the branch predictor by performing an
>    ICIALLU instruction.
> 
> For now OpenBSD assumes that "the firmware" sets ACTLR[0] since this
> register may be read-only in non-secure mode.  And unless I missed
> something Linux makes the same assumption.
> 
> If U-Boot provides the PSCI implementation it should probably flush
> the BTB on affected 32-bit processors and should defenitely flush on
> 64-bit processors.

Seeing the traffic in kernel, I think I understand these two I know of 
at least?

A8/9/12/17:
"So without IBE set, as the comments above say, the flush won't do 
anything."
https://marc.info/?l=linux-arm-kernel&m=151566145121435&w=2

A15: ACTLR
https://marc.info/?l=linux-arm-kernel&m=151562519425981&w=2

Am I misunderstanding the list we need to do in u-boot?

-- 
Regards,
Nishanth Menon

[U-Boot] U-Boot, cache speculation side channel attacks and ARM

[Michael Nazzareno Trimarchi]

Hi Nishanth

On Sat, Jan 20, 2018 at 12:10 AM, Nishanth Menon <nm@ti.com> wrote:
> On 01/19/2018 04:21 PM, Mark Kettenis wrote:
>>>
>>> Date: Fri, 19 Jan 2018 16:56:14 -0500
>>> From: Tom Rini <trini@konsulko.com>
>>>
>>> Hey all,
>>>
>>> So, now that things have quieted down a little bit in this area, I've
>>> been wondering about something.  Over on the U-Boot side of things, are
>>> there changes we need to make in order to support the kernel side of the
>>> various mitigations properly?  I know that for example currently
>>> https://developer.arm.com/support/security-update talks about ATF
>>> patches, in the context of AArch64 however.  But on the other hand for
>>> variant 2, there's nothing listed on the Linux side for 32bit ARM, but
>>> there is for non-Linux OSes.
>>>
>>> And, in the event I'm also missing something else entirely that we need
>>> to do here, is there something that we need to be doing?  Or is it still
>>> too early at this point in time to know?
>>
>>
>> I think that for AArch32, the following bit advice is relevant:
>>
>>    For Cortex-A15, set ACTLR[0]==1 from early initialization of the
>>    processor, and invalidate the branch predictor by performing an
>>    ICIALLU instruction.
>>
>> For now OpenBSD assumes that "the firmware" sets ACTLR[0] since this
>> register may be read-only in non-secure mode.  And unless I missed
>> something Linux makes the same assumption.
>>
>> If U-Boot provides the PSCI implementation it should probably flush
>> the BTB on affected 32-bit processors and should defenitely flush on
>> 64-bit processors.
>
>
> Seeing the traffic in kernel, I think I understand these two I know of at
> least?
>
> A8/9/12/17:
> "So without IBE set, as the comments above say, the flush won't do
> anything."

Regarding IBE set, is this can be set later on boot stage after MLO?

Michael

> https://marc.info/?l=linux-arm-kernel&m=151566145121435&w=2
>
> A15: ACTLR
> https://marc.info/?l=linux-arm-kernel&m=151562519425981&w=2
>
> Am I misunderstanding the list we need to do in u-boot?
>
> --
> Regards,
> Nishanth Menon
>
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> https://lists.denx.de/listinfo/u-boot



-- 
| Michael Nazzareno Trimarchi                     Amarula Solutions BV |
| COO  -  Founder                                      Cruquiuskade 47 |
| +31(0)851119172                                 Amsterdam 1018 AM NL |
|                  [`as] http://www.amarulasolutions.com               |

[U-Boot] U-Boot, cache speculation side channel attacks and ARM

[Marc Zyngier]

On Fri, 19 Jan 2018 16:56:14 -0500
Tom Rini <trini@konsulko.com> wrote:

> Hey all,
> 
> So, now that things have quieted down a little bit in this area, I've
> been wondering about something.  Over on the U-Boot side of things, are
> there changes we need to make in order to support the kernel side of the
> various mitigations properly?  I know that for example currently
> https://developer.arm.com/support/security-update talks about ATF
> patches, in the context of AArch64 however.  But on the other hand for
> variant 2, there's nothing listed on the Linux side for 32bit ARM, but
> there is for non-Linux OSes.
> 
> And, in the event I'm also missing something else entirely that we need
> to do here, is there something that we need to be doing?  Or is it still
> too early at this point in time to know?

I've so far posted two revisions of a small patch series that deals
with variant-2 on the affected 32bit Cortex-A cores. These patches are
currently stashed on the branch[1] pointed at by the web page you
mentioned.

A prerequisite for Cortex-A8 and A15 is that ACTLR[0] (IBE) is set from
secure mode. Cortex-A12/A17 do not need this.

Thanks,

	M.

[1] https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git/log/?h=kpti
-- 
Without deviation from the norm, progress is not possible.

[U-Boot] U-Boot, cache speculation side channel attacks and ARM

[Marc Zyngier]

On Fri, 19 Jan 2018 17:10:04 -0600
Nishanth Menon <nm@ti.com> wrote:

> On 01/19/2018 04:21 PM, Mark Kettenis wrote:
> >> Date: Fri, 19 Jan 2018 16:56:14 -0500
> >> From: Tom Rini <trini@konsulko.com>
> >>
> >> Hey all,
> >>
> >> So, now that things have quieted down a little bit in this area, I've
> >> been wondering about something.  Over on the U-Boot side of things, are
> >> there changes we need to make in order to support the kernel side of the
> >> various mitigations properly?  I know that for example currently
> >> https://developer.arm.com/support/security-update talks about ATF
> >> patches, in the context of AArch64 however.  But on the other hand for
> >> variant 2, there's nothing listed on the Linux side for 32bit ARM, but
> >> there is for non-Linux OSes.
> >>
> >> And, in the event I'm also missing something else entirely that we need
> >> to do here, is there something that we need to be doing?  Or is it still
> >> too early at this point in time to know?  
> > 
> > I think that for AArch32, the following bit advice is relevant:
> > 
> >    For Cortex-A15, set ACTLR[0]==1 from early initialization of the
> >    processor, and invalidate the branch predictor by performing an
> >    ICIALLU instruction.
> > 
> > For now OpenBSD assumes that "the firmware" sets ACTLR[0] since this
> > register may be read-only in non-secure mode.  And unless I missed
> > something Linux makes the same assumption.
> > 
> > If U-Boot provides the PSCI implementation it should probably flush
> > the BTB on affected 32-bit processors and should defenitely flush on
> > 64-bit processors.  
> 
> Seeing the traffic in kernel, I think I understand these two I know of 
> at least?
> 
> A8/9/12/17:
> "So without IBE set, as the comments above say, the flush won't do 
> anything."
> https://marc.info/?l=linux-arm-kernel&m=151566145121435&w=2

This applies to A8 only. A9/A12/A17 do not need any additional settings
for BPIALL to work correctly.

> A15: ACTLR
> https://marc.info/?l=linux-arm-kernel&m=151562519425981&w=2
> 
> Am I misunderstanding the list we need to do in u-boot?
> 

A15 requires IBE to be set for ICIALLU to invalidate the branch
predictor.

Thanks,

	M.
-- 
Without deviation from the norm, progress is not possible.

[U-Boot] U-Boot, cache speculation side channel attacks and ARM

[Michael Nazzareno Trimarchi]

Hi Marc

On Sat, Jan 20, 2018 at 11:42 AM, Marc Zyngier <marc.zyngier@arm.com> wrote:
> On Fri, 19 Jan 2018 16:56:14 -0500
> Tom Rini <trini@konsulko.com> wrote:
>
>> Hey all,
>>
>> So, now that things have quieted down a little bit in this area, I've
>> been wondering about something.  Over on the U-Boot side of things, are
>> there changes we need to make in order to support the kernel side of the
>> various mitigations properly?  I know that for example currently
>> https://developer.arm.com/support/security-update talks about ATF
>> patches, in the context of AArch64 however.  But on the other hand for
>> variant 2, there's nothing listed on the Linux side for 32bit ARM, but
>> there is for non-Linux OSes.
>>
>> And, in the event I'm also missing something else entirely that we need
>> to do here, is there something that we need to be doing?  Or is it still
>> too early at this point in time to know?
>
> I've so far posted two revisions of a small patch series that deals
> with variant-2 on the affected 32bit Cortex-A cores. These patches are
> currently stashed on the branch[1] pointed at by the web page you
> mentioned.
>
> A prerequisite for Cortex-A8 and A15 is that ACTLR[0] (IBE) is set from
> secure mode. Cortex-A12/A17 do not need this.

So IBE is not a pre-requisite for Cortex A9 family. Is this correct?

I have already back--ported those patches on kernel 3.4. Is those enough?

Michael

>
> Thanks,
>
>         M.
>
> [1] https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git/log/?h=kpti
> --
> Without deviation from the norm, progress is not possible.
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> https://lists.denx.de/listinfo/u-boot



-- 
| Michael Nazzareno Trimarchi                     Amarula Solutions BV |
| COO  -  Founder                                      Cruquiuskade 47 |
| +31(0)851119172                                 Amsterdam 1018 AM NL |
|                  [`as] http://www.amarulasolutions.com               |

[U-Boot] U-Boot, cache speculation side channel attacks and ARM

[Marc Zyngier]

On Fri, 19 Jan 2018 23:21:44 +0100
Mark Kettenis <mark.kettenis@xs4all.nl> wrote:

> > Date: Fri, 19 Jan 2018 16:56:14 -0500
> > From: Tom Rini <trini@konsulko.com>
> > 
> > Hey all,
> > 
> > So, now that things have quieted down a little bit in this area, I've
> > been wondering about something.  Over on the U-Boot side of things, are
> > there changes we need to make in order to support the kernel side of the
> > various mitigations properly?  I know that for example currently
> > https://developer.arm.com/support/security-update talks about ATF
> > patches, in the context of AArch64 however.  But on the other hand for
> > variant 2, there's nothing listed on the Linux side for 32bit ARM, but
> > there is for non-Linux OSes.
> > 
> > And, in the event I'm also missing something else entirely that we need
> > to do here, is there something that we need to be doing?  Or is it still
> > too early at this point in time to know?  
> 
> I think that for AArch32, the following bit advice is relevant:
> 
>   For Cortex-A15, set ACTLR[0]==1 from early initialization of the
>   processor, and invalidate the branch predictor by performing an
>   ICIALLU instruction.
> 
> For now OpenBSD assumes that "the firmware" sets ACTLR[0] since this
> register may be read-only in non-secure mode.  And unless I missed
> something Linux makes the same assumption.

Indeed. This bit is only writeable from the secure side, and we assume
that Linux runs on the non-secure side.

> If U-Boot provides the PSCI implementation it should probably flush
> the BTB on affected 32-bit processors and should defenitely flush on
> 64-bit processors.

If U-Boot implements the secure firmware, then it should invalidate the
BTB on entry to Monitor mode (AArch32) or EL3 (AArch64), before taking
any branch. That's only for the affected CPUs, of course, and you
probably don't want to do it for unaffected parts.

Thanks,

	M.
-- 
Without deviation from the norm, progress is not possible.

[U-Boot] U-Boot, cache speculation side channel attacks and ARM

[Marc Zyngier]

On Sat, 20 Jan 2018 11:45:08 +0100
Michael Nazzareno Trimarchi <michael@amarulasolutions.com> wrote:

> Hi Marc
> 
> On Sat, Jan 20, 2018 at 11:42 AM, Marc Zyngier <marc.zyngier@arm.com> wrote:
> > On Fri, 19 Jan 2018 16:56:14 -0500
> > Tom Rini <trini@konsulko.com> wrote:
> >  
> >> Hey all,
> >>
> >> So, now that things have quieted down a little bit in this area, I've
> >> been wondering about something.  Over on the U-Boot side of things, are
> >> there changes we need to make in order to support the kernel side of the
> >> various mitigations properly?  I know that for example currently
> >> https://developer.arm.com/support/security-update talks about ATF
> >> patches, in the context of AArch64 however.  But on the other hand for
> >> variant 2, there's nothing listed on the Linux side for 32bit ARM, but
> >> there is for non-Linux OSes.
> >>
> >> And, in the event I'm also missing something else entirely that we need
> >> to do here, is there something that we need to be doing?  Or is it still
> >> too early at this point in time to know?  
> >
> > I've so far posted two revisions of a small patch series that deals
> > with variant-2 on the affected 32bit Cortex-A cores. These patches are
> > currently stashed on the branch[1] pointed at by the web page you
> > mentioned.
> >
> > A prerequisite for Cortex-A8 and A15 is that ACTLR[0] (IBE) is set from
> > secure mode. Cortex-A12/A17 do not need this.  
> 
> So IBE is not a pre-requisite for Cortex A9 family. Is this correct?

Indeed. I'm not even sure A9 has that bit at all (ACTLR is
implementation specific). BPIALL works on A9 without any other setting.

> I have already back--ported those patches on kernel 3.4. Is those enough?

Define enough. These patches allow these CPUs to cope with variant-2,
and only variant-2. Variant-1 is still work in progress across all
architectures, variant-3 (aka Meltdown) doesn't concern 32bit ARM
implementations, and only A15 is susceptible to variant-3a.

Thanks,

	M.
-- 
Without deviation from the norm, progress is not possible.

[U-Boot] U-Boot, cache speculation side channel attacks and ARM

[Michael Nazzareno Trimarchi]

Hi

On Sat, Jan 20, 2018 at 12:31 PM, Marc Zyngier <marc.zyngier@arm.com> wrote:
> On Sat, 20 Jan 2018 11:45:08 +0100
> Michael Nazzareno Trimarchi <michael@amarulasolutions.com> wrote:
>
>> Hi Marc
>>
>> On Sat, Jan 20, 2018 at 11:42 AM, Marc Zyngier <marc.zyngier@arm.com> wrote:
>> > On Fri, 19 Jan 2018 16:56:14 -0500
>> > Tom Rini <trini@konsulko.com> wrote:
>> >
>> >> Hey all,
>> >>
>> >> So, now that things have quieted down a little bit in this area, I've
>> >> been wondering about something.  Over on the U-Boot side of things, are
>> >> there changes we need to make in order to support the kernel side of the
>> >> various mitigations properly?  I know that for example currently
>> >> https://developer.arm.com/support/security-update talks about ATF
>> >> patches, in the context of AArch64 however.  But on the other hand for
>> >> variant 2, there's nothing listed on the Linux side for 32bit ARM, but
>> >> there is for non-Linux OSes.
>> >>
>> >> And, in the event I'm also missing something else entirely that we need
>> >> to do here, is there something that we need to be doing?  Or is it still
>> >> too early at this point in time to know?
>> >
>> > I've so far posted two revisions of a small patch series that deals
>> > with variant-2 on the affected 32bit Cortex-A cores. These patches are
>> > currently stashed on the branch[1] pointed at by the web page you
>> > mentioned.
>> >
>> > A prerequisite for Cortex-A8 and A15 is that ACTLR[0] (IBE) is set from
>> > secure mode. Cortex-A12/A17 do not need this.
>>
>> So IBE is not a pre-requisite for Cortex A9 family. Is this correct?
>
> Indeed. I'm not even sure A9 has that bit at all (ACTLR is
> implementation specific). BPIALL works on A9 without any other setting.
>
>> I have already back--ported those patches on kernel 3.4. Is those enough?
>
> Define enough. These patches allow these CPUs to cope with variant-2,
> and only variant-2. Variant-1 is still work in progress across all
> architectures, variant-3 (aka Meltdown) doesn't concern 32bit ARM
> implementations, and only A15 is susceptible to variant-3a.
>

Just talking on variant-2 . If I understand for the variant 1 people
are working on
compiler side. Problem is that sometime It's not possible to
re-compile userspace for the pre-build
userspace library provide by the vendor.

Michael

> Thanks,
>
>         M.
> --
> Without deviation from the norm, progress is not possible.



-- 
| Michael Nazzareno Trimarchi                     Amarula Solutions BV |
| COO  -  Founder                                      Cruquiuskade 47 |
| +31(0)851119172                                 Amsterdam 1018 AM NL |
|                  [`as] http://www.amarulasolutions.com               |

[U-Boot] U-Boot, cache speculation side channel attacks and ARM

[Russell King]

On Sat, Jan 20, 2018 at 11:31:19AM +0000, Marc Zyngier wrote:
> Define enough. These patches allow these CPUs to cope with variant-2,
> and only variant-2. Variant-1 is still work in progress across all
> architectures, variant-3 (aka Meltdown) doesn't concern 32bit ARM
> implementations, and only A15 is susceptible to variant-3a.

I think you need to be really careful about statements like this.

As you know, it is possible to run a 32bit environment in a VM on
the 64bit CPUs.  So, its entirely possible to run a 32bit setup
on a Cortex A72 for example, and that means such a setup _is_
vulnerable to variant 3a.

Do people do this?  That isn't something we can really know, but
I think as long as its allowed, you can bet that someone will,
and someone will end up using it in a production environment.

So, it can't be ignored.

-- 
Russell King

[U-Boot] U-Boot, cache speculation side channel attacks and ARM

[Marc Zyngier]

On Sat, 20 Jan 2018 12:29:22 +0000
Russell King <rmk@armlinux.org.uk> wrote:

> On Sat, Jan 20, 2018 at 11:31:19AM +0000, Marc Zyngier wrote:
> > Define enough. These patches allow these CPUs to cope with variant-2,
> > and only variant-2. Variant-1 is still work in progress across all
> > architectures, variant-3 (aka Meltdown) doesn't concern 32bit ARM
> > implementations, and only A15 is susceptible to variant-3a.  
> 
> I think you need to be really careful about statements like this.
> 
> As you know, it is possible to run a 32bit environment in a VM on
> the 64bit CPUs.  So, its entirely possible to run a 32bit setup
> on a Cortex A72 for example, and that means such a setup _is_
> vulnerable to variant 3a.

Absolutely. Which is why I was careful to say A8/A9/A12/A15/A17 in all
the comments I made regarding these patches. Running 32bit code on an
A72, virtualized or not, is still running on an A72.

If you run such a configuration, you then need to apply the same
mitigations as on the arm64 side. In a virtualized environment,
KVM/arm64 will provide paravirtualized services that can be called to
ensure BP invalidation. Running bare metal will require CPU-specific
methods.

> Do people do this?  That isn't something we can really know, but
> I think as long as its allowed, you can bet that someone will,
> and someone will end up using it in a production environment.
> 
> So, it can't be ignored.

I'm certainly not stating that we should ignore it. But I'm trying to
plug the systems that I know people are using before tackling the ones
they may be using.

Thanks,

	M.
-- 
Without deviation from the norm, progress is not possible.