[PATCH] ARM: spectre-v2: fix unstable cpu get

xieyuanbin1 xieyuanbin1 at huawei.com
Thu Apr 24 07:03:30 PDT 2025


From: Xie Yuanbin <xieyuanbin1 at huawei.com>

>Consider your test program running on CPU 1 which requires fixup. It
>takes a fault, and before we enter harden_branch_predictor(), we end
>up being migrated to CPU 0, but doesn't require a switch of the MM.
>Let's say we then disable preemption and then call
>harden_branch_predictor(), and then restore the preemption state.
>The thread then gets migrated back to CPU 1. Again, no switch of
>the MM.

Your assumption is correct, and I agree with it.

>I don't care if this disrupts test tooling. The trade off between
>test tooling having a problem and a silent data leak through this
>channel... the answer is pretty obvious that the test tooling
>failing is less important than having a silent data leak.

I have never mentioned a test tool, and I agree with you.
The problem I mentioned before is possible illegal instruction and panic.



If we want to fix this problem without affecting performance,
can we add a new hook functions (in fsr-3level.c)?

I don't know much about the details of the ARM manual,
Are all user-mode access to kernel-mode addresses are `permission fault`
and common page faults (hot code) are `access flag fault`?
If so, we can add a new hook function to deal with `permission fault`
and set it in fsr-3level.c.
This means we fix the problem without adding a branch,
that there is no performance loss.

Otherwise, we can only add condition judgment before enabling irq,
which means that performance loss occurs. This is so sad. :(



More information about the linux-arm-kernel mailing list