Bug 2167430 - redhat-rpm-config: hardening does not enable PIC mode for assembler files
Summary: redhat-rpm-config: hardening does not enable PIC mode for assembler files
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: redhat-rpm-config
Version: 38
Hardware: All
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Florian Weimer
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: 2208504
TreeView+ depends on / blocked
 
Reported: 2023-02-06 15:50 UTC by Vladis Dronov
Modified: 2023-11-03 04:25 UTC (History)
16 users (show)

Fixed In Version: redhat-rpm-config-258-1.fc39
Clone Of:
: 2208504 (view as bug list)
Environment:
Last Closed: 2023-07-05 13:58:37 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Vladis Dronov 2023-02-06 15:50:39 UTC
Hi. It looks like Fedora/RH build systems hardening (/usr/lib/rpm/redhat/redhat-hardened-cc1) does
not enable PIC mode for assembler files. This is so for both Koji and Brew builders. Some research
and some conclusions follow.

A test C or Assembly code containing some check if it is build in PIC mode or not can be just like:

#if defined(__PIC__)
#warning defined __PIC__
#else
#warning no __PIC__
#endif

This works both for C and assembly code when a PIC build is requested in a usual way with "-fPIE":

$ gcc -fPIE picpie.c
picpie.c:8:2: warning: #warning defined __PIC__ [-Wcpp]

$ gcc -fPIE picpie.S
picpie.S:8:2: warning: #warning defined __PIC__ [-Wcpp]
 
Brew/Koji build system forces PIC in an indirect way using GCC specs:

gcc -DHAVE_CONFIG_H -I.     -O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches
-pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS
-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong
-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -m32 -march=i686 -mtune=generic -msse2 -mfpmath=sse
-mstackrealign -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection
-c -o rdrand_asm.o rdrand_asm.S

It turns out that this indirect way of forcing PIC works fine with C code but does not work with Asm.
I've tried to adjust redhat-hardened-cc1 specs to work for assembly sources also, but to no success:

$ gcc -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 picpie.c
picpie.c:8:2: warning: #warning defined __PIC__ [-Wcpp]

$ gcc -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 picpie.S
picpie.S:10:2: warning: #warning no __PIC__ [-Wcpp]

This means a PIC-aware assembly code is not built as PIC in our build systems Brew and Koji.

See https://kojihub.stream.rdu2.redhat.com/kojifiles/work/tasks/796/1840796/build.log as an example:
(task: https://kojihub.stream.rdu2.redhat.com/koji/taskinfo?taskID=1840796)

gcc      -I/usr/include/libxml2    -pthread -O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -m32 -march=i686 -mtune=generic -msse2 -mfpmath=sse -mstackrealign -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -pthread -Wl,-z,relro -Wl,--as-needed  -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -o rngd rngd-rngd.o rngd-rngd_entsource.o rngd-rngd_linux.o rngd-util.o rngd-ossl_helpers.o rngd-rngd_nistbeacon.o rngd-rngd_rdrand.o rdrand_asm.o  rngd-rngd_jitter.o  rngd-rngd_qrypt.o   librngd.a -ljitterentropy     -ljansson  -lcurl  -lxml2  -lssl -lcrypto  -lcap    -ljitterentropy 
make[2]: Leaving directory '/builddir/build/BUILD/rng-tools-6.15'
/usr/bin/ld: rdrand_asm.o: warning: relocation in read-only section `.text'
/usr/bin/ld: warning: creating DT_TEXTREL in a PIE

The result here is 'rngd' executable which is supposed to be PIE is not exactly PIE, rpminspect reports:

elf: BAD: Security: /usr/sbin/rngd in rng-tools has TEXTREL relocations on i686
Suggested remedy: Ensure all object files are compiled with -fPIC

This looks like some security issue to me, though in quite a corner case - PIC-aware assembly code.
I believe it would be great if /usr/lib/rpm/redhat/redhat-hardened-cc1 is adjusted so assmbly code sees __PIC__ and __PIE__ set
the same way it is done for C code.

Comment 1 Ben Cotton 2023-02-07 15:08:30 UTC
This bug appears to have been reported against 'rawhide' during the Fedora Linux 38 development cycle.
Changing version to 38.

Comment 2 Florian Weimer 2023-05-19 11:33:00 UTC
Jakub, what's your recommendation to fix this? Thanks.

I tried this, and it appears to work:

*cc1_options:
+ %{!r:%{!fpie:%{!fPIE:%{!fpic:%{!fPIC:%{!fno-pic:-fPIE}}}}}}

*cpp_options:
+ %{!r:%{!fpie:%{!fPIE:%{!fpic:%{!fPIC:%{!fno-pic:-fPIE}}}}}}

Comment 3 Marek Polacek 2023-05-23 14:18:08 UTC
(In reply to Florian Weimer from comment #2)
> Jakub, what's your recommendation to fix this? Thanks.
> 
> I tried this, and it appears to work:
> 
> *cc1_options:
> + %{!r:%{!fpie:%{!fPIE:%{!fpic:%{!fPIC:%{!fno-pic:-fPIE}}}}}}
> 
> *cpp_options:
> + %{!r:%{!fpie:%{!fPIE:%{!fpic:%{!fPIC:%{!fno-pic:-fPIE}}}}}}

Rather than cpp_options, shouldn't it be asm_options?  Otherwise I think it makes sense.

Comment 4 Florian Weimer 2023-05-23 14:52:46 UTC
(In reply to Marek Polacek from comment #3)
> (In reply to Florian Weimer from comment #2)
> > Jakub, what's your recommendation to fix this? Thanks.
> > 
> > I tried this, and it appears to work:
> > 
> > *cc1_options:
> > + %{!r:%{!fpie:%{!fPIE:%{!fpic:%{!fPIC:%{!fno-pic:-fPIE}}}}}}
> > 
> > *cpp_options:
> > + %{!r:%{!fpie:%{!fPIE:%{!fpic:%{!fPIC:%{!fno-pic:-fPIE}}}}}}
> 
> Rather than cpp_options, shouldn't it be asm_options?  Otherwise I think it
> makes sense.

It doesn't work:

as: invalid option -- 'P'

GAS does not accept -fPIC etc., but the preprocessor does to set up __PIC__ etc. macros.

Comment 5 Marek Polacek 2023-05-23 15:00:39 UTC
Indeed, I just realized that asm_ isn't going to work.  LGTM then.

Comment 6 Red Hat Bugzilla 2023-11-03 04:25:02 UTC
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 120 days


Note You need to log in before you can comment on or make changes to this bug.