From nobody Sat Feb 3 18:10:14 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 4TS1044G2jz586Nh for ; Sat, 3 Feb 2024 18:10:28 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ed1-x52d.google.com (mail-ed1-x52d.google.com [IPv6:2a00:1450:4864:20::52d]) (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 4TS1042Ytqz4lkv for ; Sat, 3 Feb 2024 18:10:28 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ed1-x52d.google.com with SMTP id 4fb4d7f45d1cf-56001d49cc5so1556264a12.2 for ; Sat, 03 Feb 2024 10:10:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1706983826; x=1707588626; darn=freebsd.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=Tbv2B20jmNJ3pKqe+GZDJ/XSlRR5WRbCO1p0QYKK5K4=; b=WN+/5WwAGWU8SJJ8qpOEL4TRs8cWheiflGgeZ1/yufZH706V1UZqlwtbLBtKSDXZlV jqAn2yN3vMhKgjBJH4K1Fkkmqf4phVziMiPPPB00BrucZ90w4SabzxtQo/sPLIPGQ5Aa 7N9ApTgiHz3LRpCPLM7fjUT9DtuSH6aIDmBAdX8aaa0iJfCxa0T+jAVZkC8U16BYPRzh Eln+H9Dj5qPZlCZ/WfkXePVe0EO2bjqsvm/bqtBlLOHNcybun3t+GZDUEHTbJFVAzW0D DfT3QY5NPBvxIykE3yrR3D8sCRpfy8csB0Bg1cc/246S6ALQby4aLhgBiAyNZo9srGnZ cR9Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706983826; x=1707588626; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=Tbv2B20jmNJ3pKqe+GZDJ/XSlRR5WRbCO1p0QYKK5K4=; b=dTMnRks+H6COpX3dKXqhICRSYyZwmy9IffItcSq6G6vqZJS/k0OON0CcSrOrpQH6rf CDRR1rysw3xA/0GyjNYu7REORcxS0oPfDpY3tapfw5GNDUdhHDUsNJQ6btln2/E/Xk3F NyEZFMJ4MqpgTyVgrcEssVfIEmQbfrL872n+R18Mf9CIfKUg6Ukn3n6f+g8oQUcCzdpQ 85UR9XJdrcZHn0xNc57hFgdFRe+lE8KfYCQtB0j+QHqM+rBDJhz+VLR4CKgegGnIW3Ua hkXr1DFmSjptueLey7rPkdbvKVmiIfFp/XHBca5SftEYi10H+rZ66SVMvekB4dwXUp8y Bf3w== X-Gm-Message-State: AOJu0YytcJLPO29ZqbwSYG51MzPCyv8atYsX/0fsAByTJvmLy7hUTVlb REcZ/BGFfForlKLZ7+tCujoVryuz+o8eiFcX1gHx6V5ZwJVgulc1WUoetlZb9QJp9flJmI62dI8 LY1bxPE25ION1Vv5x5CuB8W1VBRroDsWJSXnroA== X-Google-Smtp-Source: AGHT+IFW8ktuvkiEQFEyNcEZUGdLyp727t8EHcgbfybeFdcMxGRw+iq3sDdxdkKhrNMhiJlJ1M7ulC5+/uAvf+Mtr+M= X-Received: by 2002:aa7:d804:0:b0:55d:3d64:3ba6 with SMTP id v4-20020aa7d804000000b0055d3d643ba6mr1959517edq.29.1706983826458; Sat, 03 Feb 2024 10:10:26 -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 References: <458c2a3b-1139-4449-a4a9-f23782686dea@app.fastmail.com> <082DBB76-B8B0-4583-BDE4-B6DCD1DAD133@vigrid.com> In-Reply-To: From: Warner Losh Date: Sat, 3 Feb 2024 11:10:14 -0700 Message-ID: Subject: Re: libc/libsys split coming soon To: Konstantin Belousov Cc: Daniel Eischen , Brooks Davis , FreeBSD Current , Dave Cottlehuber Content-Type: multipart/alternative; boundary="0000000000009d1e9706107e2491" X-Rspamd-Queue-Id: 4TS1042Ytqz4lkv 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:2a00:1450::/32, country:US] --0000000000009d1e9706107e2491 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, Feb 3, 2024, 11:02=E2=80=AFAM Konstantin Belousov wrote: > On Sat, Feb 03, 2024 at 11:05:10AM -0500, Daniel Eischen wrote: > > Will this break binary compatibility with older programs expecting thos= e > symbols in libc and not linked to libsys? > > As was mentioned, libc filters libsys. This means that libc exports all > the same symbols as before, but forward the implementation to libsys. > For apps nothing changes, the introduction of libsys is (should be) ABI > compatible. > > More, I would state that no binaries wanting to state binary-compatble > with future FreeBSD should link to libsys directly, at least for now. > How do you view Golang or Rust run times using this then? They try to avoid libc today. Warner Warner > > > > > On Feb 3, 2024, at 3:39=E2=80=AFAM, Dave Cottlehuber > wrote: > > > > > > =EF=BB=BFOn Fri, 2 Feb 2024, at 23:31, 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 seri= es > > >> of patches which moves system calls, vdso support, and libc's parsin= g > 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 fo= r > > >> 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. > > > > > > Awesome! So (3) is generally considered ideal for languages like > zig[1], rust or go, to use directly? > > > > > > What=E2=80=99s the appropriate mechanism for such a language to know = which > version of FreeBSD it=E2=80=99s talking to, to ensure syscall table match= es the > languages expectations? > > > > > > It would be nice to hear about any experiments in (2) and how that > compares to things such as capsicum. > > > > > > [1]: https://github.com/ziglang/zig/issues/165 > > > > > > A+ > > > Dave > > > > > > > > > > > > --0000000000009d1e9706107e2491 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sat, Feb 3, 2024, 11:02=E2=80=AFAM Konstantin Belou= sov <kostikbel@gmail.com> = wrote:
On Sat, Feb 03, 2024 at 11:0= 5:10AM -0500, Daniel Eischen wrote:
> Will this break binary compatibility with older programs expecting tho= se symbols in libc and not linked to libsys?

