From: Ben Hutchings <hidden> Date: 2022-08-19 00:33:20
From: Ben Hutchings <redacted>
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.
Define and use a BARRIER_NOSPEC macro which makes the LFENCE
conditional on X86_FEATURE_LFENCE_RDTSC, like the barrier_nospec()
macro defined for C code in <asm/barrier.h>.
Reported-by: Martin-Éric Racine <redacted>
References: https://bugs.debian.org/1017425
Cc: stable@vger.kernel.org
Cc: regressions@lists.linux.dev
Cc: Daniel Sneddon <redacted>
Cc: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
Fixes: 2b1299322016 ("x86/speculation: Add RSB VM Exit protections")
Fixes: ba6e31af2be9 ("x86/speculation: Add LFENCE to RSB fill sequence")
Signed-off-by: Ben Hutchings <redacted>
---
Re-sending this with properly matched From address and server.
Apologies if you got 2 copies.
Ben.
arch/x86/include/asm/nospec-branch.h | 11 +++++++----
1 file changed, 7 insertions(+), 4 deletions(-)
From: Peter Zijlstra <peterz@infradead.org> Date: 2022-08-19 08:47:52
On Fri, Aug 19, 2022 at 02:33:08AM +0200, Ben Hutchings wrote:
From: Ben Hutchings <redacted>
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 ?!?
From: Peter Zijlstra <peterz@infradead.org> Date: 2022-08-19 11:02:10
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:
quoted
From: Ben Hutchings <redacted>
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.
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
---
Subject: x86/nospec: Fix i386 RSB stuffing
Turns out that i386 doesn't unconditionally have LFENCE, as such the
loop in __FILL_RETURN_BUFFER isn't actually speculation safe on such
chips.
Fixes: ba6e31af2be9 ("x86/speculation: Add LFENCE to RSB fill sequence")
Reported-by: Ben Hutchings <redacted>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
---
From: Ben Hutchings <hidden> Date: 2022-08-19 11:03:03
On Fri, 2022-08-19 at 10:47 +0200, Peter Zijlstra wrote:
On Fri, Aug 19, 2022 at 02:33:08AM +0200, Ben Hutchings wrote:
quoted
From: Ben Hutchings <redacted>
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 ?!?
Yes, X86_FEATURE_RSB_CTXSW is enabled if any other Spectre v2
mitigation is enabled. And all Intel family 6 (except some early
Atoms) and AMD family 5+ get Spectre v2 mitigation by default.
Ben.
--
Ben Hutchings
Beware of bugs in the above code;
I have only proved it correct, not tried it. - Donald Knuth
On Fri, Aug 19, 2022 at 2:01 PM Peter Zijlstra [off-list ref] wrote:
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.
This is something that I've repeatedly had to bring up, whenever
something breaks because someone meant well by enabling more security
bells and whistles:
x86-32 is by definition legacy hardware. Enabling more bells and
whistles essentially kills support for all but the very latest
variants of the x86-32 family. This is the wrong approach. The right
approach is to accept that building for x86-32 inherently means
building for older and thus less secure architectures.
Martin-Éric
From: Ben Hutchings <hidden> Date: 2022-08-19 11:38:50
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:
quoted
On Fri, Aug 19, 2022 at 02:33:08AM +0200, Ben Hutchings wrote:
quoted
From: Ben Hutchings <redacted>
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%2FhuNJLuyviIn@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
From: Peter Zijlstra <peterz@infradead.org> Date: 2022-08-19 12:16:05
On Fri, Aug 19, 2022 at 01:38:27PM +0200, Ben Hutchings wrote:
So that puts the whole __FILL_RETURN_BUFFER inside an alternative, and
we can't have nested alternatives. That's unfortunate.
Well, both alternatives end with the LFENCE instruction, so I could pull
it out and do two consequtive ALTs, but unrolling the loop for i386 is
a better solution in that the sequence, while larger, removes the need
for the LFENCE.
Greetings,
On Fri, Aug 19, 2022 at 3:15 PM Peter Zijlstra [off-list ref] wrote:
On Fri, Aug 19, 2022 at 01:38:27PM +0200, Ben Hutchings wrote:
quoted
So that puts the whole __FILL_RETURN_BUFFER inside an alternative, and
we can't have nested alternatives. That's unfortunate.
Well, both alternatives end with the LFENCE instruction, so I could pull
it out and do two consequtive ALTs, but unrolling the loop for i386 is
a better solution in that the sequence, while larger, removes the need
for the LFENCE.
Have we reached a definitive conclusion on to how to fix this?
Martin-Éric
From: Peter Zijlstra <peterz@infradead.org> Date: 2022-08-30 12:00:35
On Tue, Aug 30, 2022 at 02:42:04PM +0300, Martin-Éric Racine wrote:
Greetings,
On Fri, Aug 19, 2022 at 3:15 PM Peter Zijlstra [off-list ref] wrote:
quoted
On Fri, Aug 19, 2022 at 01:38:27PM +0200, Ben Hutchings wrote:
quoted
So that puts the whole __FILL_RETURN_BUFFER inside an alternative, and
we can't have nested alternatives. That's unfortunate.
Well, both alternatives end with the LFENCE instruction, so I could pull
it out and do two consequtive ALTs, but unrolling the loop for i386 is
a better solution in that the sequence, while larger, removes the need
for the LFENCE.
Have we reached a definitive conclusion on to how to fix this?
On Tue, Aug 30, 2022 at 3:00 PM Peter Zijlstra [off-list ref] wrote:
On Tue, Aug 30, 2022 at 02:42:04PM +0300, Martin-Éric Racine wrote:
quoted
On Fri, Aug 19, 2022 at 3:15 PM Peter Zijlstra [off-list ref] wrote:
quoted
On Fri, Aug 19, 2022 at 01:38:27PM +0200, Ben Hutchings wrote:
quoted
So that puts the whole __FILL_RETURN_BUFFER inside an alternative, and
we can't have nested alternatives. That's unfortunate.
Well, both alternatives end with the LFENCE instruction, so I could pull
it out and do two consequtive ALTs, but unrolling the loop for i386 is
a better solution in that the sequence, while larger, removes the need
for the LFENCE.
Have we reached a definitive conclusion on to how to fix this?
Hi Martin,
On Tue, Aug 30, 2022 at 03:18:51PM +0300, Martin-??ric Racine wrote:
On Tue, Aug 30, 2022 at 3:00 PM Peter Zijlstra [off-list ref] wrote:
quoted
On Tue, Aug 30, 2022 at 02:42:04PM +0300, Martin-??ric Racine wrote:
quoted
On Fri, Aug 19, 2022 at 3:15 PM Peter Zijlstra [off-list ref] wrote:
quoted
On Fri, Aug 19, 2022 at 01:38:27PM +0200, Ben Hutchings wrote:
quoted
So that puts the whole __FILL_RETURN_BUFFER inside an alternative, and
we can't have nested alternatives. That's unfortunate.
Well, both alternatives end with the LFENCE instruction, so I could pull
it out and do two consequtive ALTs, but unrolling the loop for i386 is
a better solution in that the sequence, while larger, removes the need
for the LFENCE.
Have we reached a definitive conclusion on to how to fix this?