This is an archive of the discontinued LLVM Phabricator instance.

[BPF][clang] Ignore stack protector options for BPF target
ClosedPublic

Authored by eddyz87 on Jan 18 2023, 11:02 AM.

Details

Summary

Stack protector builtin functions are not implemented for BPF target,
thus compiling programs with one of the following options would result
in an error:

-fstack-protector
-fstack-protector-all
-fstack-protector-strong

This commit adds logic to ignore these options for BPF target.
Searching through DiagnosticDriverKinds.td shows that all messages for
such kind of behavior are implemented as warnings, this commit follows
the suit.

Here is an example of the diagnostic message:

clang-16: warning: ignoring '-fstack-protector' option as it is not currently supported for target 'bpf' [-Woption-ignored]

Diff Detail

Event Timeline

eddyz87 created this revision.Jan 18 2023, 11:02 AM
Herald added a project: Restricted Project. · View Herald TranscriptJan 18 2023, 11:02 AM
eddyz87 requested review of this revision.Jan 18 2023, 11:02 AM
Herald added a project: Restricted Project. · View Herald TranscriptJan 18 2023, 11:02 AM
eddyz87 edited the summary of this revision. (Show Details)

Slightly above my edit there is a similar logic for NVPTX target:

static void RenderSSPOptions(const Driver &D, const ToolChain &TC,
                             const ArgList &Args, ArgStringList &CmdArgs,
                             bool KernelOrKext) {
  const llvm::Triple &EffectiveTriple = TC.getEffectiveTriple();

  // NVPTX doesn't support stack protectors; from the compiler's perspective, it
  // doesn't even have a stack!
  if (EffectiveTriple.isNVPTX())
    return;
  ...

I don't like it because it produces rather vague error message:

warning: argument unused during compilation: '-fstack-protector' [-Wunused-command-line-argument]

However I'm hesitant to merge the NVPTX check with BPF check to avoid any potential changes in the NVPTX target behavior (e.g. different warning).

yonghong-song added a comment.EditedJan 18 2023, 11:21 PM

@compnerd could you also take a look at this patch?

First, some background about this patch. The reason of this patch is due to:

https://lore.kernel.org/bpf/CAOFdcFPnHEc2qd-=C+hdK4nTjJfbHsf4r-G7pdJTRBAT6MuOzg@mail.gmail.com/

Further the following link has details about hardened gentoo and modified clang default flags:

https://wiki.gentoo.org/wiki/Hardened_Gentoo

Unfortunately, we don't want -fstack-protector for bpf target as bpf kernel verifier will do stack verification.
This patch tries to ignore -fstack-protector. NVPTX arch has the same need of ignoring -fstack-protector.
This patch presented a different message than NVPTX. This patch:

clang-16: warning: ignoring '-fstack-protector' option as it is not currently supported for target 'bpf' [-Woption-ignored]

NVPTX

clang-16: warning: argument unused during compilation: '-fstack-protector' [-Wunused-command-line-argument]

Does clang community has a preference for the above two formats?

Let us say we do implement this patch and merged into clang, then using gentoo clang compiler, we will hit
the warning:

clang-16: warning: ignoring '-fstack-protector' option as it is not currently supported for target 'bpf' [-Woption-ignored]

I suspect gentoo community might complain. I don't think we should add -Wno-option-ignored since this may cause
unintended issues with compiler command line arguments.
Without -Wno-option-ignored, gentoo community might wants to append -fno-stack-protector to disable stack-protector,
but with the current implementation, we might actually trigger another warning.

So we have to two choices here for bpf target:

(1). ignore any stack-protector option and do not issue any warning, or
(2). append -fno-stack-protector by clang to compilation flags.

We can document this behavior in related clang (and kernel) docs.

WDYT?

Note that in GCC we are now emitting a note if the stack protector is requested by the user in the BPF backend:

note: -fstack-protector does not work on this architecture

which is less intrusive than a warning, still informative.
Then the stack protector is disabled.

ast accepted this revision.Jan 19 2023, 11:39 AM

This approach looks better to me than NVPTX warn and I agree with Ed that it's better to leave NVPTX as-is to avoid any regression.

This revision is now accepted and ready to land.Jan 19 2023, 11:39 AM

@ast With this patch, gentoo clang compilation will hit the warning even if people appends -fno-stack-protector. Is this okay? In general, if the option is '-fstack-protector -fno-stack-protector', we should not issue warning, right?

ast added a comment.Jan 19 2023, 11:54 AM

@ast With this patch, gentoo clang compilation will hit the warning even if people appends -fno-stack-protector. Is this okay? In general, if the option is '-fstack-protector -fno-stack-protector', we should not issue warning, right?

ahh. yeah. -fno-stack-protector should silence the warning.

Sorry, I double checked. '-fstack-protector -fno-stack-protector' will not result in warnings. So the patch LGTM. So gentoo people can add -fno-stack-protector to suppress warnings.

I can relax the warning to note to be on the same page with GCC, the reason I didn't is that similar things in DiagnosticDriverKinds.td are warnings.

This revision was landed with ongoing or failed builds.Jan 20 2023, 3:16 PM
This revision was automatically updated to reflect the committed changes.
dyung added a subscriber: dyung.Jan 21 2023, 8:52 PM

Hi, our internal release build buildbot seems to have issues with this test. It seems you are expected the following function declaration in the emitted IR:

define dso_local void @_Z5test1PKc(ptr noundef %msg) #0 !dbg !19 {

But in a release build, it becomes:

define dso_local void @_Z5test1PKc(ptr noundef %0) #0 !dbg !19 {

Note that %msg became %0. Can you fix the test so that it works in release builds as well?

Godbolt link: https://godbolt.org/z/E5zbM4chc

@dyung I just pushed the fix to the 'main' branch (https://github.com/llvm/llvm-project/commit/183d075055c591dedead7ece972f1bdea611aa3b). Please check it out. Thanks for reporting!

@dyung I just pushed the fix to the 'main' branch (https://github.com/llvm/llvm-project/commit/183d075055c591dedead7ece972f1bdea611aa3b). Please check it out. Thanks for reporting!

That fixed it, thanks!

Hi Yonghong,

Thank you for taking care of this issue.
This was sloppy on my side as the parameter name was completely
irrelevant for the test.

Best regards,
Eduard