* [PATCH] x86/Kconfig: Fix CONFIG_CC_HAS_SANE_STACKPROTECTOR when cross compiling with clang
@ 2022-06-17 18:08 Nathan Chancellor
2022-07-01 22:17 ` Nathan Chancellor
` (3 more replies)
0 siblings, 4 replies; 6+ messages in thread
From: Nathan Chancellor @ 2022-06-17 18:08 UTC (permalink / raw)
To: Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86
Cc: H. Peter Anvin, Nick Desaulniers, Tom Rix, Daniel Kolesa,
linux-kernel, patches, llvm, Nathan Chancellor, stable
Chimera Linux notes that CONFIG_CC_HAS_SANE_STACKPROTECTOR cannot be
enabled when cross compiling an x86_64 kernel with clang, even though it
does work when natively compiling.
When building on aarch64:
$ make -sj"$(nproc)" ARCH=x86_64 LLVM=1 defconfig
$ grep STACKPROTECTOR .config
When building on x86_64:
$ make -sj"$(nproc)" ARCH=x86_64 LLVM=1 defconfig
$ grep STACKPROTECTOR .config
CONFIG_CC_HAS_SANE_STACKPROTECTOR=y
CONFIG_HAVE_STACKPROTECTOR=y
CONFIG_STACKPROTECTOR=y
CONFIG_STACKPROTECTOR_STRONG=y
When clang is invoked without a '--target' flag, code is generated for
the default target, which is usually the host (it is configurable via
cmake). As a result, the has-stack-protector scripts will generate code
for the default target but check for x86 specific segment registers,
which cannot succeed if the default target is not x86.
$(CLANG_FLAGS) contains an explicit '--target' flag so pass that
variable along to the has-stack-protector scripts so that the stack
protector can be enabled when cross compiling with clang. The 32-bit
stack protector cannot currently be enabled with clang, as it does not
support '-mstack-protector-guard-symbol', so this results in no
functional change for ARCH=i386 when cross compiling.
Link: https://github.com/chimera-linux/cports/commit/0fb7e506d5f83fdf2104feb22cdac34934561226
Link: https://github.com/llvm/llvm-project/issues/48553
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
---
Fixes: 2a61f4747eea ("stack-protector: test compiler capability in Kconfig and drop AUTO mode")
might be appropriate; I am conflicted on fixes tags for problems that
that arise due to use cases that were not considered at the time of a
change, as it feels wrong to blame the commit for not looking far enough
into the future where it might be common for people to have workstations
running another architecture other than x86_64.
Chimera appears to use a 5.15 kernel so a
Cc: stable@vger.kernel.org
might be nice but some maintainers are picky about that so I leave it up
to you all.
arch/x86/Kconfig | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index be0b95e51df6..076adde7ead9 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -391,8 +391,8 @@ config PGTABLE_LEVELS
config CC_HAS_SANE_STACKPROTECTOR
bool
- default $(success,$(srctree)/scripts/gcc-x86_64-has-stack-protector.sh $(CC)) if 64BIT
- default $(success,$(srctree)/scripts/gcc-x86_32-has-stack-protector.sh $(CC))
+ default $(success,$(srctree)/scripts/gcc-x86_64-has-stack-protector.sh $(CC) $(CLANG_FLAGS)) if 64BIT
+ default $(success,$(srctree)/scripts/gcc-x86_32-has-stack-protector.sh $(CC) $(CLANG_FLAGS))
help
We have to make sure stack protector is unconditionally disabled if
the compiler produces broken code or if it does not let us control
base-commit: b13baccc3850ca8b8cccbf8ed9912dbaa0fdf7f3
--
2.36.1
^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [PATCH] x86/Kconfig: Fix CONFIG_CC_HAS_SANE_STACKPROTECTOR when cross compiling with clang
2022-06-17 18:08 [PATCH] x86/Kconfig: Fix CONFIG_CC_HAS_SANE_STACKPROTECTOR when cross compiling with clang Nathan Chancellor
@ 2022-07-01 22:17 ` Nathan Chancellor
2022-07-06 22:25 ` Dave Hansen
` (2 subsequent siblings)
3 siblings, 0 replies; 6+ messages in thread
From: Nathan Chancellor @ 2022-07-01 22:17 UTC (permalink / raw)
To: Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86
Cc: H. Peter Anvin, Nick Desaulniers, Tom Rix, Daniel Kolesa,
linux-kernel, patches, llvm, stable
Gentle ping for review.
On Fri, Jun 17, 2022 at 11:08:46AM -0700, Nathan Chancellor wrote:
> Chimera Linux notes that CONFIG_CC_HAS_SANE_STACKPROTECTOR cannot be
> enabled when cross compiling an x86_64 kernel with clang, even though it
> does work when natively compiling.
>
> When building on aarch64:
>
> $ make -sj"$(nproc)" ARCH=x86_64 LLVM=1 defconfig
>
> $ grep STACKPROTECTOR .config
>
> When building on x86_64:
>
> $ make -sj"$(nproc)" ARCH=x86_64 LLVM=1 defconfig
>
> $ grep STACKPROTECTOR .config
> CONFIG_CC_HAS_SANE_STACKPROTECTOR=y
> CONFIG_HAVE_STACKPROTECTOR=y
> CONFIG_STACKPROTECTOR=y
> CONFIG_STACKPROTECTOR_STRONG=y
>
> When clang is invoked without a '--target' flag, code is generated for
> the default target, which is usually the host (it is configurable via
> cmake). As a result, the has-stack-protector scripts will generate code
> for the default target but check for x86 specific segment registers,
> which cannot succeed if the default target is not x86.
>
> $(CLANG_FLAGS) contains an explicit '--target' flag so pass that
> variable along to the has-stack-protector scripts so that the stack
> protector can be enabled when cross compiling with clang. The 32-bit
> stack protector cannot currently be enabled with clang, as it does not
> support '-mstack-protector-guard-symbol', so this results in no
> functional change for ARCH=i386 when cross compiling.
>
> Link: https://github.com/chimera-linux/cports/commit/0fb7e506d5f83fdf2104feb22cdac34934561226
> Link: https://github.com/llvm/llvm-project/issues/48553
> Signed-off-by: Nathan Chancellor <nathan@kernel.org>
> ---
>
> Fixes: 2a61f4747eea ("stack-protector: test compiler capability in Kconfig and drop AUTO mode")
>
> might be appropriate; I am conflicted on fixes tags for problems that
> that arise due to use cases that were not considered at the time of a
> change, as it feels wrong to blame the commit for not looking far enough
> into the future where it might be common for people to have workstations
> running another architecture other than x86_64.
>
> Chimera appears to use a 5.15 kernel so a
>
> Cc: stable@vger.kernel.org
>
> might be nice but some maintainers are picky about that so I leave it up
> to you all.
>
> arch/x86/Kconfig | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> index be0b95e51df6..076adde7ead9 100644
> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -391,8 +391,8 @@ config PGTABLE_LEVELS
>
> config CC_HAS_SANE_STACKPROTECTOR
> bool
> - default $(success,$(srctree)/scripts/gcc-x86_64-has-stack-protector.sh $(CC)) if 64BIT
> - default $(success,$(srctree)/scripts/gcc-x86_32-has-stack-protector.sh $(CC))
> + default $(success,$(srctree)/scripts/gcc-x86_64-has-stack-protector.sh $(CC) $(CLANG_FLAGS)) if 64BIT
> + default $(success,$(srctree)/scripts/gcc-x86_32-has-stack-protector.sh $(CC) $(CLANG_FLAGS))
> help
> We have to make sure stack protector is unconditionally disabled if
> the compiler produces broken code or if it does not let us control
>
> base-commit: b13baccc3850ca8b8cccbf8ed9912dbaa0fdf7f3
> --
> 2.36.1
>
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] x86/Kconfig: Fix CONFIG_CC_HAS_SANE_STACKPROTECTOR when cross compiling with clang
2022-06-17 18:08 [PATCH] x86/Kconfig: Fix CONFIG_CC_HAS_SANE_STACKPROTECTOR when cross compiling with clang Nathan Chancellor
2022-07-01 22:17 ` Nathan Chancellor
@ 2022-07-06 22:25 ` Dave Hansen
2022-07-07 17:17 ` Nathan Chancellor
2022-07-06 22:33 ` [tip: x86/build] " tip-bot2 for Nathan Chancellor
2022-07-11 7:04 ` tip-bot2 for Nathan Chancellor
3 siblings, 1 reply; 6+ messages in thread
From: Dave Hansen @ 2022-07-06 22:25 UTC (permalink / raw)
To: Nathan Chancellor, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
Dave Hansen, x86
Cc: H. Peter Anvin, Nick Desaulniers, Tom Rix, Daniel Kolesa,
linux-kernel, patches, llvm, stable
On 6/17/22 11:08, Nathan Chancellor wrote:
> When clang is invoked without a '--target' flag, code is generated for
> the default target, which is usually the host (it is configurable via
> cmake). As a result, the has-stack-protector scripts will generate code
> for the default target but check for x86 specific segment registers,
> which cannot succeed if the default target is not x86.
I guess the real root cause here is the direct use of '$(CC)' without
any other flags. Adding '$(CLANG_FLAGS)' seems like a pretty normal
fix, like in scripts/Kconfig.include.
I suspect there's another one of these here:
arch/x86/um/vdso/Makefile: cmd_vdso = $(CC) -nostdlib -o $@
but I wouldn't be surprised if UML doesn't work with clang in the first
place.
^ permalink raw reply [flat|nested] 6+ messages in thread
* [tip: x86/build] x86/Kconfig: Fix CONFIG_CC_HAS_SANE_STACKPROTECTOR when cross compiling with clang
2022-06-17 18:08 [PATCH] x86/Kconfig: Fix CONFIG_CC_HAS_SANE_STACKPROTECTOR when cross compiling with clang Nathan Chancellor
2022-07-01 22:17 ` Nathan Chancellor
2022-07-06 22:25 ` Dave Hansen
@ 2022-07-06 22:33 ` tip-bot2 for Nathan Chancellor
2022-07-11 7:04 ` tip-bot2 for Nathan Chancellor
3 siblings, 0 replies; 6+ messages in thread
From: tip-bot2 for Nathan Chancellor @ 2022-07-06 22:33 UTC (permalink / raw)
To: linux-tip-commits; +Cc: Nathan Chancellor, Dave Hansen, x86, linux-kernel
The following commit has been merged into the x86/build branch of tip:
Commit-ID: b230402b0dbd6930a616a07641f0bbc30325881e
Gitweb: https://git.kernel.org/tip/b230402b0dbd6930a616a07641f0bbc30325881e
Author: Nathan Chancellor <nathan@kernel.org>
AuthorDate: Fri, 17 Jun 2022 11:08:46 -07:00
Committer: Dave Hansen <dave.hansen@linux.intel.com>
CommitterDate: Wed, 06 Jul 2022 14:57:10 -07:00
x86/Kconfig: Fix CONFIG_CC_HAS_SANE_STACKPROTECTOR when cross compiling with clang
Chimera Linux notes that CONFIG_CC_HAS_SANE_STACKPROTECTOR cannot be
enabled when cross compiling an x86_64 kernel with clang, even though it
does work when natively compiling.
When building on aarch64:
$ make -sj"$(nproc)" ARCH=x86_64 LLVM=1 defconfig
$ grep STACKPROTECTOR .config
When building on x86_64:
$ make -sj"$(nproc)" ARCH=x86_64 LLVM=1 defconfig
$ grep STACKPROTECTOR .config
CONFIG_CC_HAS_SANE_STACKPROTECTOR=y
CONFIG_HAVE_STACKPROTECTOR=y
CONFIG_STACKPROTECTOR=y
CONFIG_STACKPROTECTOR_STRONG=y
When clang is invoked without a '--target' flag, code is generated for
the default target, which is usually the host (it is configurable via
cmake). As a result, the has-stack-protector scripts will generate code
for the default target but check for x86 specific segment registers,
which cannot succeed if the default target is not x86.
$(CLANG_FLAGS) contains an explicit '--target' flag so pass that
variable along to the has-stack-protector scripts so that the stack
protector can be enabled when cross compiling with clang. The 32-bit
stack protector cannot currently be enabled with clang, as it does not
support '-mstack-protector-guard-symbol', so this results in no
functional change for ARCH=i386 when cross compiling.
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
Link: https://github.com/chimera-linux/cports/commit/0fb7e506d5f83fdf2104feb22cdac34934561226
Link: https://github.com/llvm/llvm-project/issues/48553
Link: https://lkml.kernel.org/r/20220617180845.2788442-1-nathan@kernel.org
---
arch/x86/Kconfig | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index b0142e0..b7767ba 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -386,8 +386,8 @@ config PGTABLE_LEVELS
config CC_HAS_SANE_STACKPROTECTOR
bool
- default $(success,$(srctree)/scripts/gcc-x86_64-has-stack-protector.sh $(CC)) if 64BIT
- default $(success,$(srctree)/scripts/gcc-x86_32-has-stack-protector.sh $(CC))
+ default $(success,$(srctree)/scripts/gcc-x86_64-has-stack-protector.sh $(CC) $(CLANG_FLAGS)) if 64BIT
+ default $(success,$(srctree)/scripts/gcc-x86_32-has-stack-protector.sh $(CC) $(CLANG_FLAGS))
help
We have to make sure stack protector is unconditionally disabled if
the compiler produces broken code or if it does not let us control
^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [PATCH] x86/Kconfig: Fix CONFIG_CC_HAS_SANE_STACKPROTECTOR when cross compiling with clang
2022-07-06 22:25 ` Dave Hansen
@ 2022-07-07 17:17 ` Nathan Chancellor
0 siblings, 0 replies; 6+ messages in thread
From: Nathan Chancellor @ 2022-07-07 17:17 UTC (permalink / raw)
To: Dave Hansen
Cc: Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
H. Peter Anvin, Nick Desaulniers, Tom Rix, Daniel Kolesa,
linux-kernel, patches, llvm, stable
On Wed, Jul 06, 2022 at 03:25:51PM -0700, Dave Hansen wrote:
> On 6/17/22 11:08, Nathan Chancellor wrote:
> > When clang is invoked without a '--target' flag, code is generated for
> > the default target, which is usually the host (it is configurable via
> > cmake). As a result, the has-stack-protector scripts will generate code
> > for the default target but check for x86 specific segment registers,
> > which cannot succeed if the default target is not x86.
>
> I guess the real root cause here is the direct use of '$(CC)' without
> any other flags. Adding '$(CLANG_FLAGS)' seems like a pretty normal
> fix, like in scripts/Kconfig.include.
Right, also see the following commits for other areas where this was
addressed.
58d746c119df ("efi/libstub: Add $(CLANG_FLAGS) to x86 flags")
d5cbd80e302d ("x86/boot: Add $(CLANG_FLAGS) to compressed KBUILD_CFLAGS")
8abe7fc26ad8 ("x86/build: Propagate $(CLANG_FLAGS) to $(REALMODE_FLAGS)")
> I suspect there's another one of these here:
>
> arch/x86/um/vdso/Makefile: cmd_vdso = $(CC) -nostdlib -o $@
>
> but I wouldn't be surprised if UML doesn't work with clang in the first
> place.
We have started testing UML with clang and it does work but I suspect
there is little value to cross compiling a UML kernel, as it has to run
in an x86 userland anyways, rather than through QEMU or other
virtualization solutions. That is not something I plan to do anyways.
If someone does and a fix similar to this one is needed, it can be done
at that time.
Thank you for picking up this change!
Cheers,
Nathan
^ permalink raw reply [flat|nested] 6+ messages in thread
* [tip: x86/build] x86/Kconfig: Fix CONFIG_CC_HAS_SANE_STACKPROTECTOR when cross compiling with clang
2022-06-17 18:08 [PATCH] x86/Kconfig: Fix CONFIG_CC_HAS_SANE_STACKPROTECTOR when cross compiling with clang Nathan Chancellor
` (2 preceding siblings ...)
2022-07-06 22:33 ` [tip: x86/build] " tip-bot2 for Nathan Chancellor
@ 2022-07-11 7:04 ` tip-bot2 for Nathan Chancellor
3 siblings, 0 replies; 6+ messages in thread
From: tip-bot2 for Nathan Chancellor @ 2022-07-11 7:04 UTC (permalink / raw)
To: linux-tip-commits
Cc: Nathan Chancellor, Dave Hansen, Borislav Petkov, x86, linux-kernel
The following commit has been merged into the x86/build branch of tip:
Commit-ID: 1b8667812b3a1304f3db736ac4905d6ad77d721e
Gitweb: https://git.kernel.org/tip/1b8667812b3a1304f3db736ac4905d6ad77d721e
Author: Nathan Chancellor <nathan@kernel.org>
AuthorDate: Fri, 17 Jun 2022 11:08:46 -07:00
Committer: Borislav Petkov <bp@suse.de>
CommitterDate: Mon, 11 Jul 2022 08:49:39 +02:00
x86/Kconfig: Fix CONFIG_CC_HAS_SANE_STACKPROTECTOR when cross compiling with clang
Chimera Linux notes that CONFIG_CC_HAS_SANE_STACKPROTECTOR cannot be
enabled when cross compiling an x86_64 kernel with clang, even though it
does work when natively compiling.
When building on aarch64:
$ make -sj"$(nproc)" ARCH=x86_64 LLVM=1 defconfig
$ grep STACKPROTECTOR .config
When building on x86_64:
$ make -sj"$(nproc)" ARCH=x86_64 LLVM=1 defconfig
$ grep STACKPROTECTOR .config
CONFIG_CC_HAS_SANE_STACKPROTECTOR=y
CONFIG_HAVE_STACKPROTECTOR=y
CONFIG_STACKPROTECTOR=y
CONFIG_STACKPROTECTOR_STRONG=y
When clang is invoked without a '--target' flag, code is generated for
the default target, which is usually the host (it is configurable via
cmake). As a result, the has-stack-protector scripts will generate code
for the default target but check for x86 specific segment registers,
which cannot succeed if the default target is not x86.
$(CLANG_FLAGS) contains an explicit '--target' flag so pass that
variable along to the has-stack-protector scripts so that the stack
protector can be enabled when cross compiling with clang. The 32-bit
stack protector cannot currently be enabled with clang, as it does not
support '-mstack-protector-guard-symbol', so this results in no
functional change for ARCH=i386 when cross compiling.
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Link: https://github.com/chimera-linux/cports/commit/0fb7e506d5f83fdf2104feb22cdac34934561226
Link: https://github.com/llvm/llvm-project/issues/48553
Link: https://lkml.kernel.org/r/20220617180845.2788442-1-nathan@kernel.org
---
arch/x86/Kconfig | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index be0b95e..076adde 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -391,8 +391,8 @@ config PGTABLE_LEVELS
config CC_HAS_SANE_STACKPROTECTOR
bool
- default $(success,$(srctree)/scripts/gcc-x86_64-has-stack-protector.sh $(CC)) if 64BIT
- default $(success,$(srctree)/scripts/gcc-x86_32-has-stack-protector.sh $(CC))
+ default $(success,$(srctree)/scripts/gcc-x86_64-has-stack-protector.sh $(CC) $(CLANG_FLAGS)) if 64BIT
+ default $(success,$(srctree)/scripts/gcc-x86_32-has-stack-protector.sh $(CC) $(CLANG_FLAGS))
help
We have to make sure stack protector is unconditionally disabled if
the compiler produces broken code or if it does not let us control
^ permalink raw reply related [flat|nested] 6+ messages in thread
end of thread, other threads:[~2022-07-11 7:04 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-06-17 18:08 [PATCH] x86/Kconfig: Fix CONFIG_CC_HAS_SANE_STACKPROTECTOR when cross compiling with clang Nathan Chancellor
2022-07-01 22:17 ` Nathan Chancellor
2022-07-06 22:25 ` Dave Hansen
2022-07-07 17:17 ` Nathan Chancellor
2022-07-06 22:33 ` [tip: x86/build] " tip-bot2 for Nathan Chancellor
2022-07-11 7:04 ` tip-bot2 for Nathan Chancellor
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.