Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

[X86] support for -mstack-protector-guard-symbol= #48553

Closed
nickdesaulniers opened this issue Feb 16, 2021 · 10 comments
Closed

[X86] support for -mstack-protector-guard-symbol= #48553

nickdesaulniers opened this issue Feb 16, 2021 · 10 comments
Assignees
@xiangzh1
Labels
backend:X86 bugzilla Issues migrated from bugzilla clang:driver 'clang' and 'clang++' user-facing binaries. Not 'clang-cl' enhancement Improving things as opposed to bug fixing, e.g. new or missing feature

Comments

@nickdesaulniers
Copy link
Member

Bugzilla Link 49209
Version trunk
OS All
Blocks #4440
CC @kees,@zygoloid,@xiangzh1

Extended Description

via https://lore.kernel.org/lkml/c0ff7dba14041c7e5d1cae5d4df052f03759bef3.1613243844.git.luto@kernel.org/, the Linux kernel is looking to use the pair of flags:

-mstack-protector-guard-reg=fs -mstack-protector-guard-symbol=__stack_chk_guard

for 32b x86 kernels. It seems that clang does not yet support

-mstack-protector-guard-symbol=__stack_chk_guard
@nickdesaulniers
Copy link
Member Author

See also: #46685 .

@llvmbot llvmbot transferred this issue from llvm/llvm-bugzilla-archive Dec 11, 2021
@nickdesaulniers
Copy link
Member Author

cc @phoebewang

@phoebewang
Copy link
Contributor

I think we have already supported it, see 7c3fea7
cc @xiangzh1

@EugeneZelenko EugeneZelenko added clang:driver 'clang' and 'clang++' user-facing binaries. Not 'clang-cl' and removed clang Clang issues not falling into any other category labels Jun 18, 2022
@llvmbot
Copy link
Member

llvmbot commented Jun 18, 2022

@llvm/issue-subscribers-clang-driver

@nickdesaulniers
Copy link
Member Author

I think we have already supported it, see 7c3fea7

Almost; there are 4 very similarly named flags:

  1. -mstack-protector-guard=
  2. -mstack-protector-guard-reg=
  3. -mstack-protector-guard-offset=
  4. -mstack-protector-guard-symbol=

7c3fea7 implements 1-3. Clang is still missing support for 4 which is used by the Linux kernel when building the 32b x86 Linux kernel.

@xiangzh1
Copy link
Contributor

Yes, I remember I implemented some, let me try to support the 4 (some days later).
Please can you give me the requirement of support "-mstack-protector-guard-symbol=" ?

@nickdesaulniers
Copy link
Member Author

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3fb0fdb3bbe7a

void foo (int *);
void bar (void) {
    int baz [42];
    foo(baz);
}
$ clang -mstack-protector-guard-reg=gs -mstack-protector-guard-symbol=__woof -fstack-protector-strong -O2

should produce references to:

%gs:__woof(%rip)

operands rather than %fs:40 if the first two flags are removed.

ammarfaizi2 pushed a commit to ammarfaizi2/linux-block that referenced this issue Jul 6, 2022
@nathanchance @hansendc
x86/Kconfig: Fix CONFIG_CC_HAS_SANE_STACKPROTECTOR when cross compili…
b230402 
…ng 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: chimera-linux/cports@0fb7e50
Link: llvm/llvm-project#48553
Link: https://lkml.kernel.org/r/20220617180845.2788442-1-nathan@kernel.org
@xiangzh1
Copy link
Contributor

xiangzh1 commented Jul 8, 2022

Sorry for late implement, we are in release these days.
Implement patch: https://reviews.llvm.org/D129346
thank you!

This was referenced Jul 8, 2022
Closed
Open
ammarfaizi2 pushed a commit to ammarfaizi2/linux-block that referenced this issue Jul 11, 2022
@nathanchance @suryasaimadhu
x86/Kconfig: Fix CONFIG_CC_HAS_SANE_STACKPROTECTOR when cross compili…
1b86678 
…ng 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: chimera-linux/cports@0fb7e50
Link: llvm/llvm-project#48553
Link: https://lkml.kernel.org/r/20220617180845.2788442-1-nathan@kernel.org
@xgupta
Copy link
Contributor

xgupta commented Jan 27, 2023

will it be fine to close this since the patch is committed?

@llvmbot
Copy link
Member

llvmbot commented Jan 29, 2023

@llvm/issue-subscribers-backend-x86

@Endilll Endilll added enhancement Improving things as opposed to bug fixing, e.g. new or missing feature and removed missing-feature labels Aug 15, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@xiangzh1 xiangzh1

Labels
backend:X86 bugzilla Issues migrated from bugzilla clang:driver 'clang' and 'clang++' user-facing binaries. Not 'clang-cl' enhancement Improving things as opposed to bug fixing, e.g. new or missing feature
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
7 participants
@nickdesaulniers @phoebewang @EugeneZelenko @Endilll @llvmbot @xiangzh1 @xgupta