[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