From: Segher Boessenkool <segher@kernel.crashing.org>
To: Christophe Leroy <christophe.leroy@csgroup.eu>
Cc: Nathan Chancellor <nathan@kernel.org>,
Michael Ellerman <mpe@ellerman.id.au>,
linuxppc-dev@lists.ozlabs.org, llvm@lists.linux.dev,
patches@lists.linux.dev, stable@vger.kernel.org
Subject: Re: [PATCH] powerpc/vdso: Drop -mstack-protector-guard flags in 32-bit files with clang
Date: Wed, 6 Nov 2024 07:37:52 -0600 [thread overview]
Message-ID: <20241106133752.GG29862@gate.crashing.org> (raw)
In-Reply-To: <884cf694-09c7-4082-a6b1-6de987025bf8@csgroup.eu>
Hi!
On Wed, Nov 06, 2024 at 09:55:58AM +0100, Christophe Leroy wrote:
> Le 30/10/2024 à 19:41, Nathan Chancellor a écrit :
> >Under certain conditions, the 64-bit '-mstack-protector-guard' flags may
> >end up in the 32-bit vDSO flags, resulting in build failures due to the
> >structure of clang's argument parsing of the stack protector options,
> >which validates the arguments of the stack protector guard flags
> >unconditionally in the frontend, choking on the 64-bit values when
> >targeting 32-bit:
> >
> > clang: error: invalid value 'r13' in 'mstack-protector-guard-reg=',
> > expected one of: r2
> > clang: error: invalid value 'r13' in 'mstack-protector-guard-reg=',
> > expected one of: r2
> > make[3]: *** [arch/powerpc/kernel/vdso/Makefile:85:
> > arch/powerpc/kernel/vdso/vgettimeofday-32.o] Error 1
> > make[3]: *** [arch/powerpc/kernel/vdso/Makefile:87:
> > arch/powerpc/kernel/vdso/vgetrandom-32.o] Error 1
> >
> >Remove these flags by adding them to the CC32FLAGSREMOVE variable, which
> >already handles situations similar to this. Additionally, reformat and
> >align a comment better for the expanding CONFIG_CC_IS_CLANG block.
>
> Is the problem really exclusively for 32-bit VDSO on 64-bit kernel ?
> In any case, it is just wrong to have anything related to stack
> protection in VDSO, for this reason we have the following in Makefile:
>
> ccflags-y += $(call cc-option, -fno-stack-protector)
>
> If it is not enough, should we have more complete ?
The -mstack-protector-guard-reg= doesn't do anything if you aren't
doing stack protection. It allows any base register (so, r1..r31).
Setting it to any valid reg should be fine and not do anything harmful,
unless perhaps you *do* enable stack protector, then it better be the
expected stuff ;-)
Apparently clang does not implement it correctly? This is just a clang
bug, please report it with them?
(r2 is the default for -m32, r13 is the default for -m64, it appears
that clang does not implement this option at all, it simply checks if
you set the default, and explodes if not).
Segher
next prev parent reply other threads:[~2024-11-06 13:40 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-30 18:41 [PATCH] powerpc/vdso: Drop -mstack-protector-guard flags in 32-bit files with clang Nathan Chancellor
2024-11-06 8:55 ` Christophe Leroy
2024-11-06 13:37 ` Segher Boessenkool [this message]
2024-11-06 15:21 ` Nathan Chancellor
2024-11-06 18:29 ` Segher Boessenkool
2024-11-17 12:09 ` Michael Ellerman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20241106133752.GG29862@gate.crashing.org \
--to=segher@kernel.crashing.org \
--cc=christophe.leroy@csgroup.eu \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=llvm@lists.linux.dev \
--cc=mpe@ellerman.id.au \
--cc=nathan@kernel.org \
--cc=patches@lists.linux.dev \
--cc=stable@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).