As was mentioned, libc filters libsys.=C2=A0 This means that libc exports a= ll
the same symbols as before, but forward the implementation to libsys.
For apps nothing changes, the introduction of libsys is (should be) ABI
compatible.

More, I would state that no binaries wanting to state binary-compatble
with future FreeBSD should link to libsys directly, at least for now.

How do= you view Golang or Rust run times using this then? They try to avoid libc = today.

Warner

Warner
>
> > On Feb 3, 2024, at 3:39=E2=80=AFAM, Dave Cottlehuber <dch@skun= kwerks.at> wrote:
> >
> > =EF=BB=BFOn Fri, 2 Feb 2024, at 23:31, Brooks Davis wrote:
> >> TL;DR: The implementation of system calls is moving to a sepe= rate
> >> library (libsys).=C2=A0 No changes are required to existing s= oftware (except
> >> to ensure that libsys is present when building custom disk im= ages).
> >>
> >> Code: https://github.com/fre= ebsd/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&#= 39;s parsing of
> >> the ELF auxiliary argument vector into a separate library (li= bsys).=C2=A0 I
> >> plan to do this early next week (February 5th).
> >>
> >> This change serves three primary purposes:
> >>=C2=A0 1. It's easier to completely replace system call im= plementations for
> >>=C2=A0 =C2=A0 =C2=A0tracing or compartmentalization purposes.<= br> > >>=C2=A0 2. It simplifies the implementation of restrictions on = system calls such
> >>=C2=A0 =C2=A0 =C2=A0as those implemented by OpenBSD's msys= call(2)
> >>=C2=A0 =C2=A0 =C2=A0(https://man.openbsd.o= rg/msyscall.2).
> >>=C2=A0 3. It allows language runtimes to link with libsys for = system call
> >>=C2=A0 =C2=A0 =C2=A0implementations without requiring libc. > >
> > Awesome! So (3) is generally considered ideal for languages like = zig[1], rust or go, to use directly?
> >
> > What=E2=80=99s the appropriate mechanism for such a language to k= now which version of FreeBSD it=E2=80=99s talking to, to ensure syscall tab= le matches the languages expectations?
> >
> > It would be nice to hear about any experiments in (2) and how tha= t compares to things such as capsicum.
> >
> > [1]: https://github.com/ziglang/zig/is= sues/165
> >
> > A+
> > Dave
> >
> >
>
>

--0000000000009d1e9706107e2491--