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 <[email protected]>
---
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: [email protected]
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
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 <[email protected]>
> ---
>
> 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: [email protected]
>
> 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
>
>
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.
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 <[email protected]>
AuthorDate: Fri, 17 Jun 2022 11:08:46 -07:00
Committer: Dave Hansen <[email protected]>
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 <[email protected]>
Signed-off-by: Dave Hansen <[email protected]>
Link: https://github.com/chimera-linux/cports/commit/0fb7e506d5f83fdf2104feb22cdac34934561226
Link: https://github.com/llvm/llvm-project/issues/48553
Link: https://lkml.kernel.org/r/[email protected]
---
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
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
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 <[email protected]>
AuthorDate: Fri, 17 Jun 2022 11:08:46 -07:00
Committer: Borislav Petkov <[email protected]>
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 <[email protected]>
Signed-off-by: Dave Hansen <[email protected]>
Signed-off-by: Borislav Petkov <[email protected]>
Link: https://github.com/chimera-linux/cports/commit/0fb7e506d5f83fdf2104feb22cdac34934561226
Link: https://github.com/llvm/llvm-project/issues/48553
Link: https://lkml.kernel.org/r/[email protected]
---
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