When compiling Python with the --with-dtrace configure flag during RPM build on aarch64 with the -mbranch-protection=standard flag, for applying the Branch Target Identification(BTI) protections, the resulting object file (pydtrace.o) doesn't contain the protections and the associated elf note, resulting in the final shared library missing the note. Using python3.11, as later versions contain assembly sources that interfere with the results. Everything looks good when compiling on a non-rpmbuild environment: ./configure --with-dtrace && make -j $ readelf -n libpython3.11.so.1.0 Properties: AArch64 feature: BTI, PAC, GCS $ objdump -d Python/pydtrace.o 0000000000000000 <__dtrace>: 0: d503245f bti c 4: d503201f nop 8: d65f03c0 ret However when building Python as an RPM the aarch64 protection flags are not there for libpython or pydtrace.o $ objdump -d Python/pydtrace.o 0000000000000000 <__dtrace>: 0: d503201f nop 4: d65f03c0 ret I wasn't able to replicate the results by simulating the rpm build on the upstream sources, aka using all our configure options and CFLAGS. The commands from the Makefile that initiate this: /usr/bin/dtrace -o Include/pydtrace_probes.h -h -s /builddir/build/BUILD/python3.11-3.11.11-build/Python-3.11.11/Include/pydtrace.d sed 's/PYTHON_/PyDTrace_/' Include/pydtrace_probes.h > Include/pydtrace_probes.h.tmp mv Include/pydtrace_probes.h.tmp Include/pydtrace_probes.h /usr/bin/dtrace -o Python/pydtrace.o -G -s /builddir/build/BUILD/python3.11-3.11.11-build/Python-3.11.11/Include/pydtrace.d Python/ceval.o Python/import.o Python/sysmodule.o Modules/gcmodule.o At the same time the equivalent protection for x86_64 get applied properly for both rpm and non-rpm builds. Filing for systemtap for now if folks have any insight on that. Reproducible: Always
Python/ceval.o Python/import.o Python/sysmodule.o and Modules/gcmodule.o all contain the note in the rpm build.
Also building the rpm in mock on an aarch64 machine and then from the BUILD directory rerunning manually: /usr/bin/dtrace -o Python/pydtrace.o -G -s /builddir/build/BUILD/python3.11-3.11.11-build/Python-3.11.11/Include/pydtrace.d Python/ceval.o Python/import.o Python/sysmodule.o Modules/gcmodule.o The results are the same, there is no "bti c" or the note in pydtrace.o
Building the upstream sources within a mock environment in an aarch64 machine didn't reproduce the issue so the problem is not mock itself.
The /usr/bin/dtrace script doesn't have a command line option to pass along extra hardening cflags. However, it observes the $CLFAGS environment variable and relays those to the inferior gcc. (This is an accidentally undocumented feature.) Consider using: env CFLAGS=$(CFLAGS) /usr/bin/dtrace -o Python/pydtrace.o -G -s [...]
(In reply to Frank Ch. Eigler from comment #4) > The /usr/bin/dtrace script doesn't have a command line option to pass along > extra hardening cflags. However, it observes the $CLFAGS environment > variable and relays those to the inferior gcc. (This is an accidentally > undocumented feature.) > > Consider using: > > env CFLAGS=$(CFLAGS) /usr/bin/dtrace -o Python/pydtrace.o -G -s [...] From some preliminary testing this seems to be working, thanks! I'll do some more testing to verify the results everywhere and propose it upstream (although systemtap support is kinda half broken at the moment). Is there any place where this could be documented?
I'll plop it into upstream man pages right away.
https://sourceware.org/git/?p=systemtap.git;a=commit;h=1b6ef910d381fca7338de1cd75065081e6bb5f1b
Thanks! Changing the component to the latest Python in Fedora.
We can wait for the next release for this.