From nobody Wed Feb 21 20:12:41 2024 X-Original-To: current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Tg6rr3tBMz5BGsq for ; Wed, 21 Feb 2024 20:12:44 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Tg6rr2sGJz46hT; Wed, 21 Feb 2024 20:12:44 +0000 (UTC) (envelope-from dim@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1708546364; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=DnfGdWDl2r3GNuuBXwZjafl5q9yJiPGOPtmrr9p6UL4=; b=J2uMDOj3pc980Yx83Rl9Q/4xsWqweUa26W2323BdQngyGzH2YQUCPaFsE+diV+95jlqx8l +/CLeiB6M3SX8ON7j6lsVGbxskVj03o3LK1TC7M59hN4dgdG2GVpdU1N1jY3ZDukG6A1CS zmqgHIgy1UDsFlFDQrz2G6ILpK50dgTKWGa+cvXg9r0waJKic5y7g9rvZMe+8IzF0CNuKn XaaKDPomKAUSQCDhzYi8vKZHQqBawAllL31EASyDnqsEhmKSODFPNZoDOsbSANmQ6H89/H FAJB/T+UGlqyuq1pt51YHB22KpbdgmDim48wr78MpVHjuNwpzg3EDqWSqlTzig== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1708546364; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=DnfGdWDl2r3GNuuBXwZjafl5q9yJiPGOPtmrr9p6UL4=; b=JhMdUYHAyIGTwqCLchplSF6HHPO68rSJfoyb0/X91kNEAICEPnYIwbl3GauEY9DXAa6Yke 2ZVrlhdA4DpWdGySuQ1jYX14A8N7WzwXfOOxzqtjDwOiwP3DYmW5of6PDS7vnCE0qK1KVg dasGvKWrirnGRkwx4N39MenS5v8urBmaMlXbzGNkQkvc5jIM7GTC8kcRgOXTfo+MWVAiTv 89/Dkti2wBJ+h0n0Wa3a5iBctxyomVcBZIP6XyrNht3zSTcOHsAckBV5J1KdDZxTYY3CT1 7LAaySKFKF3Oz5f5kxUZkgyYImTK2S7gBbf2JOWsKQRC95eR47QtKWYnK8VyEw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1708546364; a=rsa-sha256; cv=none; b=pcWiq9HhdZETVJA/pXTXXiAU1CmCq3SZ5kanDT3xvraKBLUUvltLycrRMiVzqRLytj49UM cG0f+Ng/4JDivhRhvajAjjVl4lwX5UxZILLl30CUYZ1RhTUWi/v9iSigLmMUz/rkPun5vQ wuOYifMtK5/gBxJOQdjEE4uX8ADe39rbBwtffsIOTzAj69Cs8XhaCHQFhDKs5sM3VA1ZdR mj1JIfWxuehjBmtrW395rlo4bSumtX890Z8m02BQ0jV0ghuJj3qb1edye8nAJ1grVuSg8P polLNEJEDtz2TfksAa34LO1h/Cck9VvSjTL5XN5iH7NK5XoO5f7xzUhplCGSNA== Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "tensor.andric.com", Issuer "R3" (verified OK)) (Authenticated sender: dim) by smtp.freebsd.org (Postfix) with ESMTPSA id 4Tg6rr0jYlz16mS; Wed, 21 Feb 2024 20:12:44 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from smtpclient.apple (longrow.home.andric.com [192.168.0.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 079A24580; Wed, 21 Feb 2024 21:12:42 +0100 (CET) Content-Type: text/plain; charset=us-ascii List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.700.6.1.1\)) Subject: Re: sanitizers broken (was RE: libc/libsys split coming soon) From: Dimitry Andric In-Reply-To: Date: Wed, 21 Feb 2024 21:12:41 +0100 Cc: Hartmut.Brandt@dlr.de, current@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <0AC1DB30-95D4-4199-95D1-F5D654C09E17@FreeBSD.org> References: <385dd04f716d4b90baa826dd1b18d277@dlr.de> To: Brooks Davis X-Mailer: Apple Mail (2.3731.700.6.1.1) Can't we just add libsys.so to the /usr/lib/libc.so linker script? That = would work for everything except static linking? -Dimitry > On 21 Feb 2024, at 21:00, Brooks Davis wrote: >=20 > TL;DR: you can work around this by adding -lsys to the link line and I > aim to improve the situation soon. >=20 > The sanitizers reach somewhat questionably into libc internals that = are > exported to allow rtld to update them. I was unable to find an = solution > that didn't break this and I felt that fixing things like closefrom() > using non-deprecated syscalls was more important than avoiding changes > to the sanitizer interface. >=20 > I'm trying to find a way to better solution to the sanitizer. A few > ideas I'm considering: > - Teach clang to add -lsys when linking with sanitizers on sufficently > new systems (con: doesn't fix gcc). > - Make the symbol weak in the sanitizer and complain when it's not > found or call back to using environ. The latter migth have > limitations around direct exec with rtld. > - Relocate __elf_aux_vector to csu so the symbol is always available. > - Adding a new interface to access __elf_aux_vector directly. >=20 > I'll continue to work on this. >=20 > -- Brooks >=20 > On Wed, Feb 21, 2024 at 09:52:23AM +0000, Hartmut.Brandt@dlr.de wrote: >> Hi, >>=20 >> I updated yesterday and now event a minimal program with >>=20 >> cc -fsanitize=3Daddress >>=20 >> produces >>=20 >> 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) >>=20 >> I think this is caused by the libsys split. >>=20 >> Cheers, >> Harti >>=20 >> -----Original Message----- >> From: 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 >>=20 >> 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). >>=20 >> Code: https://github.com/freebsd/freebsd-src/pull/908 >>=20 >> 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). >>=20 >> 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. >>=20 >> 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. >>=20 >> Additionally, libthr is now linked with libsys to provide = _umtx_op_err(). >>=20 >> 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. >>=20 >> 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=3D276391 >> - Kyua tests in poudriere amd64 jails: same 359 failures as with the >> latest freebsdci build >>=20 >> 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. >>=20 >> 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. >>=20 >> See also: >> - Solaris Linker and Libraries Guide: >> https://docs.oracle.com/cd/E23824_01/html/819-0690/chapter4-4.html >>=20 >> -- Brooks