From nobody Wed Feb 21 13:33:43 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 4Tfy0d6zVGz5CCCS for ; Wed, 21 Feb 2024 13:33:53 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-qt1-x829.google.com (mail-qt1-x829.google.com [IPv6:2607:f8b0:4864:20::829]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Tfy0d4nskz4bKQ; Wed, 21 Feb 2024 13:33:53 +0000 (UTC) (envelope-from markjdb@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-qt1-x829.google.com with SMTP id d75a77b69052e-42dd6f6518fso20507691cf.1; Wed, 21 Feb 2024 05:33:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1708522426; x=1709127226; darn=freebsd.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:sender :from:to:cc:subject:date:message-id:reply-to; bh=hQ38+0r9mm557etxCfe8cZTWNZCfElwsfragUNTrlaY=; b=MFtBLf9O+UrvdBAGyoqsMbA+RWoR21/ZuqGqeClvdPinDZpCI0Ej2wAQ/4UJ3jkihw v/oBQGae1+Er5LuZ12gA/D90uphuzlSQjVZYzMElVVL10Tr3Tp1T72xzAGM+n3PFuTiz woxhKDL97RGUywWnEJQ/cabhs9i8XuaB6MC2UnRmXWWjCXXGzFMKnBsaS5pCRm+yVUgV kd3RzCsJsphf7ctqwQJLs8NW+Y5ZtMxbbTIMXFBtY4DhNgiT6+eBT+WduEMPhulp3+Iy yMLzo10OM3AE3+eU5ZRg44uacBVaoD+2dqHvcGDJR5LrCpma7rnOwaIrg+8iLJoGGtsZ lzSg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1708522426; x=1709127226; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:sender :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=hQ38+0r9mm557etxCfe8cZTWNZCfElwsfragUNTrlaY=; b=u46DU6EuqmyC6IJ9vkDqerMFsCnPat79doI+i5zQYkUh7XMb9KMcKw9yZqrXcRfwmC n1rgWXyQedoshJFf9DvOugZbCI0hOA+Av6airI+wtZ28vR3z4Fitpqn0Rp6WTfC4wXx+ SXtIq7dZJ4ECJysXlaYgLxWVCQK3TyeqTTpddk1S+OT29WM0SmKNR9RvhIjxnvKhlh+9 Y9PAXXJGdlnvM1bC2Ygnwr6SShZ7NFP9J0g//gkrxPPDRjmOKajN1jhMKgpoMEiwdwI7 gVd1OH5y615AaE/bawUIkESZV51aaf883BsO5UwtsOecazp5RmO0dMEFwYuxZdPIEaty uoKA== X-Forwarded-Encrypted: i=1; AJvYcCXyerVCvDuSeVTH16H43zNbj0FouwsMRobiVxAo8WJoitnw3YFblWqMfgYSZUV+QqZuu0WxPYyxmJaWr76JH1O4i/nh X-Gm-Message-State: AOJu0YwLTUcjc4nvjQc6rx17mozJQXRV/fqLLhRinIjMHfFlJwP0tECA zwZZS5BMi87BPwrtmR6hkJFeOoC6ydZbFYkXvMCnfWx3jS2T89zC7zCIzDf+ X-Google-Smtp-Source: AGHT+IHcCPd3a1r1ZgXDtx1claoTBBhnqAVp8R63cAT8em5ETusOs9jmDRJjk5ic6aj8jiBf9xNXWg== X-Received: by 2002:ad4:5baa:0:b0:68f:6c8f:ef79 with SMTP id 10-20020ad45baa000000b0068f6c8fef79mr11164950qvq.30.1708522426248; Wed, 21 Feb 2024 05:33:46 -0800 (PST) Received: from nuc (192-0-220-237.cpe.teksavvy.com. [192.0.220.237]) by smtp.gmail.com with ESMTPSA id p4-20020a0cfd84000000b0068f54ed22b2sm4612904qvr.0.2024.02.21.05.33.45 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 21 Feb 2024 05:33:45 -0800 (PST) Date: Wed, 21 Feb 2024 08:33:43 -0500 From: Mark Johnston 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: References: <385dd04f716d4b90baa826dd1b18d277@dlr.de> 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 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <385dd04f716d4b90baa826dd1b18d277@dlr.de> X-Spamd-Bar: ---- X-Rspamd-Queue-Id: 4Tfy0d4nskz4bKQ X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] 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 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 >