| View previous topic :: View next topic |
| How long until hardened and toolchain will produce a hardened gcc4? |
| 1 year |
|
23% |
[ 40 ] |
| 5 years |
|
20% |
[ 35 ] |
| 10 years |
|
7% |
[ 13 ] |
| lifetime |
|
4% |
[ 8 ] |
| eternity |
|
44% |
[ 76 ] |
|
| Total Votes : 172 |
|
| Author |
Message |
Dwokfur
Tux's lil' helper
Joined: 15 Sep 2006
Posts: 86
Location: Budapest, Hungary, Europe
|
 Posted: Wed Jun 03, 2009 1:33 pm Post subject: Xorg failing to fork therefore cannot invoke xkbcomp |
 |
|
Xorg.log
(**) Option "xkb_rules" "evdev"
(**) Option "xkb_model" "evdev"
(**) Option "xkb_layout" "hu,us"
(**) Option "xkb_variant" "standard"
(**) Option "xkb_options" "grp:shift_toggle,compose:ralt"
(EE) XKB: Could not invoke xkbcomp
(EE) XKB: Couldn't compile keymap
(WW) Couldn't load XKB keymap, falling back to pre-XKB keymap
grsec.log
grsec: (root:U:/usr/bin/Xorg) failed fork with errno -12 by /usr/bin/Xorg[X:pid] uid/euid:0/0 gid/egid:0/0, parent /usr/sbin/gdm-binary[gdm:pid] uid/euid:0/0 gid/egid:0/0
Anyone having symptoms like this?
https://bugs.gentoo.org/show_bug.cgi?id=272361
Regards:
Dw.
Other: Openoffice 3.1 compiles and works fine after removing stack-protector filters |
|
| Back to top |
|
 |
