Messages in this thread | | | From | Linus Walleij <> | Date | Sat, 6 Mar 2021 13:27:54 +0100 | Subject | Re: [PATCH v6] ARM: Implement SLS mitigation |
| |
On Fri, Mar 5, 2021 at 10:53 AM Will Deacon <will@kernel.org> wrote:
> I still don't see why SLS is worth a compiler mitigation which will affect > all CPUs that run the kernel binary, but Spectre-v1 is not. In other words, > the big thing missing from this is a justification as to why SLS is a > problem worth working around for general C code.
I might be on the Dunning Kruger-scale of a little knowledge is dangerous here, but AFAICT it is because it is mitigating all branches that result from the compilation.
I think the people who devised this approach didn't think about the kernel problem per se but about "any code".
They would have to go back to the compilers, have them introduce a marker instead for each branch or return, and then emit symbols that the kernel can run-time patch to mitigate the vulnerability. Something like that. (I guess.)
Notice that these symbols/pointers would first have a footprint impact, though maybe they could be discarded if not applicable.
The patch says:
It inserts speculation barrier sequences (SB or DSB+ISB depending on the target architecture) after RET and BR, and replacing BLR with BL+BR sequence.
How would you do that at runtime? If you slot in NOPs around the branch for mitigating, there will still be impact. If you want to make the code look the same unless vulnerable, you would have to patch the branch with a branch to another place to do the barriers... that patched branch in turn could be speculated? I feel stupid here. But I guess someone could come up with something?
So instead of a simple straight-forward solution that becomes a really complicated awkward solution that generate a few thousand more man-hours and delays the mitigations. So I understand if the authors would want to try the simple approach first.
It may however be our job to say "no, go do the really complicated thing", I guess that is what you're saying. :)
Yours, Linus Walleij
| |