turn off VDSO on glibc side

[heroxbd]

Dear Guys and Gals,

I am trying to get a toolchain of gcc-4.7.2/glibc-2.17/binutils-2.23
running on RHEL 5.6 box with kernel 2.6.18-238.el5, as a normal user in
a directory prefix.

The bootstrap of gcc fails in stage2, because of a non-functional cc1.

,----
| build/gcc $ ./cc1
| cc1: internal compiler error: Segmentation fault
| Please submit a full bug report,
| with preprocessed source if appropriate.
| See <http://bugs.gentoo.org/> for instructions.
`----

gdb this cc1 gives (don't worry, lib and usr/lib are also 64 bit
libraries in my setup),

,----
| Program received signal SIGSEGV, Segmentation fault.
| 0x00002aaaaaacd6eb in ?? ()
| (gdb) info sharedlibrary
| From To Syms Read Shared Object Library
| 0x00002aaaaaaabb70 0x00002aaaaaac5079 Yes (*) /home/benda/gnto/lib64/ld-linux-x86-64.so.2
| No linux-vdso.so.1
| 0x00002aaaaacd49b0 0x00002aaaaace4480 Yes (*) /home/benda/gnto/usr/lib/libmpc.so.3
| 0x00002aaaaaef4cd0 0x00002aaaaaf38c08 Yes (*) /home/benda/gnto/usr/lib/libmpfr.so.4
| 0x00002aaaab151280 0x00002aaaab19d658 Yes (*) /home/benda/gnto/usr/lib/libgmp.so.10
| 0x00002aaaab3b5090 0x00002aaaab3b5b50 Yes (*) /home/benda/gnto/lib/libdl.so.2
| 0x00002aaaab5ba7b0 0x00002aaaab5c6bb0 Yes (*) /home/benda/gnto/usr/lib/libz.so.1
| 0x00002aaaab7d4a30 0x00002aaaab83d068 Yes (*) /home/benda/gnto/lib/libm.so.6
| 0x00002aaaabaef660 0x00002aaaabc1e800 Yes (*) /home/benda/gnto/lib/libc.so.6
| (*): Shared library is missing debugging information.
`----

stepping the program shows that Segmentation fault is emitted by
gettimeofday call, which belongs to vdso.

After some STFW, it seems related to

https://bugzilla.redhat.com/show_bug.cgi?id=673616

The question is, can I just disable vdso loading in dynamic linker of
glibc instead of requesting SA to upgrade the kernel?


PS, gcc-4.7.2 built against host glibc-2.5 works fine.

PS2, the toolchains here are from Gentoo, not sure if it is related to
Gentoo patches.

PS3, the problematic binray runs fine on other hosts. I am sure the bug
is from this glibc and kernel combination.

PS4, I tried glibc-2.{9,13,16} as well with no luck. The code of gcc
triggering Segmentation fault are different though, not sure if this
indicates something.

Cheers,
Benda

related link:

http://stackoverflow.com/questions/17406389/is-it-possible-to-turn-off-vdso-on-glibc-side

[Mike Frysinger]

Post by heroxbd
After some STFW, it seems related to
https://bugzilla.redhat.com/show_bug.cgi?id=673616
The question is, can I just disable vdso loading in dynamic linker of
glibc instead of requesting SA to upgrade the kernel?

there aren't any configure flags or runtime knobs that i know of on the glibc
side of things. you could edit elf/dl-support.c and try commenting out the
parts that handle AT_SYSINFO and AT_SYSINFO_EHDR. or edit
sysdeps/unix/sysv/linux/x86_64/gettimeofday.c and force it to always use the
syscall version at the end of the file.

or upgrade your kernel to one that isn't buggy :p

Post by heroxbd
PS2, the toolchains here are from Gentoo, not sure if it is related to
Gentoo patches.

i doubt it. but maybe i'm partial :p.
-mike

[heroxbd]

Hey Mike,

Good to see you! I'm on list, so no need to Cc me.

Post by Mike Frysinger
there aren't any configure flags or runtime knobs that i know of on
the glibc side of things. you could edit elf/dl-support.c and try
commenting out the parts that handle AT_SYSINFO and AT_SYSINFO_EHDR.
or edit sysdeps/unix/sysv/linux/x86_64/gettimeofday.c and force it to
always use the syscall version at the end of the file.

Mike, you rock! It would take me hours or days to find out the right
place to hack. Thanks a lot.

Expecting it to be easier, I tried the second approach, gcc bootstrapped
happily. But the problem remains for clock_gettime, used by patch,
failing in the same pattern. I am afraid I have to disable vdso
completely for this kernel, not only part of functions it provides, in
order not to have my system crash in later unexpected places.

More on that later on the first apprach.

Post by Mike Frysinger
or upgrade your kernel to one that isn't buggy :p

Yeah. At the same time, RHEL is our main use case for Prefix/libc where
glibc is too old. I think doing the patch on our side is better than
getting users to upgrade their already-set-up-but-easy-to-break or
hard-to-request-kernel-upgrade-VPS systems.

Cheers,
Benda

