On Fri, 2022-08-19 at 13:01 +0200, Peter Zijlstra wrote:
On Fri, Aug 19, 2022 at 10:47:21AM +0200, Peter Zijlstra wrote:
On Fri, Aug 19, 2022 at 02:33:08AM +0200, Ben Hutchings wrote:
From: Ben Hutchings benh@debian.org
The mitigation for PBRSB includes adding LFENCE instructions to the RSB filling sequence. However, RSB filling is done on some older CPUs that don't support the LFENCE instruction.
Wait; what? There are chips that enable the RSB mitigations and DONT have LFENCE ?!?
So I gave in and clicked on the horrible bugzilla thing. Apparently this is P3/Athlon64 era crud.
Anyway, the added LFENCE isn't because of retbleed; it is because you can steer the jnz and terminate the loop early and then not actually complete the RSB stuffing.
I know, I corrected that further down.
New insights etc.. So it's a geniune fix for the existing rsb stuffing.
I'm not entirly sure what to do here. On the one hand, it's 32bit, so who gives a crap, otoh we shouldn't break these ancient chips either I suppose.
How's something like so then? It goes on top of my other patch cleaning up this RSB mess:
https://lkml.kernel.org/r/Yv9m%2FhuNJLuyviIn%40worktop.programming.kicks-ass...
[...]
That should be: https://lore.kernel.org/all/Yv9m%2FhuNJLuyviIn@worktop.programming.kicks-ass... (the redirector unescapes the URL-escaped /).
So that puts the whole __FILL_RETURN_BUFFER inside an alternative, and we can't have nested alternatives. That's unfortunate.
Ben.