On 01/19/2018 04:21 PM, Mark Kettenis wrote:
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?
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 mailing list
[email protected]
https://lists.denx.de/listinfo/u-boot
