Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 21 Feb 2024 08:33:43 -0500
From:      Mark Johnston <markj@freebsd.org>
To:        Hartmut.Brandt@dlr.de
Cc:        brooks@freebsd.org, current@freebsd.org
Subject:   Re: sanitizers broken (was RE: libc/libsys split coming soon)
Message-ID:  <ZdX7t6cmuZ-lB7TH@nuc>
In-Reply-To: <385dd04f716d4b90baa826dd1b18d277@dlr.de>
References:  <385dd04f716d4b90baa826dd1b18d277@dlr.de>

next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Feb 21, 2024 at 09:52:23AM +0000, Hartmut.Brandt@dlr.de wrote:
> Hi,
> 
> I updated yesterday and now event a minimal program with
> 
> cc -fsanitize=address
> 
> produces
> 
> ld: error: undefined symbol: __elf_aux_vector
> >>> referenced by sanitizer_linux_libcdep.cpp:950 (/usr/src/contrib/llvm-project/compiler-rt/lib/sanitizer_common/sanitizer_linux_libcdep.cpp:950)
> >>>               sanitizer_linux_libcdep.o:(__sanitizer::ReExec()) in archive /usr/lib/clang/17/lib/freebsd/libclang_rt.asan-x86_64.a
> cc: error: linker command failed with exit code 1 (use -v to see invocation)
> 
> I think this is caused by the libsys split.

I don't see any such problem on a system running 5f7ac491eef4, which
includes the libsys split.  Which compiler are you using, and which
revision are you running?

> Cheers,
> Harti
> 
> -----Original Message-----
> From: owner-freebsd-current@freebsd.org <owner-freebsd-current@freebsd.org> On Behalf Of Brooks Davis
> Sent: Friday, February 2, 2024 11:32 PM
> To: current@freebsd.org
> Subject: libc/libsys split coming soon
> 
> TL;DR: The implementation of system calls is moving to a seperate library (libsys).  No changes are required to existing software (except to ensure that libsys is present when building custom disk images).
> 
> Code: https://github.com/freebsd/freebsd-src/pull/908
> 
> After nearly a decade of intermittent work, I'm about to land a series of patches which moves system calls, vdso support, and libc's parsing of the ELF auxiliary argument vector into a separate library (libsys).  I plan to do this early next week (February 5th).
> 
> This change serves three primary purposes:
>   1. It's easier to completely replace system call implementations for
>      tracing or compartmentalization purposes.
>   2. It simplifies the implementation of restrictions on system calls such
>      as those implemented by OpenBSD's msyscall(2)
>      (https://man.openbsd.org/msyscall.2).
>   3. It allows language runtimes to link with libsys for system call
>      implementations without requiring libc.
> 
> libsys is an auxiliary filter for libc.  This means that for any symbol defined by both, the libsys version takes precedence at runtime.  For system call implementations, libc contains empty stubs.  For others it contains copies of the functions (this could be further refined at a later date).  The statically linked libc contains the full implementations so linking libsys is not required.
> 
> Additionally, libthr is now linked with libsys to provide _umtx_op_err().
> 
> The overall implementation follows https://reviews.freebsd.org/D14609,
> but is redone from scratch as multiple commits to facilitate review and assist git's rename detection.
> 
> Testing:
>   - Boot testing on amd64, aarch64, and riscv
>   - make tinderbox (prior version, final run in progress)
>   - exp-run: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=276391
>   - Kyua tests in poudriere amd64 jails: same 359 failures as with the
>     latest freebsdci build
> 
> Thanks to Ali Mashtizadeh and Tal Garfinkel for D14609 and many apologies for not landing this in a timely manner.  Additional thanks to kib@ for many rounds of review, markj@ and kib@ for debugging rtld issues exposed by this patch, and antoine@ for exp-runs.
> 
> Future work:
>   - Purely functional interfaces to system calls (no errorno).
>     Unfortunately there isn't an obvious way to do this without
>     significant (possibly generated) assembly code.
>   - Investigate msyscall(2) and pinsyscalls(2).
>   - Reduce the size of stubs in libc.  I’ve errored on the
>     side of not touching the copies that end up in libc to keep diff
>     size down.  We might want to generate empty stubs instead.
> 
> See also:
>   - Solaris Linker and Libraries Guide:
>     https://docs.oracle.com/cd/E23824_01/html/819-0690/chapter4-4.html
> 
> -- Brooks
> 



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?ZdX7t6cmuZ-lB7TH>