This commit is an improvement for the past commit
<d03ac3403a673a9be541f95579f2fb55a145eaf7>.
According to the following part at the commit[1] on systemtap rawhide,
systemtap-sdt-devel RPM requires systemtap-sdt-dtrace RPM including the
`dtrace` command. We can remove the systemtap-sdt-dtrace build dependency.
```
%package sdt-devel
...
Requires: systemtap-sdt-dtrace = %{version}-%{release}
```
[1] 93948388bc
Add systemtap-sdt-devel as BuildRequires to build Ruby with systemtap sdt header
files.
The commit[1] on systemtap rawhide by the change[2] on
systemtap-5.2~pre17206355g1a07290a-2.fc41 or later versions caused the
following error in the `test_systemtap.rb`.
Because the `readelf -S "#{LIBRUBY_SO}"` in the `test_systemtap.rb` failed to
find the systemtap section headers in the `libruby.so` file.
We relied on the `BuildRequires: %{_bindir}/dtrace` BuildRequires to bring in
all required files for systemtap support. However, after the change[1] that the
systemtap package was split, now we need to require systemtap sdt header files
on top of the dtrace executable to build Ruby with systemtap support to fix the
error.
```
+ make -C redhat-linux-build runruby TESTRUN_SCRIPT=/builddir/build/SOURCES/test_systemtap.rb
make: Entering directory '/builddir/build/BUILD/ruby-3.3.4-build/ruby-3.3.4/redhat-linux-build'
RUBY_ON_BUG='gdb -x /builddir/build/BUILD/ruby-3.3.4-build/ruby-3.3.4/.gdbinit -p' ./miniruby -I/builddir/build/BUILD/ruby-3.3.4-build/ruby-3.3.4/lib -I. -I.ext/common /builddir/build/BUILD/ruby-3.3.4-build/ruby-3.3.4/tool/runruby.rb --extout=.ext -- --disable-gems /builddir/build/SOURCES/test_systemtap.rb
ERROR: SystemTap (DTrace) headers were not detected in resulting library.
```
Co-authored-by: Lumír Balhar <lbalhar@redhat.com>
[1] 93948388bc
[2] https://fedoraproject.org/wiki/Changes/Separate_dtrace_package
Previously, upstream flags were overriding our configuration flags,
therefore we had two workarounds in place. This commit replaces these
workarounds by upstream solution. While it should not result in any
functional changes, it is be better to have this patch in place to make
easier to spot when it is not needed anymore.
RPM 4.20 introduce per-build directory. However, this also brings some
issues where `%{_builddir}` might have different value in different
context, leading to issues such as:
~~~
Processing files: ruby-default-gems-3.3.1-8.fc41.noarch
make: *** /builddir/build/BUILD/ruby-3.3.1/redhat-linux-build: No such file or directory. Stop.
~~~
Therefore the generators are not executed properly. Use `%define`
instead of `%global`, because those are laze evaluated and actually
suggested by RPM upstream:
https://github.com/rpm-software-management/rpm/issues/3151
This is example of current build options:
~~~
gcc -O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -march=x86-64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -mtls-dialect=gnu2 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -fPIC -m64 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -fstack-protector-strong -fno-strict-overflow -fvisibility=hidden -fexcess-precision=standard -DRUBY_EXPORT -I. -I.ext/include/x86_64-linux -I/builddir/build/BUILD/ruby-3.3.1-build/ruby-3.3.1/include -I/builddir/build/BUILD/ruby-3.3.1-build/ruby-3.3.1 -I/builddir/build/BUILD/ruby-3.3.1-build/ruby-3.3.1/prism -I/builddir/build/BUILD/ruby-3.3.1-build/ruby-3.3.1/enc/unicode/15.0.0 -o dmyext.o -c /builddir/build/BUILD/ruby-3.3.1-build/ruby-3.3.1/dmyext.c
~~~
Please note that there are included Fedora options:
~~~
-Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3
~~~
as well as upstream options:
~~~
-U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2
~~~
The problem is that the configure script cannot properly detect
`_FORTIFY_SOURCE=3` and instead of replacing that option, it includes
new definition \[[1]\]. This happens since Fedora started to use
`_FORTIFY_SOURCE=3` option. To mitigate this issue, upstream
fortification was disabled (this might or might not stay disabled
"forever").
These are the build options with this change applied for comparison:
~~~
gcc -O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -march=x86-64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -mtls-dialect=gnu2 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -fPIC -m64 -fstack-protector-strong -fno-strict-overflow -fvisibility=hidden -fexcess-precision=standard -DRUBY_EXPORT -I. -I.ext/include/x86_64-linux -I/builddir/build/BUILD/ruby-3.3.1-build/ruby-3.3.1/include -I/builddir/build/BUILD/ruby-3.3.1-build/ruby-3.3.1 -I/builddir/build/BUILD/ruby-3.3.1-build/ruby-3.3.1/prism -I/builddir/build/BUILD/ruby-3.3.1-build/ruby-3.3.1/enc/unicode/15.0.0 -o dmyext.o -c /builddir/build/BUILD/ruby-3.3.1-build/ruby-3.3.1/dmyext.c
~~~
[1]: https://bugs.ruby-lang.org/issues/20520
`checksec` output since v2.7.0 become more nuanced. Previously, the
`FORTIFY` could become just `Yes` / `No`. Now it can have also `Partial`
state, which better describe our situation.
Currently if e.g. `Fortifiable=28` and `Fortified=11`, that means that the
fortification is just partial and another 17 functions could be
fortified.
Also, check the numbers specifically, because this seems to be the
interesting information. Unfortunatelly, the results differ between
platforms.
Last but not least, use `sed` to analyze the output, because this allows to
always display the processed text. The trick comes from \[[1]\].
On top of this, use XML formatted output, which provides more context to
reader.
[1]: https://unix.stackexchange.com/questions/366/convince-grep-to-output-all-lines-not-just-those-with-matches
Resolves: rhbz#2282953
It is causing problems when network is in certain, valid, configuration.
The point of it is to workaround a glibc bug that is not present for us.
https://bugs.ruby-lang.org/issues/20208
To reproduce, have IPv6 enabled localhost but only IPv4
interfaces (such as eth0, name and count of them may vary based on system)
to disable public interfaces via sysctl:
`$ sysctl "net.ipv6.conf.<interface>.disable_ipv6=1"`
Where <interface> is NOT lo but can be eth0 or other.
Confirm with command `$ ip addr` command that only `lo`
interface has IPv6 address.
and run the following with Ruby 3.3:
~~~
$ ruby -rnet/http -e 'http = Net::HTTP.new("localhost", 8080); http.local_host = Addrinfo.tcp("localhost", 8080).ip_address; p http.get("/")'
~~~
The error is then related to EAFNOSUPPORT:
```
Errno::EAFNOSUPPORT: Failed to open TCP connection to localhost:37337 (Address family not supported by protocol - bind(2) for "::1" port 45395)
```
running above Ruby command with `strace` suggest that
there is an attempt to bind with AF_INET6
using an AF_INET socket, however, only if the reproducer above
attempts to set the `http.local_host` with Addrinfo.
From upstream issue #20208:
"This is calling getaddrinfo to resolve "localhost" for us to use
it as the local side of the connection. Because Ruby does not know
what you intend to do with this IP address, it does not make the request
with AI_ADDRCONFIG. Thus, you get an IPv6 result returned,
since there is an IPv6 addres for localhost!"
Armv8.3+ capable CPUs might segfault with incorrect compilation options.
See related upstream report: https://bugs.ruby-lang.org/issues/20085
We have hit this on COPR which uses [0] c7g.xlarge AWS flavor for aarch64
architecture builds. This machine flavor seems to fall into the ARMv8.3+
range.
Fedora CFLAGS come with `-mbranch-protection=standard` which means that
both BTI and the PAC protections are used. The option is equivalent
to `-mbranch-protection=pac-ret+bti`.
However, since the upstream configure.ac automatically appends
`-mbranch-protection=pac-ret`, the BTI protection is not used
as the last used option seems to overwrite [1] the Fedora
default for this.
To resolve both of these issues, of BTI being skipped and the potential
segfaults a patch is applied.
To fix segfaults an upstream patch was applied [2].
To fix the issue of overridden option I have patched the
configure.ac file to check for the `=standard` first when searching for a usable
`-mbranch-protection` option.
The overriding of our options was reported upstream:
<https://bugs.ruby-lang.org/issues/20154>
In the same issue I provided the extension of compilation option as an
attachment, to showcase a workaround that fixes the situation in Fedora.
[0] <https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/Y4GPCGQAZT2LJ5CE7MTIEFKGAPP6O2DW/>
[1] <https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/QWLEBS4YQH73HJNNLKCCGIIOU3SSXAYK/>
[2] <02973b78f4>
Tests fail with a LANG=C environment. A new investigation into the
failing tests on x86 revealed exact commits which introduced the issue
and the commits that fixed the situation. Fix is not yet present in Ruby
3.2, therefore the conditional disabling the tests was left in.
A new re-reported ticket replaced the old one. The new upstream ticket
includes better detailed description of the environment causing the
issue.
The tests pass in Rawhide mock (F40), as the LANG there is C.UTF-8
that does not suffer from the issue.
Upstream ticket: https://bugs.ruby-lang.org/issues/20045
libffi since NVR libffi-3.4.4-3.fc39 builds with static trampolines
enabled. This fixes the failures which were the reason for disabling
the tests.
Since it recently landed in Rawhide, we can re-enable the tests.
The rhbz#2043092 is not resolved. Nevertheless, the generation of
package notes should not break builds of rubygem- packages anymore.
Nevertheless, the additional linker options will keep making issues for
`gem install`ed gems. Nothing new here unfortunately.
Fiddle::Closure object is making use of FFI closure
from libffi. When such object is created (instantiated) in Ruby,
and then the process forks on an SELinux-enabled system, the memory
will become corrupted. That is usually not a problem until the
The garbage collector sweeps the object and tries to free it, in which case the
Ruby process will fail with signal SIGABRT.
Tests in test/fiddle/test_closure.rb, test/fiddle/test_func.rb,
and test/fiddle/test_function.rb use the `Fiddle::Closure` class
directly and fiddle/test_import.rb use the class indirectly through
`bind_function` method, therefore they are disabled to prevent
introducing the problematic object into the Ruby GC during test suite
execution instead of relying on that fork and subsequent
garbage collection will not happen.
If an FFI closure object is allocated in Ruby
and the `fork` function is used afterward, the memory
pointing to the closure gets corrupted, and if Ruby GC
tries to collect the object in that state, a SIGABRT
error occurs.
The minimal Ruby reproducer for the issue is the following:
~~~
$ cat fiddle_fork.rb
require 'fiddle/closure'
require 'fiddle/struct'
Fiddle::Closure.new(Fiddle::TYPE_VOID, [])
fork { }
GC.start
~~~
We allocate an unused Closure object,
so it is free for the GC to pick up. Before we call `GC.start`
we fork the process as that corrupts the memory.
Running this with ruby-3.1.2-167.fc37.x86_64 on SELinux enabled system:
~~~
$ ruby fiddle_fork.rb
Aborted (core dumped)
~~~
Such issues may appear at random (depending on the use of forking and GC)
in larger applications that use Fiddle::Closure but can be spotted by the
following functions appearing in the coredump backtrace:
~~~
0x00007f6284d3e5b3 in dlfree (mem=<optimized out>) at ../src/dlmalloc.c:4350
0x00007f6284d6d0b1 in dealloc () from /usr/lib64/ruby/fiddle.so
0x00007f6295e432ec in finalize_list () from /lib64/libruby.so.3.1
0x00007f6295e43420 in finalize_deferred.lto_priv () from /lib64/libruby.so.3.1
0x00007f6295e4ff1c in gc_start_internal.lto_priv () from /lib64/libruby.so.3.1
~~~
Possible solutions to prevent Ruby from crashing:
* Do not use Fiddle::Closure.
* Use the Fiddle::Closure object only in isolated subprocess that
will not fork further.
* Enable static trampolines in libffi as noted in bugzilla comment:
<https://bugzilla.redhat.com/show_bug.cgi?id=2040380#c9>
See related discussion on
<https://bugzilla.redhat.com/show_bug.cgi?id=2040380>
Ruby upstream ticket:
<https://bugs.ruby-lang.org/issues/18914>
Ruby Fiddle ticket:
<https://github.com/ruby/fiddle/issues/102>
