sys-libs/glibc-2.22 fails at "Patching to get working PIE binaries on PIE (hardened) platforms" glibc-2.20-hardened-inittls-nosysenter.patch fails Reproducible: Always Steps to Reproduce: 1.unmask and un-keyword glibc 2.22 2.attempt to emerge glibc 2.22 with hardened toolchain (gcc) 3. Actual Results: it should succeed to at least reach configure and compilation phase Expected Results: it fails upon patching phaes ======================================================== PATCH COMMAND: patch -p1 -g0 -E --no-backup-if-mismatch < '/usr/gentoo/portage/sys-libs/glibc/files/2.20/glibc-2.20-hardened-inittls-nosysenter.patch' ======================================================== checking file csu/libc-start.c Hunk #1 succeeded at 30 (offset 2 lines). Hunk #2 succeeded at 179 (offset 8 lines). Hunk #3 succeeded at 196 with fuzz 2 (offset 52 lines). checking file csu/libc-tls.c Hunk #2 FAILED at 144. 1 out of 2 hunks FAILED checking file misc/sbrk.c checking file sysdeps/unix/sysv/linux/i386/brk.c Hunk #1 succeeded at 28 (offset -3 lines). checking file sysdeps/unix/sysv/linux/i386/sysdep.h Hunk #1 succeeded at 153 (offset -34 lines). Hunk #2 FAILED at 358. Hunk #3 succeeded at 397 with fuzz 2 (offset 13 lines). Hunk #4 succeeded at 466 (offset 7 lines). Hunk #5 succeeded at 501 (offset 7 lines). 1 out of 5 hunks FAILED checking file sysdeps/i386/nptl/tls.h Hunk #1 succeeded at 190 (offset 1 line). Hunk #2 succeeded at 219 (offset 1 line). patch program exited with status 1 ========================================================
Vapier do you thing we need all the pie patches now when 2.22 support pie default? https://sourceware.org/bugzilla/show_bug.cgi?id=17841
(In reply to Magnus Granberg from comment #1) i'm not confident anyone has done real testing, including h.j.lu. his feedback so far sounds like random smoke tests than anyone (like us) doing real validation. we need to re-review each change we carry and make sure that it's actually not necessary anymore.
(In reply to SpanKY from comment #2) > (In reply to Magnus Granberg from comment #1) > > i'm not confident anyone has done real testing, including h.j.lu. his > feedback so far sounds like random smoke tests than anyone (like us) doing > real validation. we need to re-review each change we carry and make sure > that it's actually not necessary anymore. what would be a good systematic testing approach here? i can drop the patch and build stage3s for various arches, and see what breaks, but i think we'd want runtime testing too.
Created attachment 412146 [details, diff] Don't applay pie fixes. We use upstream pie fixes for this version should have the support.
the 00_all_0009-arm-fix-PIC-vs-SHARED-typos.patch is still needed for sure, but should be easier to resend it now after the big clean up in upstream commit 8c2b1ed8bbd20d35314c2a602b903159fa567ffb.
i'm fine with dropping the static pie patch if the test case posted in bug 283470 passes (see comment #12 in there): 00_all_0002-workaround-crash-when-handling-signals-in-static-PIE.patch
we can drop glibc-2.17-hardened-pie.patch, but shouldn't we also drop 62_all_binutils-2.23.52.0.1-hardened-crtbegin.patch from binutils ?
glibc-2.20-hardened-inittls-nosysenter.patch should be easy to test for. if you build glibc on x86, do you get textrels ? what if you build static ELFs ? if not, then the i386/sysdep.h code has been shifted and it should be ok to drop. if you do get textrels, then the issue is still valid and we can't drop the patch. the C library makes syscalls via SYSENTER via the %gs (TLS) register. that means it cannot use SYSENTER until TLS has been initialized, but it does so as outlined in the patch itself: - __libc_start_main calls __pthread_initialize_minimal - __pthread_initialize_minimal calls __libc_setup_tls - __libc_setup_tls calls __sbrk - __sbrk calls __brk - __brk makes a syscall (sysdeps/unix/sysv/linux/i386/brk.c) - __libc_setup_tls calls TLS_INIT_TP - TLS_INIT_TP makes a syscall (set_thread_area in sysdeps/i386/nptl/tls.h) - TLS_INIT_TP calls TLS_SET_GS to initialize %gs further, the DL_SYSDEP_OSCHECK call made by __libc_start_main happens before the pthread init which might include a uname syscall. recent versions of glibc have optimizations to avoid that syscall when possible, but it's not guaranteed. if you look at sysdeps/unix/sysv/linux/dl-sysdep.c, you'll see that _dl_discover_osversion first pokes around the vdso to try and find kernel information in it. if the vdso lacks that, then it falls back to uname, and everything fails. it also only looks at the map for shared libs, so i imagine if you compiled a static x86, it'd failed too.
(In reply to SpanKY from comment #5) the arm patch is merged upstream now: https://sourceware.org/git/?p=glibc.git;a=commit;h=3ee578690f35942f41926cc2d98e25b3d0d08c71
(In reply to SpanKY from comment #6) > i'm fine with dropping the static pie patch if the test case posted in bug > 283470 passes (see comment #12 in there): > 00_all_0002-workaround-crash-when-handling-signals-in-static-PIE.patch laptop1 / # gcc -static -o poc poc.c poc.c: In function ‘sigvtalarm’: poc.c:7:2: warning: incompatible implicit declaration of built-in function ‘printf’ printf("s\n") ; ^ poc.c: In function ‘main’: poc.c:14:2: warning: incompatible implicit declaration of built-in function ‘printf’ printf("My PID = %d\n", getpid() ) ; ^ laptop1 / # ./poc My PID = 16980 s ^C laptop1 / # Portage 2.2.20.1 (python 2.7.10-final-0, hardened/linux/amd64, gcc-4.9.3, glibc-2.22, 4.1.6-hardened-r1 x86_64) ================================================================= System uname: Linux-4.1.6-hardened-r1-x86_64-Intel-R-_Core-TM-_i7_CPU_Q_720_@_1.60GHz-with-gentoo-2.2 KiB Mem: 8095900 total, 643416 free KiB Swap: 8387580 total, 8362916 free Timestamp of repository gentoo: Sat, 12 Sep 2015 18:45:01 +0000 sh bash 4.3_p42 ld GNU ld (Gentoo 2.25.1 p1.0) 2.25.1 app-shells/bash: 4.3_p42::gentoo dev-lang/perl: 5.22.0::gentoo dev-lang/python: 2.7.10::gentoo, 3.3.5-r1::gentoo, 3.4.3::gentoo dev-util/pkgconfig: 0.28-r3::gentoo sys-apps/baselayout: 2.2::gentoo sys-apps/openrc: 0.17::gentoo sys-apps/sandbox: 2.6-r1::gentoo sys-devel/autoconf: 2.69-r1::gentoo sys-devel/automake: 1.13.4::gentoo, 1.14.1::gentoo, 1.15::gentoo sys-devel/binutils: 2.25.1::gentoo sys-devel/gcc: 4.8.4::gentoo, 4.9.3::gentoo sys-devel/gcc-config: 1.8::gentoo sys-devel/libtool: 2.4.6-r1::gentoo sys-devel/make: 4.1-r1::gentoo sys-kernel/linux-headers: 4.1::gentoo (virtual/os-headers) sys-libs/glibc: 2.22::gentoo
(In reply to Magnus Granberg from comment #10) > (In reply to SpanKY from comment #6) > > i'm fine with dropping the static pie patch if the test case posted in bug > > 283470 passes (see comment #12 in there): > > 00_all_0002-workaround-crash-when-handling-signals-in-static-PIE.patch > > laptop1 / # gcc -static -o poc poc.c > poc.c: In function ‘sigvtalarm’: > poc.c:7:2: warning: incompatible implicit declaration of built-in function > ‘printf’ > printf("s\n") ; > ^ > poc.c: In function ‘main’: > poc.c:14:2: warning: incompatible implicit declaration of built-in function > ‘printf’ > printf("My PID = %d\n", getpid() ) ; > ^ > laptop1 / # ./poc > My PID = 16980 > s > ^C This is good news. Magnus, add '#include <stdio.h>' to get rid of those warnings. Also, what's sigvalarm()? Maybe attach the poc.c.
(In reply to Anthony Basile from comment #11) > (In reply to Magnus Granberg from comment #10) > > (In reply to SpanKY from comment #6) > > > i'm fine with dropping the static pie patch if the test case posted in bug > > > 283470 passes (see comment #12 in there): > > > 00_all_0002-workaround-crash-when-handling-signals-in-static-PIE.patch > > > > laptop1 / # gcc -static -o poc poc.c > > poc.c: In function ‘sigvtalarm’: > > poc.c:7:2: warning: incompatible implicit declaration of built-in function > > ‘printf’ > > printf("s\n") ; > > ^ > > poc.c: In function ‘main’: > > poc.c:14:2: warning: incompatible implicit declaration of built-in function > > ‘printf’ > > printf("My PID = %d\n", getpid() ) ; > > ^ > > laptop1 / # ./poc > > My PID = 16980 > > s > > ^C > > This is good news. Magnus, add '#include <stdio.h>' to get rid of those > warnings. Also, what's sigvalarm()? Maybe attach the poc.c. The poc is from bug 283470 comment 12 as SpanKY was saying to test.
laptop1 / # gcc -O2 -static helloworld.c -o helloworld laptop1 / # scanelf -a helloworld TYPE PAX PERM ENDIAN STK/REL/PTL TEXTREL RPATH BIND FILE ET_EXEC ---xe- 0755 LE RW- R-- RW- - - STATIC helloworld laptop1 / # ./helloworld Hello Worldlaptop1 / # laptop1 / # laptop1 / # gcc -O2 helloworld.c -o helloworld laptop1 / # scanelf -a helloworld TYPE PAX PERM ENDIAN STK/REL/PTL TEXTREL RPATH BIND FILE ET_DYN ---xe- 0755 LE RW- R-- RW- - - NOW helloworld laptop1 / # ./helloworld Hello Worldlaptop1 / # laptop1 / # laptop1 / # cat helloworld.c #include<stdio.h> main() { printf("Hello World"); } laptop1 / # x86 with glibc 2.22 and gcc version 4.9.3 (Gentoo Hardened 4.9.3 p1.2, pie-0.6.3) have recompile nano with the new glibc and it works with no problems.
The change is commited to glibc-2.22 for more testing Commit: 02914d4a1d331d8fc07842d92b79cfb2cce2275e
(In reply to Magnus Granberg from comment #14) > The change is commited to glibc-2.22 > for more testing > Commit: 02914d4a1d331d8fc07842d92b79cfb2cce2275e Thank you, will prepare to test (backing up system beforehand + additional recovery system), anything special to look out for ?
(In reply to Magnus Granberg from comment #14) i thought i was pretty clear in comment #5 -- the arm patch is required still
(In reply to SpanKY from comment #16) > (In reply to Magnus Granberg from comment #14) > > i thought i was pretty clear in comment #5 -- the arm patch is required still Fixed. Patch 62_all_binutils-2.23.52.0.1-hardened-crtbegin.patch can be removed i think.
Haven't heard any more hardened probs with 2.22 so i think it can be close.
