Bug 2356302

Summary: When compiling Python with systemtap support, the branch protections on aarch64 do not get applied
Product: [Fedora] Fedora Reporter: Charalampos Stratakis <cstratak>
Component: python3.11Assignee: Charalampos Stratakis <cstratak>
Status: CLOSED ERRATA QA Contact:
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: rawhideCC: cstratak, mhroncok, python-maint, python-packagers-sig, thrnciar, torsava, vstinner
Target Milestone: ---   
Target Release: ---   
Hardware: aarch64   
OS: Unspecified   
Whiteboard:
Fixed In Version: python3.11-3.11.12-2.fc43 Doc Type: ---
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2025-04-17 02:15:59 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Charalampos Stratakis 2025-03-31 20:13:33 UTC 
This bug was initially created as a copy of Bug #2350935



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
Comment 1 Charalampos Stratakis 2025-03-31 23:25:06 UTC 
PRs:
https://src.fedoraproject.org/rpms/python3.11/pull-request/176
https://src.fedoraproject.org/rpms/python3.11/pull-request/177
https://src.fedoraproject.org/rpms/python3.11/pull-request/178
https://src.fedoraproject.org/rpms/python3.11/pull-request/179
Comment 2 Fedora Update System 2025-04-17 02:11:08 UTC 
FEDORA-2025-2c2d0957d1 (python3.11-3.11.12-2.fc43) has been submitted as an update to Fedora 43.
https://bodhi.fedoraproject.org/updates/FEDORA-2025-2c2d0957d1
Comment 3 Fedora Update System 2025-04-17 02:15:59 UTC 
FEDORA-2025-2c2d0957d1 (python3.11-3.11.12-2.fc43) has been pushed to the Fedora 43 stable repository.
If problem still persists, please make note of it in this bug report.