U-Boot, cache speculation side channel attacks and ARM

Date: Fri, 19 Jan 2018 16:56:14 -0500
From: Tom Rini <[email protected]>

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?

Quoted 14 lines

Date: Fri, 19 Jan 2018 16:56:14 -0500
From: Tom Rini <[email protected]>

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.

Quoted 3 lines

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.

Quoted 26 lines · Mark Kettenis

Quoted 15 lines

Date: Fri, 19 Jan 2018 16:56:14 -0500
From: Tom Rini <[email protected]>

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.

Quoted 3 lines

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.

Quoted 7 lines

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 mailing list
U-Boot at lists.denx.de
https://lists.denx.de/listinfo/u-boot

Quoted 24 lines · Mark Kettenis

Quoted 14 lines

Date: Fri, 19 Jan 2018 16:56:14 -0500
From: Tom Rini <[email protected]>

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.

Quoted 3 lines

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.

Quoted 7 lines

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?

Quoted 14 lines

Date: Fri, 19 Jan 2018 16:56:14 -0500
From: Tom Rini <[email protected]>

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.

Quoted 3 lines

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.

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?

Quoted 11 lines · On Fri, 19 Jan 2018 16:56:14 -0500 Tom Rini <[email protected]> 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.

Quoted 3 lines

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 mailing list
U-Boot at lists.denx.de
https://lists.denx.de/listinfo/u-boot

Hi Marc

Quoted 23 lines · Marc Zyngier

Quoted 11 lines · On Fri, 19 Jan 2018 16:56:14 -0500 Tom Rini <[email protected]> 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.

Quoted 3 lines

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.

Quoted 2 lines

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?

Quoted 26 lines · On Sat, 20 Jan 2018 11:45:08 +0100 Michael Nazzareno Trimarchi…

Hi Marc

Quoted 23 lines · Marc Zyngier

Quoted 11 lines · On Fri, 19 Jan 2018 16:56:14 -0500 Tom Rini <[email protected]> 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.

Quoted 3 lines

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.

Quoted 4 lines

Quoted 2 lines

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.

Quoted 1 line

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.

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.

Quoted 4 lines · Marc Zyngier

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.