[Carlos O'Donell]

Post by heroxbd

Post by Mike Frysinger
or upgrade your kernel to one that isn't buggy :p

Yeah. At the same time, RHEL is our main use case for Prefix/libc where
glibc is too old. I think doing the patch on our side is better than
getting users to upgrade their already-set-up-but-easy-to-break or
hard-to-request-kernel-upgrade-VPS systems.

What problem are you trying to solve?

May I ask why you want a new glibc?

I ask because if you just want a new compiler you could use the
Developer Toolset (DTS) to get the benefit of newer compilers,
linkers, and tools without the need to recompile the entire base
runtime (uses the system glibc).

If you want new API's from glibc, then that's a problem DTS
can't fix.

Cheers,
Carlos.

[heroxbd]

Dear Carlos,

Post by Carlos O'Donell

Post by heroxbd

Post by Mike Frysinger
or upgrade your kernel to one that isn't buggy :p

Yeah. At the same time, RHEL is our main use case for Prefix/libc where
glibc is too old. I think doing the patch on our side is better than
getting users to upgrade their already-set-up-but-easy-to-break or
hard-to-request-kernel-upgrade-VPS systems.

What problem are you trying to solve?
May I ask why you want a new glibc?

In a sub project of Gentoo called Prefix, we allow normal user to
install a Gentoo in a prefix[1]. In the Linux variant of Prefix, we
share glibc and linux kernel with the host, while build other parts from
Gentoo portage tree.

glibc from RHEL5, however, is 2.5 and do not have support for
fortify. This causes a variety of issues[2,3,4], some of them are
resolved with a dirty hack[4], some of them are still hidden.

To address this issue, we are trying to get independent from host
glibc[5]. Then we met this vdso bug in RHEL-5.6 kernel.

Post by Carlos O'Donell
I ask because if you just want a new compiler you could use the
Developer Toolset (DTS) to get the benefit of newer compilers,
linkers, and tools without the need to recompile the entire base
runtime (uses the system glibc).

Thanks for the offer. I am wondering as a set of tools built around
system glibc, how DTS handles fortify. Does it disable it completely?

Post by Carlos O'Donell
If you want new API's from glibc, then that's a problem DTS
can't fix.

I am afraid so.

Cheers,
Benda

1. http://prefix.gentoo.org
2. http://thread.gmane.org/gmane.linux.gentoo.alt/6459
3. http://thread.gmane.org/gmane.linux.gentoo.alt/6110
4. https://bugs.gentoo.org/show_bug.cgi?id=289757
5. http://wiki.gentoo.org/wiki/Prefix/libc

[Carlos O'Donell]

Post by heroxbd
Thanks for the offer. I am wondering as a set of tools built around
system glibc, how DTS handles fortify. Does it disable it completely?

If the host glibc doesn't have fortify then it won't be used.
Thus it doesn't solve you needs.

It sounds like you have a full solution to your problem.

Cheers,
Carlos.

[heroxbd]

Hey Mike,

Post by Mike Frysinger
there aren't any configure flags or runtime knobs that i know of on
the glibc side of things. you could edit elf/dl-support.c and try
commenting out the parts that handle AT_SYSINFO and AT_SYSINFO_EHDR.

I've pursued this approach. So far a base system was built around the
patched glibc on that vdso-buggy kernel, verifying that it works. Here I
attach a simple (and ugly) patch I used to disable VDSO completely for
completeness.

Thanks a lot!

Benda

[Mike Frysinger]

Post by heroxbd

Post by Mike Frysinger
there aren't any configure flags or runtime knobs that i know of on
the glibc side of things. you could edit elf/dl-support.c and try
commenting out the parts that handle AT_SYSINFO and AT_SYSINFO_EHDR.

I've pursued this approach. So far a base system was built around the
patched glibc on that vdso-buggy kernel, verifying that it works. Here I
attach a simple (and ugly) patch I used to disable VDSO completely for
completeness.

i'm not sure there's a way to generalize this, and i don't think this is a
patch i want to carry in Gentoo's glibc build. i don't have a good answer
short of "upgrade your kernel". sucks either way.
-mike

[Carlos O'Donell]

Post by Mike Frysinger

Post by heroxbd

Post by Mike Frysinger
there aren't any configure flags or runtime knobs that i know of on
the glibc side of things. you could edit elf/dl-support.c and try
commenting out the parts that handle AT_SYSINFO and AT_SYSINFO_EHDR.

I've pursued this approach. So far a base system was built around the
patched glibc on that vdso-buggy kernel, verifying that it works. Here I
attach a simple (and ugly) patch I used to disable VDSO completely for
completeness.

i'm not sure there's a way to generalize this, and i don't think this is a
patch i want to carry in Gentoo's glibc build. i don't have a good answer
short of "upgrade your kernel". sucks either way.

A runtime tunable might get you part of the way but it would
be disabled for AT_SECURE. Would that help?

I'll add this to the list of things users want to control.

Cheers,
Carlos.

[Siddhesh Poyarekar]

Post by heroxbd
After some STFW, it seems related to
https://bugzilla.redhat.com/show_bug.cgi?id=673616
The question is, can I just disable vdso loading in dynamic linker of
glibc instead of requesting SA to upgrade the kernel?

Ask the SA to upgrade the kernel unless there's a really good reason
to stay on an old, possibly vulnerable kernel. You've solved the
wrong problem by disabling vdso.

Siddhesh
--
http://siddhesh.in

[heroxbd]

Hi Siddhesh,

Post by Siddhesh Poyarekar
Ask the SA to upgrade the kernel unless there's a really good reason
to stay on an old, possibly vulnerable kernel. You've solved the
wrong problem by disabling vdso.

I totally agree with you, and don't like this solution either. At the
same time, in real life having a hack like this is better than nothing.

Cheers,
Benda