diff mbox series

[tip:,x86/bugs] x86/srso: Fix build breakage with the LLVM linker

Message ID 169165870802.27769.15353947574704602257.tip-bot2@tip-bot2
State New
Headers
Series [tip:,x86/bugs] x86/srso: Fix build breakage with the LLVM linker |

Commit Message

tip-bot2 for Thomas Gleixner Aug. 10, 2023, 9:11 a.m. UTC 
  The following commit has been merged into the x86/bugs branch of tip:

Commit-ID:     cbe8ded48b939b9d55d2c5589ab56caa7b530709
Gitweb:        https://git.kernel.org/tip/cbe8ded48b939b9d55d2c5589ab56caa7b530709
Author:        Nick Desaulniers <ndesaulniers@google.com>
AuthorDate:    Wed, 09 Aug 2023 09:40:26 -07:00
Committer:     Borislav Petkov (AMD) <bp@alien8.de>
CommitterDate: Thu, 10 Aug 2023 11:03:12 +02:00

x86/srso: Fix build breakage with the LLVM linker

The assertion added to verify the difference in bits set of the
addresses of srso_untrain_ret_alias() and srso_safe_ret_alias() would fail
to link in LLVM's ld.lld linker with the following error:

  ld.lld: error: ./arch/x86/kernel/vmlinux.lds:210: at least one side of
  the expression must be absolute
  ld.lld: error: ./arch/x86/kernel/vmlinux.lds:211: at least one side of
  the expression must be absolute

Use ABSOLUTE to evaluate the expression referring to at least one of the
symbols so that LLD can evaluate the linker script.

Also, add linker version info to the comment about XOR being unsupported
in either ld.bfd or ld.lld until somewhat recently.

Fixes: fb3bd914b3ec ("x86/srso: Add a Speculative RAS Overflow mitigation")
Closes: https://lore.kernel.org/llvm/CA+G9fYsdUeNu-gwbs0+T6XHi4hYYk=Y9725-wFhZ7gJMspLDRA@mail.gmail.com/
Reported-by: Nathan Chancellor <nathan@kernel.org>
Reported-by: Daniel Kolesa <daniel@octaforge.org>
Reported-by: Naresh Kamboju <naresh.kamboju@linaro.org>
Suggested-by: Sven Volkinsfeld <thyrc@gmx.net>
Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Link: https://github.com/ClangBuiltLinux/linux/issues/1907
Link: https://lore.kernel.org/r/20230809-gds-v1-1-eaac90b0cbcc@google.com
---
 arch/x86/kernel/vmlinux.lds.S | 12 +++++++++---
 1 file changed, 9 insertions(+), 3 deletions(-)

Comments

Jakub Kicinski Aug. 10, 2023, 11:25 p.m. UTC | #1 
On Thu, 10 Aug 2023 09:11:48 -0000 tip-bot2 for Nick Desaulniers wrote:
> The following commit has been merged into the x86/bugs branch of tip:

Hi folks, is there an ETA on this getting to Linus?
The breakage has propagated to the networking trees, if the fix reaches
Linus soon we'll just hold off on applying stuff and fast forward again.
Jakub Kicinski Aug. 11, 2023, 12:28 a.m. UTC | #2 
On Thu, 10 Aug 2023 16:25:24 -0700 Jakub Kicinski wrote:
> On Thu, 10 Aug 2023 09:11:48 -0000 tip-bot2 for Nick Desaulniers wrote:
> > The following commit has been merged into the x86/bugs branch of tip:  
> 
> Hi folks, is there an ETA on this getting to Linus?
> The breakage has propagated to the networking trees, if the fix reaches
> Linus soon we'll just hold off on applying stuff and fast forward again.

Are the commit IDs stable on x86/bugs? 
Would it be rude if we pulled that in?
Linus Torvalds Aug. 11, 2023, 12:37 a.m. UTC | #3 
On Thu, 10 Aug 2023 at 17:29, Jakub Kicinski <kuba@kernel.org> wrote:
>
> Are the commit IDs stable on x86/bugs?

I think normally yes.

> Would it be rude if we pulled that in?

If this is holding stuff up, you have a pretty good excuse. It
shouldn't be the normal workflow, but hey, it's not a normal problem.

As I mentioned elsewhere, I hate the embargoed stuff, and every single
time it happens I expect fallout from the fact that we couldn't use
the usual bots for build and boot testing.

All our processes are geared towards open development, and I think
that's exactly how they *should* be.

But then that means that they fail horribly for the embargoes.

Anyway, go ahead and just pull in the fixes if this holds up your
normal workflow.

And if we end up with duplicates due to rebases (or worse yet, merge
issues due to rebases with other changes), it is what it is. Can't
blame you.

              Linus
Borislav Petkov Aug. 11, 2023, 9:02 a.m. UTC | #4 
On Thu, Aug 10, 2023 at 05:37:46PM -0700, Linus Torvalds wrote:
> If this is holding stuff up, you have a pretty good excuse. It
> shouldn't be the normal workflow, but hey, it's not a normal problem.
> 
> As I mentioned elsewhere, I hate the embargoed stuff, and every single
> time it happens I expect fallout from the fact that we couldn't use
> the usual bots for build and boot testing.

Yah, and this time ain't no different.

I was thinking of sending it to you now but Jakub pulled already. So
I'll send it to you on Sunday.

Thx.
diff mbox series

Patch

diff --git a/arch/x86/kernel/vmlinux.lds.S b/arch/x86/kernel/vmlinux.lds.S
index e768132..ef06211 100644
--- a/arch/x86/kernel/vmlinux.lds.S
+++ b/arch/x86/kernel/vmlinux.lds.S
@@ -529,11 +529,17 @@  INIT_PER_CPU(irq_stack_backing_store);
 
 #ifdef CONFIG_CPU_SRSO
 /*
- * GNU ld cannot do XOR so do: (A | B) - (A & B) in order to compute the XOR
+ * GNU ld cannot do XOR until 2.41.
+ * https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=f6f78318fca803c4907fb8d7f6ded8295f1947b1
+ *
+ * LLVM lld cannot do XOR until lld-17.
+ * https://github.com/llvm/llvm-project/commit/fae96104d4378166cbe5c875ef8ed808a356f3fb
+ *
+ * Instead do: (A | B) - (A & B) in order to compute the XOR
  * of the two function addresses:
  */
-. = ASSERT(((srso_untrain_ret_alias | srso_safe_ret_alias) -
-		(srso_untrain_ret_alias & srso_safe_ret_alias)) == ((1 << 2) | (1 << 8) | (1 << 14) | (1 << 20)),
+. = ASSERT(((ABSOLUTE(srso_untrain_ret_alias) | srso_safe_ret_alias) -
+		(ABSOLUTE(srso_untrain_ret_alias) & srso_safe_ret_alias)) == ((1 << 2) | (1 << 8) | (1 << 14) | (1 << 20)),
 		"SRSO function pair won't alias");
 #endif