[PATCH 2/4] ARM: Introduce ability to enable invalidate of BTB with ICIALLU on Cortex-A15 for CVE-2017-5715

[nm@ti.com (Nishanth Menon)]

On 21:36-20180613, Florian Fainelli wrote:
[...]
> >>> c) This workaround applies to only the boot processor. It is important
> >>>   to apply workaround as necessary (context-save-restore) around low
> >>>   power context loss OR additional processors as necessary in either
> >>>   firmware support OR elsewhere in OS.
> >>
> >> About that, I don't know enough of uboot but are there existing PSCI or
> >> other seemingly standard secondary core support in uboot that would make
> >> us go through the same initialization as the boot CPU? If not, is
> >> everything going to be largely implementation specific and
> >> scattered between uboot and the hypervisors or kernel?
> > 
> > in ARMV7 SoCs, unfortunately, we lived in a world of no-exact-standard.
> > even within TI, Few of the SoCs use PSCI, others did implement custom
> > SMC calls (since they existed in an architecture prior to PSCI).
> > 
> >>
> >> FWIW, this is what prompted me to submit this:
> >>
> >> https://patchwork.kernel.org/patch/10453643/
> > 
> > That wont work in a generic manner for precisely the same reason I had to do
> > it with weak function in u-boot (some SoCs will only permit 'mcr
> > p15, 0, r0, c1, c0, 1' in secure world and you need to make a custom smc
> > call to make it happen). Unfortunately, IMHO, at least at this
> > point, there'd be custom implementations per SoC and layers depending on
> > where to implement it.
> 
> It won't work in a generic manner but it will work for some platforms
> where updating the firmware is impractical, and since the bits are write
> ignore if your PL does not allow it, this still seems like a net win for
> platforms where this is effective, and it does take care of Linux doing
> the SMP bring-up of secondary cores as well. That's what we have in our
> downstream tree at least, and I was hoping this could land upstream too.


I think it is clear from Russell's summary that we dont want "may work"
workaround in kernel/bootloaders. in case of u-boot (which this patch is
about), I'd suggest adding the CONFIG_*CVE* input to the Kconfig for the
SoC where you know for sure this works.

Does that sound a fair tradeoff?

-- 
Regards,
Nishanth Menon