[PATCH v2] Enable -mrop-protect through configure command

[Sachin Monga]

> I believe so, but I've asked Sachin to confirm setting CC or CFLAGS
> with -mrop-protect works.
1. -mrop-protect works well with CC but not with CFLAGS as they don’t reach .S files.
However, as Florian said CC="gcc -mrop-protect” is enough and I ‘ve checked that.
2. Also , after Adhemerval’s patch to remove strncase* functions for Power7, build faces no errors.
Regards:
Sachin.

From: Peter Bergner <bergner@linux.ibm.com>
Date: Wednesday, 30 April 2025 at 5:14 PM
To: Florian Weimer <fw@deneb.enyo.de>, Sachin Monga <smonga@linux.ibm.com>
Cc: libc-alpha@sourceware.org <libc-alpha@sourceware.org>
Subject: [EXTERNAL] Re: [PATCH v2] Enable -mrop-protect through configure command
On 4/30/25 12:29 AM, Florian Weimer wrote:
> -CFLAGS-strncase-power7.c += -mcpu=power7 -funroll-loops
> -CFLAGS-strncase_l-power7.c += -mcpu=power7 -funroll-loops
> +CFLAGS-strncase-power7.c += -mcpu=power7 -funroll-loops $(no-rop-protection)
> +CFLAGS-strncase_l-power7.c += -mcpu=power7 -funroll-loops $(no-rop-protection)
>
> This isn't necessary because the code will not run on POWER7 anyway if
> the reset of glibc is built with ROP protection.

This patch hunk _is_ necessary, but not for the reason you mention
(ie, stopping us from executing a ROP instruction on a Power7 system).
It is required to stop a compiler error during the build.  The above
-mcpu=power7 overrides the -mcpu= we've set either through --with-cpu=
or CFLAGS or CC and gcc will flag an error if you use -mpcu=power7
and -mrop-protect together.  The $(no-rop-protection) is just used to
place a -mno-rop-protect on the command line after the -mrop-protect
disabling it, so we skirt around that build error.



>> If glibc is not responsible for turning on ROP protection, there
>> doesn't seem to be anything special required in glibc for enabling it.
>> So building with CC="gcc -mrop-protect" seems to be enough?

I believe so, but I've asked Sachin to confirm setting CC or CFLAGS
with -mrop-protect works.


>> We have a special flag for stack protector because parts of glibc need
>> to be built without it.

Nod.  As I mentioned to Adhemerval, we're ok going the CC/CFLAGS route
if that is what the community prefers.

Peter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://sourceware.org/pipermail/libc-alpha/attachments/20250508/4db658f2/attachment-0001.htm>