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 <b...@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.net [...] That should be: https://lore.kernel.org/all/yv9m%2fhunjluyv...@worktop.programming.kicks-ass.net/ (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. -- Ben Hutchings Beware of bugs in the above code; I have only proved it correct, not tried it. - Donald Knuth
signature.asc
Description: This is a digitally signed message part