costel78
Guru
Joined: 20 Apr 2007
Posts: 402
|
| Posted: Fri Jun 05, 2009 9:46 am Post subject: |
|
|
I receive that:
| Code: | /usr/lib/gcc/x86_64-pc-linux-gnu/4.4.0/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib/gcc/x86_64-pc-linux-gnu/4.4.0/../../../../lib64/crt1.o: relocation R_X86_64_32S against `__libc_csu_fini' can not be used when making a shared object; recompile with -fPIC
/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.0/../../../../lib64/crt1.o: could not read symbols: Bad value
collect2: ld returned 1 exit status |
when I switch to any of:
| Code: |
[3] x86_64-pc-linux-gnu-4.3.3-nopie
[4] x86_64-pc-linux-gnu-4.3.3-nossp
[5] x86_64-pc-linux-gnu-4.3.3-vanilla
[8] x86_64-pc-linux-gnu-4.4.0-nopie
[9] x86_64-pc-linux-gnu-4.4.0-nossp
[10] x86_64-pc-linux-gnu-4.4.0-vanilla
|
The only specs that are usable are:
| Code: |
[1] x86_64-pc-linux-gnu-4.3.3
[2] x86_64-pc-linux-gnu-4.3.3-nofortify
[6] x86_64-pc-linux-gnu-4.4.0
[7] x86_64-pc-linux-gnu-4.4.0-nofortify
|
Recompile glibc with any of usable gcc-specs and minimal CFLAGS/no LDFLAGS did not help.
This is happening since glibc upgrade to 2.10.1. As you now, downgrade of glibc is impossible.
Anybody has some clue about what's wrong, solution please ?
_________________
Sorry for my English. I'm still learning this language. |
|
| Back to top |
|
|
Dwokfur
Tux's lil' helper
Joined: 15 Sep 2006
Posts: 86
Location: Budapest, Hungary, Europe
|
| Posted: Fri Jun 05, 2009 2:09 pm Post subject: Re: Xorg failing to fork therefore cannot invoke xkbcomp |
|
|
| Dwokfur wrote: |
grsec.log
grsec: (root:U:/usr/bin/Xorg) failed fork with errno -12 by /usr/bin/Xorg[X:pid] uid/euid:0/0 gid/egid:0/0, parent /usr/sbin/gdm-binary[gdm:pid] uid/euid:0/0 gid/egid:0/0
|
The issue might be related to PaX/Grsec. It popped only on the Athlon MP server, while no sigs of fork failures on my Pentium M laptop. The toolchain is the same. I'll get back upon any news on it. BTW hardened-sources-2.6.28-r8 failed to load on that Athlon MP, while the laptop was doing well. When I was about to take a screen capture of the remote console, hardened-sources-2.6.29 came out and the kernel loaded well. There were no problems except for the fork failure.
Please note, that the last portage update issued a message about layout.conf and repos.conf. According to the portage manpage these can be used to configure how eclasses of overlays takes precedence over eachother.
Xake-toolchain can make use of that. However it won't provide a solution for emerge --regen. Although the speed of regen was greatly improved since I'm using the experimental toolchain. I was happy to see "pic" useflag for xvid: great! The developers of x264 might follow the same path sometimes.
Regards,
Dw. |
|
| Back to top |
|
|
zorry
Developer
Joined: 30 Mar 2008
Posts: 380
Location: Umeå The north part of scandinavia
|
| Posted: Sun Jun 07, 2009 3:08 pm Post subject: |
|
|
| costel78 wrote: | I receive that:
| Code: | /usr/lib/gcc/x86_64-pc-linux-gnu/4.4.0/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib/gcc/x86_64-pc-linux-gnu/4.4.0/../../../../lib64/crt1.o: relocation R_X86_64_32S against `__libc_csu_fini' can not be used when making a shared object; recompile with -fPIC
/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.0/../../../../lib64/crt1.o: could not read symbols: Bad value
collect2: ld returned 1 exit status |
when I switch to any of:
| Code: |
[3] x86_64-pc-linux-gnu-4.3.3-nopie
[4] x86_64-pc-linux-gnu-4.3.3-nossp
[5] x86_64-pc-linux-gnu-4.3.3-vanilla
[8] x86_64-pc-linux-gnu-4.4.0-nopie
[9] x86_64-pc-linux-gnu-4.4.0-nossp
[10] x86_64-pc-linux-gnu-4.4.0-vanilla
|
The only specs that are usable are:
| Code: |
[1] x86_64-pc-linux-gnu-4.3.3
[2] x86_64-pc-linux-gnu-4.3.3-nofortify
[6] x86_64-pc-linux-gnu-4.4.0
[7] x86_64-pc-linux-gnu-4.4.0-nofortify
|
Recompile glibc with any of usable gcc-specs and minimal CFLAGS/no LDFLAGS did not help.
This is happening since glibc upgrade to 2.10.1. As you now, downgrade of glibc is impossible.
Anybody has some clue about what's wrong, solution please ? |
okey will look at it when i have update the espf patch and specs.
_________________
gcc version 6.1.0 (Gentoo Hardened 6.1.0 p1.1) |
|
| Back to top |
|
|
costel78
Guru
Joined: 20 Apr 2007
Posts: 402
|
| Posted: Sun Jun 07, 2009 3:17 pm Post subject: |
|
|
By adding make gcc to be able to compile stuff with vanilla specs.
But I have to admit that I don't fully understand the implications of doing this. As I understand studying the problem this is due to problems linking code compiled with -fPIC and code compiled without it.
_________________
Sorry for my English. I'm still learning this language. |
|
| Back to top |
|
|
radegand
n00b
Joined: 22 Aug 2008
Posts: 45
Location: Poland
|
| Posted: Sun Jun 14, 2009 11:41 am Post subject: Re: Xorg failing to fork therefore cannot invoke xkbcomp |
|
|
| Dwokfur wrote: | Xorg.log
Anyone having symptoms like this?
|
Not sure if I'm using xkbcomp for different keyboard layouts - I'm relying on the standard KDE setting and it works fine, no grsec related errors...what would be the best way to test this issue?
| Quote: |
Other: Openoffice 3.1 compiles and works fine after removing stack-protector filters
|
Hmm...It seems that it compiled fine on x86 with stack protector using gcc 4.3.3 and glibc 2.10, see below: -
| Code: |
$ ./checksec.sh --proc-all
COMMAND PID RELRO STACK CANARY NX PIE ASLR
firefox 13967 Full RELRO Canary found NX enabled PIE enabled ASLR enabled
gconfd-2 13969 Full RELRO Canary found NX enabled PIE enabled ASLR enabled
bash 21111 Full RELRO Canary found NX enabled PIE enabled ASLR enabled
bash 21126 Full RELRO Canary found NX enabled PIE enabled ASLR enabled
soffice.bin 22370 Full RELRO Canary found NX enabled PIE enabled ASLR enabled
|
Awesome!  Checksec.sh script can be found here.
I only modified the 3.1.0 ebuild following the 3.0.1 ebuild from overlay adding this:
| Code: |
if [[ $(gcc-major-version) -lt 4 ]] ; then
filter-flags "-fstack-protector"
filter-flags "-fstack-protector-all"
fi
|
But that should affect only gcc < 4, or? Nevertheless - it worked!  |
|
| Back to top |
|
|
kernelOfTruth
Watchman
Joined: 20 Dec 2005
Posts: 6111
Location: Vienna, Austria; Germany; hello world :)
|
| Posted: Sun Jun 14, 2009 12:42 pm Post subject: Re: Xorg failing to fork therefore cannot invoke xkbcomp |
|
|
| radegand wrote: |
[snip] ... [snip]
Hmm...It seems that it compiled fine on x86 with stack protector using gcc 4.3.3 and glibc 2.10, see below: -
| Code: |
$ ./checksec.sh --proc-all
COMMAND PID RELRO STACK CANARY NX PIE ASLR
firefox 13967 Full RELRO Canary found NX enabled PIE enabled ASLR enabled
gconfd-2 13969 Full RELRO Canary found NX enabled PIE enabled ASLR enabled
bash 21111 Full RELRO Canary found NX enabled PIE enabled ASLR enabled
bash 21126 Full RELRO Canary found NX enabled PIE enabled ASLR enabled
soffice.bin 22370 Full RELRO Canary found NX enabled PIE enabled ASLR enabled
|
Awesome! Checksec.sh script can be found here.
[snip] ... [snip] |
great find, radegand ! 
_________________
https://github.com/kernelOfTruth/ZFS-for-SystemRescueCD/tree/ZFS-for-SysRescCD-4.9.0
https://github.com/kernelOfTruth/pulseaudio-equalizer-ladspa
Hardcore Gentoo Linux user since 2004 |
|
| Back to top |
|
|
zorry
Developer
Joined: 30 Mar 2008
Posts: 380
Location: Umeå The north part of scandinavia
|
| Posted: Sun Jun 14, 2009 8:20 pm Post subject: |
|
|
New espf patch and specs for GCC 4.4.0 is out and i hope it fix some bugs.
_________________
gcc version 6.1.0 (Gentoo Hardened 6.1.0 p1.1) |
|
| Back to top |
|
|
kernelOfTruth
Watchman
Joined: 20 Dec 2005
Posts: 6111
Location: Vienna, Austria; Germany; hello world :)
|
|
| Back to top |
|
|
costel78
Guru
Joined: 20 Apr 2007
Posts: 402
|
| Posted: Mon Jun 15, 2009 9:45 am Post subject: |
|
|
| Code: | /usr/lib/gcc/x86_64-pc-linux-gnu/4.4.0/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib/gcc/x86_64-pc-linux-gnu/4.4.0/../../../../lib64/crt1.o: relocation R_X86_64_32S against `__libc_csu_fini' can not be used when making a shared object; recompile with -fPIC
/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.0/../../../../lib64/crt1.o: could not read symbols: Bad value
collect2: ld returned 1 exit status |
error is gone.
Tonight I'll let the machine to build both test server (64 and 32 bits version) and I'll come back with details.
Thank you!
_________________
Sorry for my English. I'm still learning this language. |
|
| Back to top |
|
|
kernelOfTruth
Watchman
Joined: 20 Dec 2005
Posts: 6111
Location: Vienna, Austria; Germany; hello world :)
|
|
| Back to top |
|
|
qjim
n00b
Joined: 10 May 2008
Posts: 23
|
| Posted: Mon Jun 15, 2009 8:19 pm Post subject: |
|
|
zorry: 3 weeks ago you asked for `file test` compiled by new gcc-4.4. My current output from new gcc-4.4.0-r4 (p1.1, espf-0.2.9) (compiled by gcc-4.3.3-r3 p1.1, espf-0.2.0) is still same - "test: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), for GNU/Linux 2.6.9, dynamically linked (uses shared libs), not stripped". 
Is it mean, that I need recompile the entire toolchain again? But which tools? Both my gcc-4.3.3/4.4.0 are producing same results: "dynamically linked (uses shared libs)"!
Can you recommend some procedure? |
|
| Back to top |
|
|
kernelOfTruth
Watchman
Joined: 20 Dec 2005
Posts: 6111
Location: Vienna, Austria; Germany; hello world :)
|
|
| Back to top |
|
|
zorry
Developer
Joined: 30 Mar 2008
Posts: 380
Location: Umeå The north part of scandinavia
|
| Posted: Mon Jun 15, 2009 10:22 pm Post subject: |
|
|
| qjim wrote: | zorry: 3 weeks ago you asked for `file test` compiled by new gcc-4.4. My current output from new gcc-4.4.0-r4 (p1.1, espf-0.2.9) (compiled by gcc-4.3.3-r3 p1.1, espf-0.2.0) is still same - "test: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), for GNU/Linux 2.6.9, dynamically linked (uses shared libs), not stripped".
Is it mean, that I need recompile the entire toolchain again? But which tools? Both my gcc-4.3.3/4.4.0 are producing same results: "dynamically linked (uses shared libs)"!
Can you recommend some procedure? |
The probs was that file did't have all the check built in for pie suff on the older one.
So dynamically linked (uses shared libs) is okey.
_________________
gcc version 6.1.0 (Gentoo Hardened 6.1.0 p1.1) |
|
| Back to top |
|
|
zorry
Developer
Joined: 30 Mar 2008
Posts: 380
Location: Umeå The north part of scandinavia
|
| Posted: Mon Jun 15, 2009 10:26 pm Post subject: |
|
|
| kernelOfTruth wrote: | zorry, could you please re-add the nofortify specs / profile for gcc 4.4.0 / espf?
| Quote: | [15] x86_64-pc-linux-gnu-4.3.3
[16] x86_64-pc-linux-gnu-4.3.3-nofortify
[17] x86_64-pc-linux-gnu-4.3.3-nopie
[18] x86_64-pc-linux-gnu-4.3.3-nossp_all
[19] x86_64-pc-linux-gnu-4.3.3-vanilla
[20] x86_64-pc-linux-gnu-4.4.0 *
[21] x86_64-pc-linux-gnu-4.4.0-nopie
[22] x86_64-pc-linux-gnu-4.4.0-nossp
[23] x86_64-pc-linux-gnu-4.4.0-vanilla |
many thanks in advance |
Will do that when i can remove gentoo's fortify patch from the ebuild.
Need to add some doc stuff and code.
_________________
gcc version 6.1.0 (Gentoo Hardened 6.1.0 p1.1) |
|
| Back to top |
|
|
costel78
Guru
Joined: 20 Apr 2007
Posts: 402
|
| Posted: Thu Jun 18, 2009 6:55 pm Post subject: |
|
|
With gcc-4.4.0-r4 I get
| Code: | | general protection ip:7f12f950debe sp:7fff0c3c82a0 error:0 in libGL.so |
using nvidia-drivers-180.60 no matter if I compile it with nopie profile or vanilla adding -fstack-protector -D_FORTIFY_SOURCE=2
With previous version I was able to use nvidia-drivers compiled with vanilla profile and having hardened flags in my CFLAGS.
Anyone know a workaround ?
_________________
Sorry for my English. I'm still learning this language. |
|
| Back to top |
|
|
kernelOfTruth
Watchman
Joined: 20 Dec 2005
Posts: 6111
Location: Vienna, Austria; Germany; hello world :)
|
| Posted: Thu Jun 18, 2009 7:54 pm Post subject: |
|
|
| costel78 wrote: | With gcc-4.4.0-r4 I get
| Code: | | general protection ip:7f12f950debe sp:7fff0c3c82a0 error:0 in libGL.so |
using nvidia-drivers-180.60 no matter if I compile it with nopie profile or vanilla adding -fstack-protector -D_FORTIFY_SOURCE=2
With previous version I was able to use nvidia-drivers compiled with vanilla profile and having hardened flags in my CFLAGS.
Anyone know a workaround ? |
that would be nice to know 
for me this problem appeared since >180.29 so 180.29 is the last release which allows me to work with full hardened toolchain 
the only "solution" with newer nvidia drivers releases right now is to stop using hardened gcc for everything X-related, qt, gnome, gtk, opengl related and switching to non-hardened gcc, manually adding hardened flags - like I've already mentioned in previous posts 
in this regard xf86-video-ati, radeonhd and fglrx FTW 
_________________
https://github.com/kernelOfTruth/ZFS-for-SystemRescueCD/tree/ZFS-for-SysRescCD-4.9.0
https://github.com/kernelOfTruth/pulseaudio-equalizer-ladspa
Hardcore Gentoo Linux user since 2004 |
|
| Back to top |
|
|
costel78
Guru
Joined: 20 Apr 2007
Posts: 402
|
| Posted: Fri Jun 19, 2009 5:44 am Post subject: |
|
|
| kernelOfTruth wrote: | the only "solution" with newer nvidia drivers releases right now is to stop using hardened gcc for everything X-related, qt, gnome, gtk, opengl related and switching to non-hardened gcc, manually adding hardened flags - like I've already mentioned in previous posts
|
Yes, I saw your previous post in page 26 of this thread, but not using hardened-gcc is not an option in my case.
The strange thing is that nvidia-drivers worked when I compiled it with vanilla-sources and -fstack-protector -D_FORTIFY_SOURCE=2 flags.
I'll downgrade to 180.29 and I'll stay with it until and this problem will disappear (if it will )
_________________
Sorry for my English. I'm still learning this language. |
|
| Back to top |
|
|
forsaken1
n00b
Joined: 30 May 2008
Posts: 27
Location: Lovely Skåne, Sweden
|
| Posted: Tue Jun 23, 2009 1:13 pm Post subject: |
|
|
| I'm trying to compile 2.6.30 with gcc version 4.4.0 (Gentoo Hardened 4.4.0-r4 p1.1, espf-0.2.9) and I have enabled stack-protector in the kernel config but it seems that the config script in the kernel doesn't recognize that gcc supports stack-protector. Running the script manually returns "n". |
|
| Back to top |
|
|
zorry
Developer
Joined: 30 Mar 2008
Posts: 380
Location: Umeå The north part of scandinavia
|
| Posted: Tue Jun 23, 2009 4:47 pm Post subject: |
|
|
| forsaken1 wrote: | | I'm trying to compile 2.6.30 with gcc version 4.4.0 (Gentoo Hardened 4.4.0-r4 p1.1, espf-0.2.9) and I have enabled stack-protector in the kernel config but it seems that the config script in the kernel doesn't recognize that gcc supports stack-protector. Running the script manually returns "n". |
We have disable SSP for kernel in the spec to support older kernels and some modules that don't work with SSP.
I would't run SSP in the kernel before it is well tested.
_________________
gcc version 6.1.0 (Gentoo Hardened 6.1.0 p1.1) |
|
| Back to top |
|
|
kernelOfTruth
Watchman
Joined: 20 Dec 2005
Posts: 6111
Location: Vienna, Austria; Germany; hello world :)
|
| Posted: Tue Jun 23, 2009 5:07 pm Post subject: |
|
|
| zorry wrote: | | forsaken1 wrote: | | I'm trying to compile 2.6.30 with gcc version 4.4.0 (Gentoo Hardened 4.4.0-r4 p1.1, espf-0.2.9) and I have enabled stack-protector in the kernel config but it seems that the config script in the kernel doesn't recognize that gcc supports stack-protector. Running the script manually returns "n". |
We have disable SSP for kernel in the spec to support older kernels and some modules that don't work with SSP.
I would't run SSP in the kernel before it is well tested. |
is there a way to test if CONFIG_CC_STACKPROTECTOR or CONFIG_CC_STACKPROTECTOR_ALL is enabled in the kernel / working ?
thanks for your ongoing efforts !
_________________
https://github.com/kernelOfTruth/ZFS-for-SystemRescueCD/tree/ZFS-for-SysRescCD-4.9.0
https://github.com/kernelOfTruth/pulseaudio-equalizer-ladspa
Hardcore Gentoo Linux user since 2004 |
|
| Back to top |
|
|
forsaken1
n00b
Joined: 30 May 2008
Posts: 27
Location: Lovely Skåne, Sweden
|
| Posted: Tue Jun 23, 2009 6:48 pm Post subject: |
|
|
| zorry wrote: | We have disable SSP for kernel in the spec to support older kernels and some modules that don't work with SSP.
I would't run SSP in the kernel before it is well tested. |
Ok, do you mean well tested for this version of gcc or generally ?
I've been using it since it was available without any problems. |
|
| Back to top |
|
|
zorry
Developer
Joined: 30 Mar 2008
Posts: 380
Location: Umeå The north part of scandinavia
|
| Posted: Tue Jun 23, 2009 10:25 pm Post subject: |
|
|
| forsaken1 wrote: | | zorry wrote: | We have disable SSP for kernel in the spec to support older kernels and some modules that don't work with SSP.
I would't run SSP in the kernel before it is well tested. |
Ok, do you mean well tested for this version of gcc or generally ?
I've been using it since it was available without any problems. |
Only x86 and amd64 arch support SSP in the kernel and we have the same spec to all arch.
But i can change that in the specs in next patch.
_________________
gcc version 6.1.0 (Gentoo Hardened 6.1.0 p1.1) |
|
| Back to top |
|
|
forsaken1
n00b
Joined: 30 May 2008
Posts: 27
Location: Lovely Skåne, Sweden
|
| Posted: Wed Jun 24, 2009 8:51 am Post subject: |
|
|
| zorry wrote: | | forsaken1 wrote: | | zorry wrote: | We have disable SSP for kernel in the spec to support older kernels and some modules that don't work with SSP.
I would't run SSP in the kernel before it is well tested. |
Ok, do you mean well tested for this version of gcc or generally ?
I've been using it since it was available without any problems. |
Only x86 and amd64 arch support SSP in the kernel and we have the same spec to all arch.
But i can change that in the specs in next patch. |
Ok, no need to change it for me, I changed the script to return "y". |
|
| Back to top |
|
|
jamario
n00b
Joined: 22 May 2009
Posts: 10
|
| Posted: Wed Jun 24, 2009 3:17 pm Post subject: |
|
|
| Xake wrote: | | costel78 wrote: | | Unfortunately I don't use qemu. Is there any specific tests you are interested about ? |
No it was exactly things like that I wanted to know. Running anything in qemu is intresting, but since the bugs @ bugs.gentoo.org is about compilation failure when not filtering hardened I wanted to know if this is still true with qemu-0.10 and hardened.
I have tried compiling qemu-0.10 in 32-bit userland and 64-bit userland with gcc-3.4.6 from portage and gcc-4.3.3 from overlay.
It seems like on x86 it compiles fine, on amd64 I get the same error you got.
As far as I can tell after searching around the bugzilla the filtering is there becouse dyngen did not compile with it. However dyngen was dumped upstream in qemu-0.10 due to being hard to port to new versions of gcc, and it seems like the source was fixed so qemu does not need to be filtered anymore.
I have reported a bug @ b.g.o, 270421. |
I compiled qemu 0.10.5 on my 2.6.28-hardened-49 amd64 machine (I had to remove the filter flags). However it is terminated by PAX with the default flags, I turn them off, and I get a segfault after running the VM. The help menu displays fine, the actual VM has an issue though, I only tried toggling SDL so far and looked a bit with gdb. I saw that it hits line 3800 ("ret = cpu_exec(env);") in vl.c a few times and then segfaults. The backtrace doesn't help either, it seems to have jumped to some address that doesn't exist. |
|
| Back to top |
|
|
|
Gentoo Chat
(perhaps related to hardened, espf)