[ruby-core:118233] [Ruby master Bug#20154] aarch64: configure overrides `-mbranch-protection` if it was set in CFLAGS via environment

Issue #20154 has been updated by vo.x (Vit Ondruch).


kjtsanaktsidis (KJ Tsanaktsidis) wrote in #note-7:
> Ah yeah, I did see that - I'll try and tackle these two together.

=F0=9F=91=8D

> * From a distro-packager perspective, how do you expect CFLAGS vs XCFLAGS=
 to behave? When you set `CFLAGS=3D...`, do you expect those to carry over =
to native gems installed with `gem install`? Are there ever flags you want =
to apply to Ruby that you don't want to apply to gems? Or do you just not c=
are at all because you package gems in separate RPM's with your own CFLAGS =
there too, and nobody should ever `gem install` with a distro-provided Ruby=
?

I wish we could ignore `gem install`, but there is too many gems around (an=
d Bundler). That leaves us in unfortunate place, because we struggle with i=
ssues such as [this](https://bugzilla.redhat.com/show_bug.cgi?id=3D1284684)=
.

IOW for RPM, we are setting the flags and configure options like this:

https://github.com/rpm-software-management/rpm/blob/8ab304f173379e539329aaf=
528920f50cee68638/macros.in#L1017-L1051

What e.g. `configure` detects on build system does not match with user inst=
allation. It might be difference in tools / libraries installed but also di=
fferent HW which would benefit from different optimizations.


> * Do you know how other autoconf-based programs handle optimistically tur=
ning on things like `-DFORTIFY_SOURCE` or `-mbranch-protection` by default?

Unfortunately, I am hardly expert on autoconf. In general, I am fan of opti=
mistically enabling features such as `-DFORTIFY_SOURCE`. After all, Fedora =
might just benefit if this kind of features are already tested / supported =
upstream. OTOH, Fedora sometimes leads in those effort as in this case.

> It seems to me that a lot of problems would go away if we prepended stuff=
 like this to the user-provided flags, rather than appended it (since gcc w=
ill just pick the last one). Is that normal, do you think?

I am hardly expert on compiler command line. For me it would be certainly e=
asier, if I saw each flag just one time. But prepending might generally pro=
vide results close to expected state. I think this is also my answer to you=
r `gcc $XCFLAGS $CFLAGS` question.

> It seems that if you build with CFLAGS=3D, you totally overwrite Ruby's d=
efault optimisation flags & warning flags, whereas if you use cflags=3D, yo=
u prepend to them (or you can specifically overwrite optflags=3D etc). I gu=
ess you build with CFLAGS=3D because you really do want to decide for yours=
elf what the compilation flags should be including all the warnings etc - i=
s that right?

The consistency of compilation options is one of the advantages of distribu=
tions such as Fedora. However there is more, e.g. supporting multiple archi=
tectures. I just trust the toolchain folks that the default set is the best=
 for Fedora.

But we might be missing some flags which would be beneficial for Ruby in Fe=
dora. I am happy to learn about those.

----------------------------------------
Bug #20154: aarch64: configure overrides `-mbranch-protection` if it was se=
t in CFLAGS via environment
https://bugs.ruby-lang.org/issues/20154#change-108731

* Author: jprokop (Jarek Prokop)
* Status: Open
* Assignee: kjtsanaktsidis (KJ Tsanaktsidis)
* ruby -v: ruby 3.3.0 (2023-12-25 revision 5124f9ac75) [aarch64-linux]
* Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN
----------------------------------------
Recently a GH PR was merged <https://github.com/ruby/ruby/pull/9306> For PA=
C/BTI support on ARM CPUs for Coroutine.S.

Without proper compilation support in configure.ac it segfaults Ruby with f=
ibers on CPUs where PAC is supported: https://bugs.ruby-lang.org/issues/200=
85

At the time of writing, configure.ac appends the first option from a list f=
or flag `-mbranch-protection` that successfully compiles a program <https:/=
/github.com/ruby/ruby/blob/master/configure.ac#L829>,
to XCFLAGS and now also ASFLAGS to fix issue 20085 for Ruby master.

This is suboptimal for Fedora as we set -mbranch-protection=3Dstandard by d=
efault in C{,XX}FLAGS:
```
CFLAGS=3D'-O2 -flto=3Dauto -ffat-lto-objects -fexceptions -g -grecord-gcc-s=
witches -pipe -Wall -Werror=3Dformat-security -Werror=3Dimplicit-function-d=
eclaration -Werror=3Dimplicit-int -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=
=3D3 -Wp,-D_GLIBCXX_ASSERTIONS -specs=3D/usr/lib/rpm/redhat/redhat-hardened=
-cc1 -fstack-protector-strong -specs=3D/usr/lib/rpm/redhat/redhat-annobin-c=
c1  -mbranch-protection=3Dstandard -fasynchronous-unwind-tables -fstack-cla=
sh-protection -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer '
export CFLAGS
CXXFLAGS=3D'-O2 -flto=3Dauto -ffat-lto-objects -fexceptions -g -grecord-gcc=
-switches -pipe -Wall -Werror=3Dformat-security -Wp,-U_FORTIFY_SOURCE,-D_FO=
RTIFY_SOURCE=3D3 -Wp,-D_GLIBCXX_ASSERTIONS -specs=3D/usr/lib/rpm/redhat/red=
hat-hardened-cc1 -fstack-protector-strong -specs=3D/usr/lib/rpm/redhat/redh=
at-annobin-cc1  -mbranch-protection=3Dstandard -fasynchronous-unwind-tables=
 -fstack-clash-protection -fno-omit-frame-pointer -mno-omit-leaf-frame-poin=
ter'
export CXXFLAGS
```

And the appended flag overrides distribution's compilation configuration, w=
hich in this case ends up omitting BTI instructions and only using PAC.

Would it make sense to check if such flags exist and not overwrite them if =
they do?

Serious proposals:
1. Simplest fix that does not overwrite what is set in the distribution and=
 results in higher security is simply prepending the list of options with `=
-mbranch-protection=3Dstandard`, it should cause no problems on ARMv8 CPUs =
and forward, BTI similarly to PAC instructions result into NOP, it is only =
extending the capability.

See attached 0001-aarch64-Check-mbranch-protection-standard-first-to-u.patc=
h


2. Other fix that sounds more sane IMO and dodges this kind of guessing whe=
re are all the correct places for the flag is what another Fedora contribut=
or Florian Weimer suggested: https://lists.fedoraproject.org/archives/list/=
[e-mail]/message/CVTNF2OQCL3XZHUUFNYMDK6ZEF2SWUEN/

"The reliable way to do this would be to compile a C file and check
whether that enables __ARM_FEATURE_PAC_DEFAULT, and if that's the case,
define a *different* macro for use in the assembler implementation.
This way, you don't need to care about the exact name of the option."

IOW instead of using __ARM_FEATURE_* directly in that code, define a macro =
in the style of "USE_PAC" with value of the feature if it is defined, I thi=
nk that way we shouldn't need to append ASFLAGS anymore.

However it's also important to catch the value of those macros as their val=
ues have meaning, I have an idea how to do that but I'd get on that monday =
earliest.

---Files--------------------------------
0001-aarch64-Check-mbranch-protection-standard-first-to-u.patch (1004 Bytes=
)


--=20
https://bugs.ruby-lang.org/