From nobody Sat Feb 3 09:15:09 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 4TRn6S51gSz590qm for ; Sat, 3 Feb 2024 09:15:12 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: from mail-ot1-x32f.google.com (mail-ot1-x32f.google.com [IPv6:2607:f8b0:4864:20::32f]) (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 4TRn6S2wFnz4W3G; Sat, 3 Feb 2024 09:15:12 +0000 (UTC) (envelope-from mjguzik@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ot1-x32f.google.com with SMTP id 46e09a7af769-6e0f43074edso1772530a34.1; Sat, 03 Feb 2024 01:15:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1706951710; x=1707556510; darn=freebsd.org; h=cc:to:subject:message-id:date:from:references:in-reply-to :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=i/q1jJ3aV/iP7WaCFKsQYKyDAZlrkUVHqqE0Zo807aA=; b=PaylmUAMHzQqRPfQFQvrXyru56XeimPAnSbz9itu2QHe+hsgrgWr8SQdwYGCF6kTvE vYvrn6vwYIQ8KHaA7Dty/8eFKHre2NmvxSPBbWbZg0WPQE+6Mb/sld6V7YwsZ27PlNxZ WLria2N1PEXkSEt6FDrC8cLosRwFwCsBSrj0M2d8gbLSKIm/2hWo72JIvmwbX5U1NNMp qiJL5crBHlB+4Mtjz0B9LHeJEtqkdQuJWp3EGiA+gopw277HpYTjpOS+I+JsFW82eozE 1SC9cmRcKEwcEgiIVXq8uwwovU79Tuqcw/+1mhOBRXbcSlrCaNLTaN7qWFuUhUJpY7Zw hyZw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706951710; x=1707556510; h=cc:to:subject:message-id:date:from:references:in-reply-to :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=i/q1jJ3aV/iP7WaCFKsQYKyDAZlrkUVHqqE0Zo807aA=; b=tUeGmrGJesbQBsWJd4wBXrBtZX7Wn/vDa1/fg+1D6rI+1GXxB+JqS9QbaIfCmCWAwV GYnt2//Drn7KABPmSG5iPQNtvS5/9raSunZx4ZboAZlzDoXuChvkuZrIcDvFHfZoU9WO Jf/UIH4kRTWXLcjQ3U7f9yOWVPrbiMySdDdQ3TDRK/KxzTPcDVKOAA4UNQkEzhGLh5uR nDNiZuKD5zt3mnElHhd6SNMUgu4JX2DRS1aLVoB4t27Ky37kfD/q1zxRIQbghDuxbPB4 2801q3NHbifb72TITYsec0O6uCNFyq1ur6IgCkRnhLJ2MU8PmvWJGaZvyYibsnzd6hTg 3cTQ== X-Gm-Message-State: AOJu0YwyDr/0xrQpnZcxiO9A6l7KeSsmDHUSnLL+OmNGnbYozR3kzAB8 fgarq/SjiaU5+N37hx3fYmNhKwgILSH6KpTzEsNVlj5jbAkFA7cMEezFpPyFKMVFVbM7cZRm9jA swW8B1xNhd0bqB5vuVMu8cCaI+2Gs6zMV X-Google-Smtp-Source: AGHT+IE5cNkE3GLVBhyMqOFpPUQvgOwkp/K2sJ2g+lHKLhgn+AF8CVo25doC63+Ryy/Ak/XUk/6nG1wjZDv4SE+/imM= X-Received: by 2002:a9d:631a:0:b0:6dd:e134:935c with SMTP id q26-20020a9d631a000000b006dde134935cmr4361088otk.28.1706951710096; Sat, 03 Feb 2024 01:15:10 -0800 (PST) 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 Received: by 2002:ac9:4645:0:b0:517:6330:dd0f with HTTP; Sat, 3 Feb 2024 01:15:09 -0800 (PST) In-Reply-To: References: From: Mateusz Guzik Date: Sat, 3 Feb 2024 10:15:09 +0100 Message-ID: Subject: Re: libc/libsys split coming soon To: Brooks Davis Cc: current@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4TRn6S2wFnz4W3G X-Spamd-Bar: ---- 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 2/2/24, Brooks Davis wrote: > 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. > Do I read it correctly that everything dynamically linked will also be linked to libsys, as in executing such a binary will now require loading one extra .so? Binary startup is very slow, for example execve of a hello world binary in a Linux-based chroot on FreeBSD is faster by a factor of 2 compared to a native one. As such perf-wise this looks like a step in the wrong direction. Is there a problem making it so that libc ends up unchanged, but all the bits are available separately in libsys if one does not want libc? -- Mateusz Guzik