[PATCH] ARM: mm: harden branch predictor before opening interrupts during fault

[Russell King - ARM Linux admin]

On Tue, Jan 26, 2021 at 11:01:50PM +0800, Lecopzer Chen wrote:
> > On 2021-01-26 10:59:32 [+0000], Russell King - ARM Linux admin wrote:
> > > On Tue, Jan 26, 2021 at 05:17:08PM +0800, Lecopzer Chen wrote:
> > > > Hi all,
> > > > 
> > > > I don't see any fix for this issue now(maybe I missed it..?),
> > > > could we fix this if there is better solution?
> > > > This issue exists almost two years.
> > > 
> > > I don't think anyone provided an acceptable patch.
> > > 
> > > The first patch moved the hardening out of the translation/section
> > > fault handling. Since the kernel is mapped with sections, these
> > > are above TASK_SIZE, and the whole point of the branch prediction
> > > hardening is to prevent the prediction in the kernel being exploited,
> > > missing the hardening effectively makes the mitigation useless.
> > > 
> > > The discussion in February 2019 never concluded from what I can see.
> > 
> > My memory is that I never got a reply which I understood.
> > Let me try again this week with the information above.
> 
> 
> NOTE:
> Before sending this mail, I had searched the relative threads and
> there are two solutions in general:
>     1. Add get_pcpu()/put_cpu() https://lkml.org/lkml/2019/6/3/426
>        Reject by Marc:
>        > The right fix would be to move the call to a point where we haven't
>        > enabled preemption yet.
> 
>     2. Move out like the patch from Sebastian:
>        This seems follow the concept of 1.
>        (move the call to a point where we haven't enabled preemption yet).
>        But I can't find any reply in the thread.
> 
> Now the CONFIG_HARDEN_BRANCH_PREDICTOR has already backported to LTS,
> and after upgrading ARM CONFIG_CPU_V7 products to latest LTS, the
> CONFIG_HARDEN_BRANCH_PREDICTOR will be default y and this issue makes
> our devices panic and we have to either disable HARDEN_BRANCH_PREDICTOR
> or hack in-house to avoid the kernel panic.

It does _not_ cause the kernel to panic, ever. A kernel panic takes
out the system. This is not the case here.

It merely causes a noisy message to be emitted in the kernel log, and
the system survives. That is way more preferable than breaking the
effect of branch predictor hardening.

If it is taking out your kernel with a real panic, then there is
something wrong elsewhere - and this is _not_ something that should
be happening during normal system operation.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!