Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Sanitizers use wrong version of intercepted symbols #628

Open
mikea opened this issue Nov 30, 2015 · 9 comments
Open

Sanitizers use wrong version of intercepted symbols #628

mikea opened this issue Nov 30, 2015 · 9 comments

Comments

@mikea
Copy link
Contributor

mikea commented Nov 30, 2015

Because intercepted symbols are reexported without version information, wrong version of a symbol could be used during runtime. An example would be fmemopen in glibc2.22 (#627)

kraj pushed a commit to kraj/glibc that referenced this issue Jun 10, 2016
After some discussion in libc-alpha about this POSIX compliance fix, I see
that GLIBC should indeed revert back to previous definition of msghdr and
cmsghdr and implementation of sendmsg, recvmsg, sendmmsg, recvmmsg due some
reasons:

 * The possible issue where the syscalls wrapper add the compatibility
   layer is quite limited in scope and range.  And kernel current
   also add some limits to the values on the internal msghdr and
   cmsghdr fields:

     - msghdr::msg_iovlen larger than UIO_MAXIOV (1024) returns
       EMSGSIZE.
     - msghdr::msg_controllen larger than INT_MAX returns ENOBUFS.

 * There is a small performance hit for recvmsg/sendmsg/recmmsg which
   is neglectable, but it is a big hit for sendmmsg since now instead
   of calling the syscall for the packed structure, GLIBC is calling
   multiple sendmsg.  This defeat the very existence of the syscall.

 * It currently breaks libsanitizer build on GCC [1] (I fixed on compiler-rt).
   However the fix is incomplete because it does add any runtime check
   since libsanitizer currently does not have any facility to intercept
   symbols with multiple version [2].

   This, along with incorret dlsym/dlvsym return for versioned symbol due
   another bug [3], makes hard to interpose versioned symbols.

   Also, current approach of fixing GCC PR#71445 leads to half-baked
   solutions without versioned symbol interposing.

This patch basically reverts commits 2f0dc39, 222c2d7,
af7f7c7.  I decided to not revert abf29ed (Adjust
kernel-features.h defaults for recvmsg and sendmsg) mainly because it
does not really address the POSIX compliance original issue and also
adds some cleanups.

Tested on x86, i386, s390, s390x, aarch64, and powerpc64le.

[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71445
[2] google/sanitizers#628
[3] https://sourceware.org/bugzilla/show_bug.cgi?id=14932

	* conform/data/sys/socket.h-data (msghdr.msg_iovlen): Add xfail-.
	(msghdr.msg_controllen): Likewise.
	(cmsghdr.cmsg_len): Likewise.
	* nptl/Makefile (libpthread-routines): Remove ptw-oldrecvmsg and
	ptw-oldsendmsg.
	(CFLAGS-oldrecvmsg.c): Remove rule.
	(CFLAGS-oldsendmsg.c): Likewise.
	(CFLAGS-recvmsg.c): Add rule.
	(CFLAGS-sendmsg.c): Likewise.
	* sysdeps/unix/sysv/linux/Makefile (sysdep_routines): Remove
	oldrecvmsg, oldsendmsg, oldrecvmmsg, oldsendmmsg.
	(CFLAGS-recvmsg.c): Remove rule.
	(CFLAGS-sendmsg.c): Likewise.
	(CFLAGS-oldrecvmsg.c): Likewise.
	(CFLAGS-oldsendmsg.c): Likewise.
	(CFLAGS-recvmmsg.c): Likewise.
	* sysdeps/unix/sysv/linux/bits/socket.h (msghdr.msg_iovlen): Revert
	to kernel defined interfaces.
	(msghdr.msg_controllen): Likewise.
	(cmsghdr.cmsg_len): Likewise.
	(msghdr.__glibc_reserved1): Remove member.
	(msghdr.__glibc_reserved2): Likewise.
	(cmsghdr.__glibc_reserved1): Likewise.
	* sysdeps/unix/sysv/linux/oldrecvmmsg.c: Remove file.
	* sysdeps/unix/sysv/linux/oldrecvmsg.c: Likewise.
	* sysdeps/unix/sysv/linux/oldsendmmsg.c: Likewise.
	* sysdeps/unix/sysv/linux/oldsendmsg.c: Likewise.
	* sysdeps/unix/sysv/linux/recvmmsg.c: Revert back to previous
	version.
	* sysdeps/unix/sysv/linux/recvmsg.c: Likewise.
	* sysdeps/unix/sysv/linux/sendmmsg.c: Likewise.
	* sysdeps/unix/sysv/linux/sendmsg.c: Likewise.
	* sysdeps/unix/sysv/linux/aarch64/Versions [libc] (GLIBC_2.24):
	Remove recvmsg and sendmsg.
	* sysdeps/unix/sysv/linux/alpha/Versions [libc] (GLIBC_2.24):
	Likewise.
	* sysdeps/unix/sysv/linux/hppa/Versions [libc] (GLIBC_2.24):
	Likewise.
	* sysdeps/unix/sysv/linux/i386/Versions [libc] (GLIBC_2.24): Likewise.
	* sysdeps/unix/sysv/linux/m68k/Versions [libc] (GLIBC_2.24): Likewise.
	* sysdeps/unix/sysv/linux/microblaze/Versions [libc] (GLIBC_2.24):
	Likewise.
	* sysdeps/unix/sysv/linux/mips/mips32/Versions [libc] (GLIBC_2.24):
	Likewise.
	* sysdeps/unix/sysv/linux/mips/mips64/n32/Versions
	[libc] (GLIBC_2.24): Likewise.
	* sysdeps/unix/sysv/linux/nios2/Versions [libc] (GLIBC_2.24):
	Likewise.
	* sysdeps/unix/sysv/linux/powerpc/Versions [libc] (GLIBC_2.24):
	Likewise.
	* sysdeps/unix/sysv/linux/powerpc/powerpc64/Versions
	[libc] (GLIBC_2.24): Likewise.
	* sysdeps/unix/sysv/linux/s390/s390-32/Versions [libc] (GLIBC_2.24):
	Likewise.
	* sysdeps/unix/sysv/linux/s390/s390-64/Versions [libc] (GLIBC_2.24):
	Likewise.
	* sysdeps/unix/sysv/linux/sh/Versions [libc] (GLIBC_2.24): Likewise.
	* sysdeps/unix/sysv/linux/sparc/Versions [libc] (GLIBC_2.24):
	Likewise.
	* sysdeps/unix/sysv/linux/sparc/sparc64/Versions [libc] (GLIBC_2.24):
	Likewise.
	* sysdeps/unix/sysv/linux/tile/Versions [libc] (GLIBC_2.24):
	Likewise.
	* sysdeps/unix/sysv/linux/x86_64/Versions [libc] (GLIBC_2.24):
	Likewise.
	* sysdeps/unix/sysv/linux/tile/tilegx/tilegx64/Versions: Remove file
	* sysdeps/unix/sysv/linux/x86_64/64/Versions: Likewise.
	* sysdeps/unix/sysv/linux/mips/mips64/n64/Versions: Likewise.
	* sysdeps/unix/sysv/linux/aarch64/libc.abilist: Remove new 2.24
	version for {recv,send,recm,sendm}msg.
	* sysdeps/unix/sysv/linux/alpha/libc.abilist: Likewise.
	* sysdeps/unix/sysv/linux/arm/libc.abilist: Likewise.
	* sysdeps/unix/sysv/linux/hppa/libc.abilist: Likewise.
	* sysdeps/unix/sysv/linux/i386/libc.abilist: Likewise.
	* sysdeps/unix/sysv/linux/ia64/libc.abilist: Likewise.
	* sysdeps/unix/sysv/linux/m68k/coldfire/libc.abilist: Likewise.
	* sysdeps/unix/sysv/linux/m68k/m680x0/libc.abilist: Likewise.
	* sysdeps/unix/sysv/linux/microblaze/libc.abilist: Likewise.
	* sysdeps/unix/sysv/linux/mips/mips32/fpu/libc.abilist: Likewise.
	* sysdeps/unix/sysv/linux/mips/mips32/nofpu/libc.abilist: Likewise.
	* sysdeps/unix/sysv/linux/mips/mips64/n32/libc.abilist: Likewise.
	* sysdeps/unix/sysv/linux/mips/mips64/n64/libc.abilist: Likewise.
	* sysdeps/unix/sysv/linux/powerpc/powerpc32/fpu/libc.abilist:
	Likewise.
	* sysdeps/unix/sysv/linux/powerpc/powerpc32/nofpu/libc.abilist:
	Likewise.
	* sysdeps/unix/sysv/linux/powerpc/powerpc64/libc-le.abilist: Likewise.
	* sysdeps/unix/sysv/linux/powerpc/powerpc64/libc.abilist: Likewise.
	* sysdeps/unix/sysv/linux/s390/s390-32/libc.abilist: Likewise.
	* sysdeps/unix/sysv/linux/s390/s390-64/libc.abilist: Likewise.
	* sysdeps/unix/sysv/linux/nios2/libc.abilist: Likewise.
	* sysdeps/unix/sysv/linux/sh/libc.abilist: Likewise.
	* sysdeps/unix/sysv/linux/sparc/sparc32/libc.abilist: Likewise.
	* sysdeps/unix/sysv/linux/sparc/sparc64/libc.abilist: Likewise.
	* sysdeps/unix/sysv/linux/tile/tilegx/tilegx32/libc.abilist: Likewise.
	* sysdeps/unix/sysv/linux/tile/tilegx/tilegx64/libc.abilist: Likewise.
	* sysdeps/unix/sysv/linux/tile/tilepro/libc.abilist: Likewise.
	* sysdeps/unix/sysv/linux/x86_64/64/libc.abilist: Likewise.
	* sysdeps/unix/sysv/linux/x86_64/x32/libc.abilist: Likewise.
@morehouse
Copy link
Contributor

@kcc: Is this something we intend to fix at some point?

@kcc
Copy link
Contributor

kcc commented Jun 7, 2018

dunno, nobody complained recently.

@yugr
Copy link

yugr commented Jun 8, 2018

This is still a serious issue with Asan interceptors...

@kcc
Copy link
Contributor

kcc commented Jun 8, 2018

@yugr would you like to elaborate?

@yugr
Copy link

yugr commented Jun 8, 2018

Glibc exports legacy versions of standard APIs (with different ABIs) so that applications compiled against legacy Glibc's keep working. Asan implements only the latest ABI and does not assign version information to interceptor so it'll intercept calls to legacy ABIs as well. Calling interceptor from code that was compiled against older Glibc will result in runtime crash.

@yugr
Copy link

yugr commented Jun 8, 2018

See also #778

@kcc
Copy link
Contributor

kcc commented Jun 8, 2018

let's keep it open in case someone wants to fix this (not me though).
A usual reminder: the today's strategy of using interceptors is absolutely necessary,
but if we want C/C++ to survive long term, we should push towards not having any interceptors
and just have all the code, including libc, always compiled from scratch (and thus instrumented in asan and other modes)

@kcc kcc reopened this Jun 8, 2018
@eugenis
Copy link
Contributor

eugenis commented Jun 8, 2018

This is mostly an i386 problem, where glibc has a long history of changes. For example, pthread_mutex_t layout has changed (AFAIR more than once). But that platform is almost gone by now.

As x86_64 matures, we will surely see versioned symbols for common libc functions there as well.

@valpackett
Copy link

This is a big deal for FreeBSD! Many languages, most prominently Rust (well, the libc crate) by default link to pre-ino64 symbols like stat@FBSD_1.0 to build binaries compatible with the older, 32-bit-inode ABI, i.e. FreeBSD <12.

valpackett added a commit to valpackett/rust that referenced this issue Jul 31, 2020
Unfortunately, sanitizers do not support versioned symbols[1],
so they break filesystem access via the legacy, pre-ino64 ABI.

To use sanitizers on FreeBSD >= 12, we need to build the libc
crate with LIBC_CI=1 to use the new ABI -- including the libc
used for std. But that removes the st_lspare field std was
expecting for the deprecated metadata extension.

Add a way to skip that field to allow the build to work.

[1]: google/sanitizers#628
Manishearth added a commit to Manishearth/rust that referenced this issue Jul 31, 2020
…-obk

Add sanitizer support on FreeBSD

Restarting rust-lang#47337. Everything is better now, no more weird llvm problems, well not everything:

Unfortunately, the sanitizers don't have proper support for versioned symbols (google/sanitizers#628), so `libc`'s usage of `stat@FBSD_1.0` and so on explodes, e.g. in calling `std::fs::metadata`.

Building std (now easy thanks to cargo `-Zbuild-std`) and libc with `freebsd12/13` config via the `LIBC_CI=1` env variable is a good workaround…

```
LIBC_CI=1 RUSTFLAGS="-Z sanitizer=address" cargo +san-test -Zbuild-std run --target x86_64-unknown-freebsd --verbose
```

…*except* std won't build because there's no `st_lspare` in the ino64 version of the struct, so an std patch is required:

```diff
--- i/src/libstd/os/freebsd/fs.rs
+++ w/src/libstd/os/freebsd/fs.rs
@@ -66,8 +66,6 @@ pub trait MetadataExt {
     fn st_flags(&self) -> u32;
     #[stable(feature = "metadata_ext2", since = "1.8.0")]
     fn st_gen(&self) -> u32;
-    #[stable(feature = "metadata_ext2", since = "1.8.0")]
-    fn st_lspare(&self) -> u32;
 }

 #[stable(feature = "metadata_ext", since = "1.1.0")]
@@ -136,7 +134,4 @@ impl MetadataExt for Metadata {
     fn st_flags(&self) -> u32 {
         self.as_inner().as_inner().st_flags as u32
     }
-    fn st_lspare(&self) -> u32 {
-        self.as_inner().as_inner().st_lspare as u32
-    }
 }
```

I guess std could like.. detect that `libc` isn't built for the old ABI, and replace the implementation of `st_lspare` with a panic?
valpackett added a commit to valpackett/rust that referenced this issue Aug 9, 2020
Unfortunately, sanitizers do not support versioned symbols[1],
so they break filesystem access via the legacy, pre-ino64 ABI.

To use sanitizers on FreeBSD >= 12, we need to build the libc
crate with LIBC_CI=1 to use the new ABI -- including the libc
used for std. But that removes the st_lspare field std was
expecting for the deprecated metadata extension.

Add a way to skip that field to allow the build to work.

[1]: google/sanitizers#628
bors added a commit to rust-lang-ci/rust that referenced this issue Aug 15, 2020
Add sanitizer support on FreeBSD

Restarting rust-lang#47337. Everything is better now, no more weird llvm problems, well not everything:

Unfortunately, the sanitizers don't have proper support for versioned symbols (google/sanitizers#628), so `libc`'s usage of `stat@FBSD_1.0` and so on explodes, e.g. in calling `std::fs::metadata`.

Building std (now easy thanks to cargo `-Zbuild-std`) and libc with `freebsd12/13` config via the `LIBC_CI=1` env variable is a good workaround…

```
LIBC_CI=1 RUSTFLAGS="-Z sanitizer=address" cargo +san-test -Zbuild-std run --target x86_64-unknown-freebsd --verbose
```

…*except* std won't build because there's no `st_lspare` in the ino64 version of the struct, so an std patch is required:

```diff
--- i/src/libstd/os/freebsd/fs.rs
+++ w/src/libstd/os/freebsd/fs.rs
@@ -66,8 +66,6 @@ pub trait MetadataExt {
     fn st_flags(&self) -> u32;
     #[stable(feature = "metadata_ext2", since = "1.8.0")]
     fn st_gen(&self) -> u32;
-    #[stable(feature = "metadata_ext2", since = "1.8.0")]
-    fn st_lspare(&self) -> u32;
 }

 #[stable(feature = "metadata_ext", since = "1.1.0")]
@@ -136,7 +134,4 @@ impl MetadataExt for Metadata {
     fn st_flags(&self) -> u32 {
         self.as_inner().as_inner().st_flags as u32
     }
-    fn st_lspare(&self) -> u32 {
-        self.as_inner().as_inner().st_lspare as u32
-    }
 }
```

I guess std could like.. detect that `libc` isn't built for the old ABI, and replace the implementation of `st_lspare` with a panic?
cgzones added a commit to cgzones/libconfuse that referenced this issue Sep 19, 2022
fmemopen(2) is broken with address and memory sanitizer, see
google/sanitizers#627 and
google/sanitizers#628.
cgzones added a commit to cgzones/libconfuse that referenced this issue Sep 20, 2022
fmemopen(2) is broken with address and memory sanitizer, see
google/sanitizers#628.
cgzones added a commit to cgzones/libconfuse that referenced this issue Sep 20, 2022
fmemopen(2) is broken with address and memory sanitizer, see
google/sanitizers#628.
cgzones added a commit to cgzones/libconfuse that referenced this issue Sep 22, 2022
fmemopen(2) is broken with address and memory sanitizer, see
google/sanitizers#628.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants