From nobody Mon Apr 15 20:10:12 2024 X-Original-To: arch@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 4VJJF16GwJz5H0dC for ; Mon, 15 Apr 2024 20:10:13 +0000 (UTC) (envelope-from lexi@le-fay.org) Received: from fuchsia.eden.le-Fay.ORG (fuchsia.eden.le-fay.org [81.187.47.195]) by mx1.freebsd.org (Postfix) with ESMTP id 4VJJF1311Pz4Tn1 for ; Mon, 15 Apr 2024 20:10:13 +0000 (UTC) (envelope-from lexi@le-fay.org) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=le-fay.org header.s=fuchsia header.b=i4ZjXE3U; dmarc=none; spf=softfail (mx1.freebsd.org: 81.187.47.195 is neither permitted nor denied by domain of lexi@le-fay.org) smtp.mailfrom=lexi@le-fay.org Received: from iris.eden.le-Fay.ORG (iris.eden.le-fay.org [IPv6:2001:8b0:aab5:106:3::6]) by fuchsia.eden.le-Fay.ORG (Postfix) with ESMTP id CA5688D45 for ; Mon, 15 Apr 2024 20:10:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=le-fay.org; s=fuchsia; t=1713211812; bh=5nnXilmAQRn5bk16Sc8hGMQ8BbUsGF/w0m86CqjENM8=; h=Date:From:To:Subject; b=i4ZjXE3U9rW4SNIW3mT/HuBsPjyD3CJhIshI27VaXLr2hOXVeYpp2k81x09qep9rf ZjNiQ4LTyopN1Xh/Xre0UIazzztFu/RDcmT45LTIqG5cPgnpcrftR6N5tU6QJ3TurD +F3juR0jGgAx8HPJd+ZL4J6uPjsIHtiT9mY8lzw0= Received: from ilythia.eden.le-fay.org (ilythia.eden.le-fay.org [IPv6:2001:8b0:aab5:106:3::10]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (secp384r1) server-digest SHA384) (No client certificate requested) by iris.eden.le-Fay.ORG (Postfix) with ESMTPSA id 48B9D2C0421 for ; Mon, 15 Apr 2024 21:10:12 +0100 (BST) Date: Mon, 15 Apr 2024 21:10:12 +0100 From: Lexi Winter To: arch@freebsd.org Subject: removing RIP/RIPng (routed/route6d) Message-ID: List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@FreeBSD.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="YwhyjZXuuh/1LhYW" Content-Disposition: inline X-Spamd-Bar: - X-Spamd-Result: default: False [-1.77 / 15.00]; VIOLATED_DIRECT_SPF(3.50)[]; SIGNED_PGP(-2.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.97)[-0.973]; R_DKIM_ALLOW(-0.20)[le-fay.org:s=fuchsia]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; RCVD_NO_TLS_LAST(0.10)[]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; DMARC_NA(0.00)[le-fay.org]; RCPT_COUNT_ONE(0.00)[1]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DKIM_TRACE(0.00)[le-fay.org:+]; FROM_HAS_DN(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; ASN(0.00)[asn:20712, ipnet:81.187.0.0/16, country:GB]; TO_DN_NONE(0.00)[]; R_SPF_SOFTFAIL(0.00)[~all:c]; FROM_EQ_ENVFROM(0.00)[]; MISSING_XM_UA(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[arch@freebsd.org]; MLMMJ_DEST(0.00)[arch@freebsd.org]; MID_RHS_MATCH_FROMTLD(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; DWL_DNSWL_NONE(0.00)[le-fay.org:dkim] X-Rspamd-Queue-Id: 4VJJF1311Pz4Tn1 --YwhyjZXuuh/1LhYW Content-Type: text/plain; charset=us-ascii Content-Disposition: inline hello, currently FreeBSD ships routed(8) and route6d(8) which implement the RIP resp. RIPng routing protocols. many years ago, it was fairly common for hosts to run these protocols to get their routing table and it made sense to ship an implementation with the operating systems. nowadays, these are fairly niche protocols and have been replaced in most networks by either static routing tables (mostly just a default route) or more modern routing protocols like IBGP/EBGP, OSPF or IS-IS. as such, i'm not convinced there's any value continuing to ship these with the OS. for people who do want to continue running RIP/RIPng, there are several implementations available in ports, such as net/bird2 and net/quagga. i'd like to submit a patch to remove both of these daemons from src. if there's some concern that people still want to use the BSD implementation of routed/route6d, i'm also willing to submit a port such as net/freebsd-routed containing the old code, in a similar way to how the removal of things like window(1) and telnetd(8) were handled. does anyone have an opinion on this? --YwhyjZXuuh/1LhYW Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGzBAABCAAdFiEEuwt6MaPcv/+Mo+ftDHqbqZ41x5kFAmYdiaEACgkQDHqbqZ41 x5ktqwv/USP8bMZ4LQSX3YygX0sDg94FQ3VcnIc3sC7zk0LekrUUMb7q5sRHepMk HviNjY0l5M8ApLeJ+3fEjoBm+OO6fE8xD3DSeVwtpe1ZfX2Q+utWl7nPPgnGE+vA LJa7qsa64J0Rj406XF5gDnbiEc4fcJnnYI02Zc5R8TVjnhMzjv5xk+uHv5IujCUW xA/8jy1BnHKe6k6M4rKIS619IY3yrPF+SGlr4nmvvTzh7Ae4Xjy1NNGsyqmIZ5Z+ 2SpuUNfWwugKRoC/V4XrnSTruvqsv2S3ZcURKyMnX/QSAjlxhJ8rM+xCovGQotHs 1+8WQ4acrwK1vpK7cGakMWTk0EvLrb5Ikua512dKb8xvhL+wHK5oNCA8uQPSDRy8 RI9LY2GuOtM8RI7/45EUh5f42VStClvBryNq8Jo/Czwuz2/mNBUpWEpwZ1YDXVKk QoKKw+19zEyp+qzWO6L/wPDwe36OUzJbGdHmJ6IqKX4QdORtEULOHFOnnQPN0X2r 1XK0ZBJg =qFZe -----END PGP SIGNATURE----- --YwhyjZXuuh/1LhYW-- From nobody Mon Apr 15 20:22:13 2024 X-Original-To: arch@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 4VJJVx410jz5H1mY for ; Mon, 15 Apr 2024 20:22:17 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from omta001.cacentral1.a.cloudfilter.net (omta001.cacentral1.a.cloudfilter.net [3.97.99.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4VJJVx18xHz4VgG for ; Mon, 15 Apr 2024 20:22:17 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Authentication-Results: mx1.freebsd.org; none Received: from shw-obgw-4002a.ext.cloudfilter.net ([10.228.9.250]) by cmsmtp with ESMTPS id wIWhrjnzo2Ui5wSqGrFX3c; Mon, 15 Apr 2024 20:22:16 +0000 Received: from spqr.komquats.com ([70.66.152.170]) by cmsmtp with ESMTPSA id wSqErjN2b9Cr4wSqFrCffm; Mon, 15 Apr 2024 20:22:16 +0000 X-Authority-Analysis: v=2.4 cv=etl8zZpX c=1 sm=1 tr=0 ts=661d8c78 a=y8EK/9tc/U6QY+pUhnbtgQ==:117 a=y8EK/9tc/U6QY+pUhnbtgQ==:17 a=kj9zAlcOel0A:10 a=raytVjVEu-sA:10 a=Rk-M77FJAAAA:8 a=YxBL1-UpAAAA:8 a=6I5d2MoRAAAA:8 a=EkcXrb_YAAAA:8 a=qKQGo5T3y57yA9P6tiwA:9 a=CjuIK1q_8ugA:10 a=ef1k35tKgZpiIrJ2aQ5N:22 a=Ia-lj3WSrqcvXOmTRaiG:22 a=IjZwj45LgO3ly-622nXo:22 a=LK5xJRSDVpKd5WXXoEvA:22 Received: from slippy.cwsent.com (slippy [10.1.1.91]) by spqr.komquats.com (Postfix) with ESMTP id 40029248B; Mon, 15 Apr 2024 13:22:14 -0700 (PDT) Received: by slippy.cwsent.com (Postfix, from userid 1000) id B9BDC6F; Mon, 15 Apr 2024 13:22:13 -0700 (PDT) X-Mailer: exmh version 2.9.0 11/07/2018 with nmh-1.8+dev Reply-to: Cy Schubert From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.cschubert.com/ To: Lexi Winter cc: arch@freebsd.org Subject: Re: removing RIP/RIPng (routed/route6d) In-reply-to: References: Comments: In-reply-to Lexi Winter message dated "Mon, 15 Apr 2024 21:10:12 +0100." List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@FreeBSD.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 15 Apr 2024 13:22:13 -0700 Message-Id: <20240415202213.B9BDC6F@slippy.cwsent.com> X-CMAE-Envelope: MS4xfJJP6z0LjrKNPSZVP/M5n+Z9HTtpZdGcCo0wtmDFAkQIAjRCxYJPO0yJW7RhYYwgXGdv1GJ9mU/07HnAMvy4YMNbctejsQ7rzAETzuvXxLTORrXb6OxX d1+Xqypt/bYe2j5ukKh/UMNuFAlaWmuzSsttBy5fry6zwqvTisv1SJo5F0DLmHQlK4RuL3h8eDnQ3Z9cEWzeP7i6YhYytpOeAvaS91pf/DIIQnDoe8Bb2LYd 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:16509, ipnet:3.96.0.0/15, country:US] X-Rspamd-Queue-Id: 4VJJVx18xHz4VgG In message , Lexi Winter writes: > > --YwhyjZXuuh/1LhYW > Content-Type: text/plain; charset=us-ascii > Content-Disposition: inline > > hello, > > currently FreeBSD ships routed(8) and route6d(8) which implement the RIP > resp. RIPng routing protocols. > > many years ago, it was fairly common for hosts to run these protocols to > get their routing table and it made sense to ship an implementation with > the operating systems. > > nowadays, these are fairly niche protocols and have been replaced in > most networks by either static routing tables (mostly just a default > route) or more modern routing protocols like IBGP/EBGP, OSPF or IS-IS. > as such, i'm not convinced there's any value continuing to ship these > with the OS. > > for people who do want to continue running RIP/RIPng, there are several > implementations available in ports, such as net/bird2 and net/quagga. > > i'd like to submit a patch to remove both of these daemons from src. if > there's some concern that people still want to use the BSD > implementation of routed/route6d, i'm also willing to submit a port such > as net/freebsd-routed containing the old code, in a similar way to how > the removal of things like window(1) and telnetd(8) were handled. > > does anyone have an opinion on this? If a port, the source repo must contain full history extracted from our src tree like I did with our telnetd and ftpd extracts. -- Cheers, Cy Schubert FreeBSD UNIX: Web: https://FreeBSD.org NTP: Web: https://nwtime.org e^(i*pi)+1=0 From nobody Mon Apr 15 20:24:17 2024 X-Original-To: arch@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 4VJJYG18dfz5H1m2 for ; Mon, 15 Apr 2024 20:24:18 +0000 (UTC) (envelope-from lexi@le-fay.org) Received: from fuchsia.eden.le-Fay.ORG (fuchsia.eden.le-fay.org [81.187.47.195]) by mx1.freebsd.org (Postfix) with ESMTP id 4VJJYG0Rzxz4WgT for ; Mon, 15 Apr 2024 20:24:18 +0000 (UTC) (envelope-from lexi@le-fay.org) Authentication-Results: mx1.freebsd.org; none Received: from iris.eden.le-Fay.ORG (iris.eden.le-fay.org [IPv6:2001:8b0:aab5:106:3::6]) by fuchsia.eden.le-Fay.ORG (Postfix) with ESMTP id 6E2DD8CE0; Mon, 15 Apr 2024 20:24:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=le-fay.org; s=fuchsia; t=1713212657; bh=J9Y6mKZ964SJdcMpVEZVZ/+0n3QcUOk5Hu3ZyfhR/AA=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=zPo7UiIktZ2sMTylQDhCeepi3nY2k/9/tg2fMzD+MbkxcR3R/oYbGDCJtjEXfhJB5 lI880q65mE39XRnYK8bj4mWkTtA8exonNXIdGr1gjlVLhmSmV+0H8yEoNPugtYlu01 f1UlMvBYDsgSVEgMtO/HJdUFsaFc0PHH6BkX2Rd4= Received: from ilythia.eden.le-fay.org (ilythia.eden.le-fay.org [IPv6:2001:8b0:aab5:106:3::10]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (secp384r1) server-digest SHA384) (No client certificate requested) by iris.eden.le-Fay.ORG (Postfix) with ESMTPSA id 5157E2C0422; Mon, 15 Apr 2024 21:24:17 +0100 (BST) Date: Mon, 15 Apr 2024 21:24:17 +0100 From: Lexi Winter To: Cy Schubert Cc: arch@freebsd.org Subject: Re: removing RIP/RIPng (routed/route6d) Message-ID: References: <20240415202213.B9BDC6F@slippy.cwsent.com> List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@FreeBSD.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="4V/4RNUhYOEMkuLx" Content-Disposition: inline In-Reply-To: <20240415202213.B9BDC6F@slippy.cwsent.com> 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:20712, ipnet:81.187.0.0/16, country:GB] X-Rspamd-Queue-Id: 4VJJYG0Rzxz4WgT --4V/4RNUhYOEMkuLx Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Cy Schubert: > > if there's some concern that people still want to use the BSD > > implementation of routed/route6d, i'm also willing to submit a port > > such as net/freebsd-routed containing the old code, in a similar way > > to how the removal of things like window(1) and telnetd(8) were > > handled. =20 > If a port, the source repo must contain full history extracted from our s= rc=20 > tree like I did with our telnetd and ftpd extracts. noted. can i ask how you did that for telnetd? --4V/4RNUhYOEMkuLx Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGzBAABCAAdFiEEuwt6MaPcv/+Mo+ftDHqbqZ41x5kFAmYdjO4ACgkQDHqbqZ41 x5ma+Qv9HC/z+YVI0OU7GVyAjkFwGGerF9LknLL0NJlMheP+Kmw3zAwaJY2iSOFO l/qEYqO1ekG6xHoPhWvK7kJfCucE9XIVpBQNvHHU9qF+3/TC/2ZcHOWWnfyxZE8I 66u3BOpXul0ZyHdbdCgBgsAtRvhfmva/M90pvAybnbdF/izQRKdfnHwgKQhlfLC1 T12VLEmT2yluzz3b1aWFRGbb1MQPTxXO1Zvj0HQ8tVEFqdTrj7zTAAJpKP0IsQhL 9zhb+1KEnE8Mh/93ZXY68qiAcOdNwcnUAN1oTYbHoF3u3Ysi2jA79qZYyynEIl8e S3zYA+fIIzPDf1SW9n0E8PNVDt73/xw1CZwIc15WfvcXKBUbu8TvQDSwNJv++ATe 5XguzZxupvs50lmMr79xmsfWr5R5TgvYsH5b8I4BC4hxtM8ZN0jtsmfvYV+Aiiab BEWjXev/ZaVc1mD2M3+LoXYofhm7ozXIa7aTIK3i70wqEliyZpRhHmo9ODiM7HSW IbhXPH5Y =1o12 -----END PGP SIGNATURE----- --4V/4RNUhYOEMkuLx-- From nobody Mon Apr 15 20:32:07 2024 X-Original-To: arch@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 4VJJkb4p5Gz5H2Lk for ; Mon, 15 Apr 2024 20:32:23 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ed1-x534.google.com (mail-ed1-x534.google.com [IPv6:2a00:1450:4864:20::534]) (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 4VJJkb2w27z4XQh for ; Mon, 15 Apr 2024 20:32:23 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ed1-x534.google.com with SMTP id 4fb4d7f45d1cf-56e6a1edecfso5761845a12.1 for ; Mon, 15 Apr 2024 13:32:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1713213139; x=1713817939; 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=s24UyUPTD+mQX22dtikiRIwTwD3kUs593XhiPZRSwm8=; b=i+0Ui11ErU0HXofQMjKOkoZJJ53PzOBs3AGCP6hggWhU37NID38g9sj/u8mdsJhbk1 4Kc81idi1qBwMWctmMe0i+c4BDueI7ir5Q/78I8SuJhDnCHBpBG00USoWwtk7HSrJuvE OhTabWhA56jZqneLk7c8Mv9sasXbU5MvfB39z51E5Ia5v0JgCQhTngR4NPNvKhLdH4ZJ 5I2mJfpfnY75IodzZpWje9d+XruQQIDBiv6sTz1bs6UtFZ89uuUyNUwGBpAFDZcEzFnl F2lqE1P92aS+VKrVDClP2nDHXganaKJrw5sFmZMFMJQ+3HcAe8Y0FnBfdbqfkDNAtauz GS3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1713213139; x=1713817939; 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=s24UyUPTD+mQX22dtikiRIwTwD3kUs593XhiPZRSwm8=; b=GUYggKkLPVQAnAP06c2jTHVm3GMcySxdYkFLg8fgYTDZDnvrEa2pu6iCOSopPIWn/P ubUde7ctIk0RZ2OAqW8YFwRZnm4WyPZsLyaKclgrZCXyKsbb7aaNYD/ctkVII06uy8Ad We/Lax16gUJzRBMYPn7BCWL7J9DKMpdov3f+LrM9yJ0ZuVEx2RnFHMYbSlo5J1bFci3W 34o4/1l4zNOARN4EsPya9FYnv7qIP0Ex129HrJSMFnyyFqoHb9iV10Al4Fj0w0mdArsy CgDnEptILa4EkxXothTCYhIKtNTEZYRm0dNJn2mLsUZFwDH7RwpyI96G/Pc2mgyQZP/h /MTw== X-Forwarded-Encrypted: i=1; AJvYcCVJmj9XStPkYZ+CUnMP0cPxflnLws3WcqRzB83g+DEbCZi/sV314DmpBNL6gS4/X2u3tA8QPDkhdwaoJ5xk3f25 X-Gm-Message-State: AOJu0YxoiE5SC/MSCYW2x1tJ3WFfKTuzOgqO6DiEi6dcX5Vq8KHG5QOc zGQDRowrwootukxHdG7xsz/SMJ2kkVFz0x5gOvCVu67TO3QrbrW/4vHZ3jj6Uf26Tfbjh+41LR8 xAcMYkdWAA28aConRjec/L3yWUWUMkeqAk5haRw== X-Google-Smtp-Source: AGHT+IFEIJLjz5qMhXziVu2URYA5rb4xSe+gotMP59lzOspVSpjmkuYAQXQEGeVIBLEqE3/XVBXlEcN6tybX3rWgeic= X-Received: by 2002:a17:906:c116:b0:a52:3f01:e11d with SMTP id do22-20020a170906c11600b00a523f01e11dmr8222357ejc.34.1713213139471; Mon, 15 Apr 2024 13:32:19 -0700 (PDT) List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@FreeBSD.org MIME-Version: 1.0 References: <20240415202213.B9BDC6F@slippy.cwsent.com> In-Reply-To: From: Warner Losh Date: Mon, 15 Apr 2024 14:32:07 -0600 Message-ID: Subject: Re: removing RIP/RIPng (routed/route6d) To: Lexi Winter Cc: Cy Schubert , arch@freebsd.org Content-Type: multipart/alternative; boundary="0000000000009a676206162884ed" 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] X-Rspamd-Queue-Id: 4VJJkb2w27z4XQh --0000000000009a676206162884ed Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Apr 15, 2024 at 2:24=E2=80=AFPM Lexi Winter wrote= : > Cy Schubert: > > > if there's some concern that people still want to use the BSD > > > implementation of routed/route6d, i'm also willing to submit a port > > > such as net/freebsd-routed containing the old code, in a similar way > > > to how the removal of things like window(1) and telnetd(8) were > > > handled. > > > If a port, the source repo must contain full history extracted from our > src > > tree like I did with our telnetd and ftpd extracts. > > noted. > > can i ask how you did that for telnetd? > git filter-branch is usually all you need. Warner --0000000000009a676206162884ed Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Apr 15, 2024 at 2:24=E2=80=AF= PM Lexi Winter <lexi@le-fay.org&g= t; wrote:
Cy Sch= ubert:
> > if there's some concern that people still want to use the BSD=
> > implementation of routed/route6d, i'm also willing to submit = a port
> > such as net/freebsd-routed containing the old code, in a similar = way
> > to how the removal of things like window(1) and telnetd(8) were > > handled.

> If a port, the source repo must contain full history extracted from ou= r src
> tree like I did with our telnetd and ftpd extracts.

noted.

can i ask how you did that for telnetd?

git filter-branch is usually all you need.

Warner= =C2=A0
--0000000000009a676206162884ed-- From nobody Mon Apr 15 20:37:32 2024 X-Original-To: arch@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 4VJJrd4vFbz5H31G for ; Mon, 15 Apr 2024 20:37:37 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from omta001.cacentral1.a.cloudfilter.net (omta001.cacentral1.a.cloudfilter.net [3.97.99.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4VJJrd41Lqz4Y6g for ; Mon, 15 Apr 2024 20:37:37 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Authentication-Results: mx1.freebsd.org; none Received: from shw-obgw-4002a.ext.cloudfilter.net ([10.228.9.250]) by cmsmtp with ESMTPS id wLN6rjuDV2Ui5wT56rFa6p; Mon, 15 Apr 2024 20:37:36 +0000 Received: from spqr.komquats.com ([70.66.152.170]) by cmsmtp with ESMTPSA id wT55rjRkP9Cr4wT56rChdR; Mon, 15 Apr 2024 20:37:36 +0000 X-Authority-Analysis: v=2.4 cv=etl8zZpX c=1 sm=1 tr=0 ts=661d9010 a=y8EK/9tc/U6QY+pUhnbtgQ==:117 a=y8EK/9tc/U6QY+pUhnbtgQ==:17 a=kj9zAlcOel0A:10 a=raytVjVEu-sA:10 a=Rk-M77FJAAAA:8 a=6I5d2MoRAAAA:8 a=YxBL1-UpAAAA:8 a=EkcXrb_YAAAA:8 a=DiX9dCntg7FcU8tGMkUA:9 a=CjuIK1q_8ugA:10 a=ef1k35tKgZpiIrJ2aQ5N:22 a=IjZwj45LgO3ly-622nXo:22 a=Ia-lj3WSrqcvXOmTRaiG:22 a=LK5xJRSDVpKd5WXXoEvA:22 Received: from slippy.cwsent.com (slippy [10.1.1.91]) by spqr.komquats.com (Postfix) with ESMTP id 60BED2517; Mon, 15 Apr 2024 13:37:34 -0700 (PDT) Received: by slippy.cwsent.com (Postfix, from userid 1000) id 6287411E; Mon, 15 Apr 2024 13:37:32 -0700 (PDT) X-Mailer: exmh version 2.9.0 11/07/2018 with nmh-1.8+dev Reply-to: Cy Schubert From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.cschubert.com/ To: Warner Losh cc: Lexi Winter , Cy Schubert , arch@freebsd.org Subject: Re: removing RIP/RIPng (routed/route6d) In-reply-to: References: <20240415202213.B9BDC6F@slippy.cwsent.com> Comments: In-reply-to Warner Losh message dated "Mon, 15 Apr 2024 14:32:07 -0600." List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@FreeBSD.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 15 Apr 2024 13:37:32 -0700 Message-Id: <20240415203732.6287411E@slippy.cwsent.com> X-CMAE-Envelope: MS4xfHwDyymYItdB+sb89//xWEcjpbp5Zl5qN6qKYRdvkInDsvcAxLn8cQb7bFarQWq9OynT2evAKLfnW74Z+CuHOxze3BQJWSsYRqhpTgc7BaRQqavvcQ4M fb/WGfW3nnKhAPvdxJWMNMszNzHzMCm8WiA0QsnQab97yCtjNcZi3AhsSJ67OIAIY/jm57DsVjz8e2sJRO8WZ+Nj2IHV4vKd8I6ORW9Yz4nYPKYzOxRXcmTw +KIIyHSLLSc/35dZf2KY8Q== 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:16509, ipnet:3.96.0.0/15, country:US] X-Rspamd-Queue-Id: 4VJJrd41Lqz4Y6g In message , Warner Losh writes: > --0000000000009a676206162884ed > Content-Type: text/plain; charset="UTF-8" > Content-Transfer-Encoding: quoted-printable > > On Mon, Apr 15, 2024 at 2:24=E2=80=AFPM Lexi Winter wrote= > : > > > Cy Schubert: > > > > if there's some concern that people still want to use the BSD > > > > implementation of routed/route6d, i'm also willing to submit a port > > > > such as net/freebsd-routed containing the old code, in a similar way > > > > to how the removal of things like window(1) and telnetd(8) were > > > > handled. > > > > > If a port, the source repo must contain full history extracted from our > > src > > > tree like I did with our telnetd and ftpd extracts. > > > > noted. > > > > can i ask how you did that for telnetd? > > > > git filter-branch is usually all you need. It also has some warts. The git-filter-branch documentation says to use git-filter-repo. I documented my telnetd and ftpd experiences at https://wiki.freebsd.org/git-filter. I used git-filter-repo with telnetd and git filter-branch for ftpd. One will give you better results than the other. You may need to try the other if you're unsatisfied with the results. -- Cheers, Cy Schubert FreeBSD UNIX: Web: https://FreeBSD.org NTP: Web: https://nwtime.org e^(i*pi)+1=0 From nobody Mon Apr 15 23:54:31 2024 X-Original-To: arch@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 4VJPCv2lbLz5HLvX for ; Mon, 15 Apr 2024 23:54:35 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from omta001.cacentral1.a.cloudfilter.net (omta001.cacentral1.a.cloudfilter.net [3.97.99.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4VJPCv0TCFz3wpm for ; Mon, 15 Apr 2024 23:54:35 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Authentication-Results: mx1.freebsd.org; none Received: from shw-obgw-4001a.ext.cloudfilter.net ([10.228.9.142]) by cmsmtp with ESMTPS id wP8erk8212Ui5wW9irGB2R; Mon, 15 Apr 2024 23:54:34 +0000 Received: from spqr.komquats.com ([70.66.152.170]) by cmsmtp with ESMTPSA id wW9grSCalpsbgwW9hreOha; Mon, 15 Apr 2024 23:54:34 +0000 X-Authority-Analysis: v=2.4 cv=Ff+Ux4+6 c=1 sm=1 tr=0 ts=661dbe3a a=y8EK/9tc/U6QY+pUhnbtgQ==:117 a=y8EK/9tc/U6QY+pUhnbtgQ==:17 a=kj9zAlcOel0A:10 a=raytVjVEu-sA:10 a=Rk-M77FJAAAA:8 a=NEAV23lmAAAA:8 a=YxBL1-UpAAAA:8 a=6I5d2MoRAAAA:8 a=EkcXrb_YAAAA:8 a=p4he0witWULeRhyr_0oA:9 a=CjuIK1q_8ugA:10 a=ef1k35tKgZpiIrJ2aQ5N:22 a=Ia-lj3WSrqcvXOmTRaiG:22 a=IjZwj45LgO3ly-622nXo:22 a=LK5xJRSDVpKd5WXXoEvA:22 Received: from slippy.cwsent.com (slippy [10.1.1.91]) by spqr.komquats.com (Postfix) with ESMTP id 3073ADF; Mon, 15 Apr 2024 16:54:32 -0700 (PDT) Received: by slippy.cwsent.com (Postfix, from userid 1000) id E1DB8111; Mon, 15 Apr 2024 16:54:31 -0700 (PDT) X-Mailer: exmh version 2.9.0 11/07/2018 with nmh-1.8+dev Reply-to: Cy Schubert From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.cschubert.com/ To: Lexi Winter cc: Cy Schubert , arch@freebsd.org Subject: Re: removing RIP/RIPng (routed/route6d) In-reply-to: References: <20240415202213.B9BDC6F@slippy.cwsent.com> Comments: In-reply-to Lexi Winter message dated "Mon, 15 Apr 2024 21:24:17 +0100." List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@FreeBSD.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 15 Apr 2024 16:54:31 -0700 Message-Id: <20240415235431.E1DB8111@slippy.cwsent.com> X-CMAE-Envelope: MS4xfGJBvzSDTDuRFON/6eZTfhs9cLS5hDvkBLeKLYqsDeoJClysF1Qn8+kgmAUg9uTR1XuNHzfFZz9HIQtV/8kW0v6qW7cBXD8jOf7jBXVz82k9ck8/hZEq h7cnijq9gc+r4MB2KvsI/6yO9PpInQD2d2VmJrycMQV4NUaOupzQRtpDIlpNpb6qY5b0YT0q99UGkPiVDVZ6pHupa4I0K5ySsxW1tzXz3v+6G5MtUgB6NX2I 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:16509, ipnet:3.96.0.0/15, country:US] X-Rspamd-Queue-Id: 4VJPCv0TCFz3wpm In message , Lexi Winter writes: > > > --4V/4RNUhYOEMkuLx > Content-Type: text/plain; charset=us-ascii > Content-Disposition: inline > Content-Transfer-Encoding: quoted-printable > > Cy Schubert: > > > if there's some concern that people still want to use the BSD > > > implementation of routed/route6d, i'm also willing to submit a port > > > such as net/freebsd-routed containing the old code, in a similar way > > > to how the removal of things like window(1) and telnetd(8) were > > > handled. > =20 > > If a port, the source repo must contain full history extracted from our s= > rc=20 > > tree like I did with our telnetd and ftpd extracts. > > noted. > > can i ask how you did that for telnetd? I've extracted sbin/routed and usr.sbin/route6d for you, at https://github.com/cschuber/freebsd-routed. Would you what that I create the ports? The repo contains both routed and route6d. The ports will need to build one or the other, or maybe one port to build and install both. I think two separate ports building off the same source is better. git-filter-repo took a matter of minutes to complete what git-filter-branch estimated would take approximately 27 days (or more) to complete. The wiki has been updated with an additional step. A git tag points to a non-existent ref, causing git-filter-repo to choke. Removing the tag allowed it to complete. The steps I used for this latest extract are also documented in the wiki page. -- Cheers, Cy Schubert FreeBSD UNIX: Web: https://FreeBSD.org NTP: Web: https://nwtime.org e^(i*pi)+1=0 From nobody Tue Apr 16 03:12:26 2024 X-Original-To: arch@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 4VJTcF4pLpz5Hdmv for ; Tue, 16 Apr 2024 03:12:29 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from omta001.cacentral1.a.cloudfilter.net (omta001.cacentral1.a.cloudfilter.net [3.97.99.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4VJTcF30Whz4QKc for ; Tue, 16 Apr 2024 03:12:29 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Authentication-Results: mx1.freebsd.org; none Received: from shw-obgw-4001a.ext.cloudfilter.net ([10.228.9.142]) by cmsmtp with ESMTPS id wP8erk8242Ui5wZFErGYw5; Tue, 16 Apr 2024 03:12:28 +0000 Received: from spqr.komquats.com ([70.66.152.170]) by cmsmtp with ESMTPSA id wZFCrT5ZapsbgwZFDrefCd; Tue, 16 Apr 2024 03:12:28 +0000 X-Authority-Analysis: v=2.4 cv=Ff+Ux4+6 c=1 sm=1 tr=0 ts=661dec9c a=y8EK/9tc/U6QY+pUhnbtgQ==:117 a=y8EK/9tc/U6QY+pUhnbtgQ==:17 a=kj9zAlcOel0A:10 a=raytVjVEu-sA:10 a=Rk-M77FJAAAA:8 a=YxBL1-UpAAAA:8 a=6I5d2MoRAAAA:8 a=EkcXrb_YAAAA:8 a=xPR4nRW3NWrAzx-OmTYA:9 a=CjuIK1q_8ugA:10 a=ef1k35tKgZpiIrJ2aQ5N:22 a=Ia-lj3WSrqcvXOmTRaiG:22 a=IjZwj45LgO3ly-622nXo:22 a=LK5xJRSDVpKd5WXXoEvA:22 Received: from slippy.cwsent.com (slippy [10.1.1.91]) by spqr.komquats.com (Postfix) with ESMTP id 7A6FD434; Mon, 15 Apr 2024 20:12:26 -0700 (PDT) Received: by slippy.cwsent.com (Postfix, from userid 1000) id 59C4420F; Mon, 15 Apr 2024 20:12:26 -0700 (PDT) X-Mailer: exmh version 2.9.0 11/07/2018 with nmh-1.8+dev Reply-to: Cy Schubert From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.cschubert.com/ To: Lexi Winter cc: Cy Schubert , arch@freebsd.org Subject: Re: removing RIP/RIPng (routed/route6d) In-reply-to: References: <20240415202213.B9BDC6F@slippy.cwsent.com> Comments: In-reply-to Lexi Winter message dated "Mon, 15 Apr 2024 21:24:17 +0100." List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@FreeBSD.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 15 Apr 2024 20:12:26 -0700 Message-Id: <20240416031226.59C4420F@slippy.cwsent.com> X-CMAE-Envelope: MS4xfDPA1NGvAXIwWDhCe6HBXLe88LZNvNU0qdG6j+6j1tjDru6ovZg4p5P3fbh9RZ9fYHMHB3ShO0ahk4REWS0nAbAJ+w/Q3ulfyf73wfq/GppUAaeHKNWG CI8TsYCTclx+hpJMuBKLJtAPeVDLIsyeuP2KLeYwp4MwkFzy9Zu+8M6SIwtP+yQGfBHSzEWnwfUtY+cf05WOI+8y9r2UVbWSlRmZn6hvn68lcMNtXV+q8dlp 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:16509, ipnet:3.96.0.0/15, country:US] X-Rspamd-Queue-Id: 4VJTcF30Whz4QKc In message , Lexi Winter writes: > > Cy Schubert: > > > if there's some concern that people still want to use the BSD > > > implementation of routed/route6d, i'm also willing to submit a port > > > such as net/freebsd-routed containing the old code, in a similar way > > > to how the removal of things like window(1) and telnetd(8) were > > > handled. > =20 > > If a port, the source repo must contain full history extracted from our s= > rc=20 > > tree like I did with our telnetd and ftpd extracts. > > noted. > > can i ask how you did that for telnetd? The ports have been added. -- Cheers, Cy Schubert FreeBSD UNIX: Web: https://FreeBSD.org NTP: Web: https://nwtime.org e^(i*pi)+1=0 From nobody Tue Apr 16 12:19:44 2024 X-Original-To: arch@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 4VJjlj47d7z5GlQC for ; Tue, 16 Apr 2024 12:19:45 +0000 (UTC) (envelope-from lexi@le-fay.org) Received: from fuchsia.eden.le-Fay.ORG (fuchsia.eden.le-fay.org [IPv6:2001:8b0:aab5:107::11]) by mx1.freebsd.org (Postfix) with ESMTP id 4VJjlj3NmGz3xwc for ; Tue, 16 Apr 2024 12:19:45 +0000 (UTC) (envelope-from lexi@le-fay.org) Authentication-Results: mx1.freebsd.org; none Received: from iris.eden.le-Fay.ORG (iris.eden.le-fay.org [IPv6:2001:8b0:aab5:106:3::6]) by fuchsia.eden.le-Fay.ORG (Postfix) with ESMTP id CC7038E28; Tue, 16 Apr 2024 12:19:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=le-fay.org; s=fuchsia; t=1713269984; bh=BgHO6JNefjrhY/aOXk2pf2JIP4IW/BGK5MKGqMU2HQU=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=K3EZpkB2lDVAqVU/Wynz7rxaqhtuHem9CCqbXUnOtZmK5yQK0Mr8cihDNhI0JRTtZ meh5b2ShpyaKFpVLoIfnLJIF5PW6sx01O378UgGhvyRxwkAFExj809jVeXQN90w0qw z8T1qOGsWp8MN2+XYK7xMahtFy2eg0W9jySAdiwI= Received: from ilythia.eden.le-fay.org (ilythia.eden.le-fay.org [IPv6:2001:8b0:aab5:106:3::10]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (secp384r1) server-digest SHA384) (No client certificate requested) by iris.eden.le-Fay.ORG (Postfix) with ESMTPSA id 326E22C0421; Tue, 16 Apr 2024 13:19:44 +0100 (BST) Date: Tue, 16 Apr 2024 13:19:44 +0100 From: Lexi Winter To: Cy Schubert Cc: arch@freebsd.org Subject: Re: removing RIP/RIPng (routed/route6d) Message-ID: References: <20240415202213.B9BDC6F@slippy.cwsent.com> <20240416031226.59C4420F@slippy.cwsent.com> List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@FreeBSD.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="FzCGTHNmNnYBuI5E" Content-Disposition: inline In-Reply-To: <20240416031226.59C4420F@slippy.cwsent.com> 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:20712, ipnet:2001:8b0::/32, country:GB] X-Rspamd-Queue-Id: 4VJjlj3NmGz3xwc --FzCGTHNmNnYBuI5E Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Cy Schubert: > The ports have been added. thanks Cy. i believe you may also need to add usr.sbin/rip6query, which is the IPv6 version of rtquery, as well as the rc.d scripts which i was intending to remove. the initial draft of my patch showing the files to be removed is at [0] but this hasn't been much tested (or reviewed) beyond building. https://github.com/llfw/freebsd-src/commit/c46f3f1387386448652af66fa3cfafa8311110e6 --FzCGTHNmNnYBuI5E Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGzBAABCAAdFiEEuwt6MaPcv/+Mo+ftDHqbqZ41x5kFAmYebN0ACgkQDHqbqZ41 x5lEhQv/SBTwfSIDyNwH4aYG9vhQ2d9/5iTRgAyprZvV1KeP7vGUNsSvGCgfivje B0unRbcX8wLxdfR2XBCbjrcolkoXzmcuYZwdJjaxfSutTugbdjgL/ZHfseJUotvC MBE4G0/WQX62SEdC2HP+foV2W3eBaqWNYnkpgsoM6ug09i+GHWGrZIbqUPZ55vxK 5n5fsjPf8oZZuj9h2oaDQIzFNi7vO34jVREIZ5qEc/sH/SJyeZl21ggbyAhZojYD WG3+MAFDS7wp8KR+p138yCV+uSmX9N5x5UjGR4zEcUyTJY3TAivMofiJGNQwo/ZF FB97z734pf3BhQ0oP3nvpAAo6M9bjoqzRcrNd1XQ6LJlcJgXhZPWiqYVLs7j78Nk AUE/3s1+SRz8GqyLmE28oySLYVqJxDy80m5okTpGTjyzYetstNr/54S8NgSMjWaC rAg0RUjQoHUhDgnnIRrwsiWzT+ST4baivvnlRLWK3+i0YNFyq412BxGr6Hb0ywDS dxTz/5F1 =83We -----END PGP SIGNATURE----- --FzCGTHNmNnYBuI5E-- From nobody Tue Apr 16 14:12:01 2024 X-Original-To: arch@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 4VJmFK6D8qz5GwNG for ; Tue, 16 Apr 2024 14:12:05 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from omta002.cacentral1.a.cloudfilter.net (omta002.cacentral1.a.cloudfilter.net [3.97.99.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4VJmFK4CLqz4DDW for ; Tue, 16 Apr 2024 14:12:05 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Authentication-Results: mx1.freebsd.org; none Received: from shw-obgw-4001a.ext.cloudfilter.net ([10.228.9.142]) by cmsmtp with ESMTPS id wfbmrtA1ddrxEwjXXrLjgE; Tue, 16 Apr 2024 14:12:03 +0000 Received: from spqr.komquats.com ([70.66.152.170]) by cmsmtp with ESMTPSA id wjXWrVXdwpsbgwjXXrfASP; Tue, 16 Apr 2024 14:12:03 +0000 X-Authority-Analysis: v=2.4 cv=Ff+Ux4+6 c=1 sm=1 tr=0 ts=661e8733 a=y8EK/9tc/U6QY+pUhnbtgQ==:117 a=y8EK/9tc/U6QY+pUhnbtgQ==:17 a=kj9zAlcOel0A:10 a=raytVjVEu-sA:10 a=Rk-M77FJAAAA:8 a=NEAV23lmAAAA:8 a=YxBL1-UpAAAA:8 a=6I5d2MoRAAAA:8 a=EkcXrb_YAAAA:8 a=3XAD31bATW-CUEcUAT4A:9 a=CjuIK1q_8ugA:10 a=ef1k35tKgZpiIrJ2aQ5N:22 a=Ia-lj3WSrqcvXOmTRaiG:22 a=IjZwj45LgO3ly-622nXo:22 a=LK5xJRSDVpKd5WXXoEvA:22 Received: from slippy.cwsent.com (slippy [10.1.1.91]) by spqr.komquats.com (Postfix) with ESMTP id 06588B4E; Tue, 16 Apr 2024 07:12:01 -0700 (PDT) Received: by slippy.cwsent.com (Postfix, from userid 1000) id B97D0327; Tue, 16 Apr 2024 07:12:01 -0700 (PDT) X-Mailer: exmh version 2.9.0 11/07/2018 with nmh-1.8+dev Reply-to: Cy Schubert From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.cschubert.com/ To: Lexi Winter cc: Cy Schubert , arch@freebsd.org Subject: Re: removing RIP/RIPng (routed/route6d) In-reply-to: References: <20240415202213.B9BDC6F@slippy.cwsent.com> <20240416031226.59C4420F@slippy.cwsent.com> Comments: In-reply-to Lexi Winter message dated "Tue, 16 Apr 2024 13:19:44 +0100." List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@FreeBSD.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 16 Apr 2024 07:12:01 -0700 Message-Id: <20240416141201.B97D0327@slippy.cwsent.com> X-CMAE-Envelope: MS4xfE0/aJMJoXg0Au2CDsyFKTXDH/CAODW84VZWdcFzC36MjwQBscxaYfwBaX/bXTmVS2ErkIeBARKnjEpARpsMVP6FA9vXOI1OQfcy2pxs+7Wm1mctzrS7 mxpKk/n/DBS+b1jMHgLiEfTVYnhL67gZ+5xwOeTu5ZQwpvgkgUkFCkycbT6iV9IBXXn0xfUYxqWXxQF028DZwmMbCxvvShJDRELMNkQpEAbmNky7AW0D2MB2 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:16509, ipnet:3.96.0.0/15, country:US] X-Rspamd-Queue-Id: 4VJmFK4CLqz4DDW In message , Lexi Winter writes: > > Cy Schubert: > > The ports have been added. > > thanks Cy. i believe you may also need to add usr.sbin/rip6query, which > is the IPv6 version of rtquery, as well as the rc.d scripts which i was > intending to remove. > > the initial draft of my patch showing the files to be removed is at [0] > but this hasn't been much tested (or reviewed) beyond building. > > https://github.com/llfw/freebsd-src/commit/c46f3f1387386448652af66fa3cfafa831 > 1110e6 The repo has been regenned. I'll catch up with the new tagnames and distfile hashes, and the rip6query port later this morning. -- Cheers, Cy Schubert FreeBSD UNIX: Web: https://FreeBSD.org NTP: Web: https://nwtime.org e^(i*pi)+1=0 From nobody Tue Apr 16 18:10:49 2024 X-Original-To: arch@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 4VJsXr74bhz5HHNj for ; Tue, 16 Apr 2024 18:10:52 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from omta002.cacentral1.a.cloudfilter.net (omta002.cacentral1.a.cloudfilter.net [3.97.99.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4VJsXr590Hz4hRX for ; Tue, 16 Apr 2024 18:10:52 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Authentication-Results: mx1.freebsd.org; none Received: from shw-obgw-4004a.ext.cloudfilter.net ([10.228.9.227]) by cmsmtp with ESMTPS id wihtrtG8rdrxEwnGerMgjy; Tue, 16 Apr 2024 18:10:52 +0000 Received: from spqr.komquats.com ([70.66.152.170]) by cmsmtp with ESMTPSA id wnGcrEtniWhyfwnGdrOpPT; Tue, 16 Apr 2024 18:10:51 +0000 X-Authority-Analysis: v=2.4 cv=MenPuI/f c=1 sm=1 tr=0 ts=661ebf2b a=y8EK/9tc/U6QY+pUhnbtgQ==:117 a=y8EK/9tc/U6QY+pUhnbtgQ==:17 a=kj9zAlcOel0A:10 a=raytVjVEu-sA:10 a=Rk-M77FJAAAA:8 a=NEAV23lmAAAA:8 a=YxBL1-UpAAAA:8 a=6I5d2MoRAAAA:8 a=EkcXrb_YAAAA:8 a=PFwmRLSQWuzHIWiy7BQA:9 a=CjuIK1q_8ugA:10 a=ef1k35tKgZpiIrJ2aQ5N:22 a=Ia-lj3WSrqcvXOmTRaiG:22 a=IjZwj45LgO3ly-622nXo:22 a=LK5xJRSDVpKd5WXXoEvA:22 Received: from slippy.cwsent.com (slippy [10.1.1.91]) by spqr.komquats.com (Postfix) with ESMTP id CBBDC22D; Tue, 16 Apr 2024 11:10:49 -0700 (PDT) Received: by slippy.cwsent.com (Postfix, from userid 1000) id 9592D1A2; Tue, 16 Apr 2024 11:10:49 -0700 (PDT) X-Mailer: exmh version 2.9.0 11/07/2018 with nmh-1.8+dev Reply-to: Cy Schubert From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.cschubert.com/ To: Lexi Winter cc: Cy Schubert , arch@freebsd.org Subject: Re: removing RIP/RIPng (routed/route6d) In-reply-to: References: <20240415202213.B9BDC6F@slippy.cwsent.com> <20240416031226.59C4420F@slippy.cwsent.com> Comments: In-reply-to Lexi Winter message dated "Tue, 16 Apr 2024 13:19:44 +0100." List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@FreeBSD.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 16 Apr 2024 11:10:49 -0700 Message-Id: <20240416181049.9592D1A2@slippy.cwsent.com> X-CMAE-Envelope: MS4xfP8Tft/ybTvzVL3lYM15xZnFVY4pKqbAKNW92APoojCmwvBR4Srf9CBPMAVmSKfk3TB+zMSLMlyhoDrCRwDW1D6/97kMR8qJTMAprfKKSOs7uaBlbuKi jJMDfFDI5REzPBhfZg2iDthhvcf1JJEcktWEpsVS8HUl8lgojVCdTS+Jf/znU2kLPTjetLXaGWTIt3gCPpdzyzI3IGrG2au1FW1wT4TrGGm4xdKWsuwXyYt9 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:16509, ipnet:3.96.0.0/15, country:US] X-Rspamd-Queue-Id: 4VJsXr590Hz4hRX In message , Lexi Winter writes: > > Cy Schubert: > > The ports have been added. > > thanks Cy. i believe you may also need to add usr.sbin/rip6query, which > is the IPv6 version of rtquery, as well as the rc.d scripts which i was > intending to remove. > > the initial draft of my patch showing the files to be removed is at [0] > but this hasn't been much tested (or reviewed) beyond building. > > https://github.com/llfw/freebsd-src/commit/c46f3f1387386448652af66fa3cfafa831 > 1110e6 Removing routed from the ifconfig and ping man pages may be a mistake. Maybe we should replace the wording to say something about some daemon that may alter the routing table, such as routed or other example. Removing references to some daemon altering the routing table may cause confusion as routing tables are changed unbeknownst a sysadmin trying to grok a situation that is impacting routing. We can discuss this in the phabricatior review. Just putting it out here as a heads up. -- Cheers, Cy Schubert FreeBSD UNIX: Web: https://FreeBSD.org NTP: Web: https://nwtime.org e^(i*pi)+1=0 From nobody Tue Apr 16 21:00:31 2024 X-Original-To: arch@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 4VJxJm3d9cz5H4Zk for ; Tue, 16 Apr 2024 21:00:40 +0000 (UTC) (envelope-from lexi@le-fay.org) Received: from fuchsia.eden.le-Fay.ORG (fuchsia.eden.le-fay.org [81.187.47.195]) by mx1.freebsd.org (Postfix) with ESMTP id 4VJxJl0xPlz4PY1 for ; Tue, 16 Apr 2024 21:00:39 +0000 (UTC) (envelope-from lexi@le-fay.org) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=le-fay.org header.s=fuchsia header.b=E3BoQaqJ; dmarc=none; spf=pass (mx1.freebsd.org: domain of lexi@le-fay.org designates 81.187.47.195 as permitted sender) smtp.mailfrom=lexi@le-fay.org Received: from iris.eden.le-Fay.ORG (iris.eden.le-fay.org [IPv6:2001:8b0:aab5:106:3::6]) by fuchsia.eden.le-Fay.ORG (Postfix) with ESMTP id 861ED8EB8 for ; Tue, 16 Apr 2024 21:00:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=le-fay.org; s=fuchsia; t=1713301232; bh=WUbYBnFNQGb/3GoQLjXahf4yYECmPeALqu/8q3kbEJs=; h=Date:From:To:Subject; b=E3BoQaqJUdmSptExPOsjkOTEEXvc6z9DDFrCkUbkKYomdWZIWhpvmGuwqmwWJyNHv tvryUHE8XpN0XTjRVgkh8cLXIMEQJ5Z2HIIg7iUC7PknwdQiWAsCcUSXuZ6NS4NQNW isjyBAy3W4ktVCfGBLgonsIGih5MgCyyRKllT290= Received: from ilythia.eden.le-fay.org (ilythia.eden.le-fay.org [IPv6:2001:8b0:aab5:106:3::10]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (secp384r1) server-digest SHA384) (No client certificate requested) by iris.eden.le-Fay.ORG (Postfix) with ESMTPSA id 0240D2C0421 for ; Tue, 16 Apr 2024 22:00:32 +0100 (BST) Date: Tue, 16 Apr 2024 22:00:31 +0100 From: Lexi Winter To: arch@freebsd.org Subject: enable INVARIANT_SUPPORT in GENERIC in release builds Message-ID: List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@FreeBSD.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="mDX6N1oNLAuF4Sxz" Content-Disposition: inline X-Spamd-Bar: ----- X-Spamd-Result: default: False [-5.50 / 15.00]; SIGNED_PGP(-2.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.996]; R_DKIM_ALLOW(-0.20)[le-fay.org:s=fuchsia]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; R_SPF_ALLOW(-0.20)[+ip4:81.187.47.195]; RCVD_NO_TLS_LAST(0.10)[]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; ASN(0.00)[asn:20712, ipnet:81.187.0.0/16, country:GB]; MISSING_XM_UA(0.00)[]; FROM_HAS_DN(0.00)[]; DWL_DNSWL_NONE(0.00)[le-fay.org:dkim]; TO_DN_NONE(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; DMARC_NA(0.00)[le-fay.org]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MID_RHS_MATCH_FROMTLD(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[arch@freebsd.org]; MLMMJ_DEST(0.00)[arch@freebsd.org]; DKIM_TRACE(0.00)[le-fay.org:+] X-Rspamd-Queue-Id: 4VJxJl0xPlz4PY1 --mDX6N1oNLAuF4Sxz Content-Type: text/plain; charset=us-ascii Content-Disposition: inline hello, currently release version of GENERIC (or GENERIC-NODEBUG in main) does not have INVARIANT_SUPPORT enabled. unfortunately, the presence or absense of this option breaks the KABI because, as i understand it, modules built with INVARIANTS won't load on a kernel without INVARIANT_SUPPORT. is there a reason INVARIANT_SUPPORT can't just be enabled by default? this would remove one roadblock to separating kernel modules from the kernel config in both pkgbase and ports, because there would be no need to build a KABI-incompatible kernel just to build a single module with INVARIANTS. --mDX6N1oNLAuF4Sxz Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGzBAABCAAdFiEEuwt6MaPcv/+Mo+ftDHqbqZ41x5kFAmYe5u0ACgkQDHqbqZ41 x5ni1wwAjGacl71/dMw2s6WECcF7YjLcxfFd1Y4oea5Y7E47t4rJ0c5LSq4Z0O55 KJnYtDW7CplVZQuIqdNnaLaeIcM0d9hQ3lVq+lFi3efJdj5g+dgwvTIOp7ug/iE2 6KegBEWKk3ViiZMuQ1Qlvx9iLJRxKWRXn8IeB/PLIykcojtP7SZj3ukG8KFs1bR3 hfc2Wn1vLY2x+UOYTcNPXF9BtevV07KRWBM+LmuXQZMKgUW4WZLnmHEnpE8LvgTs lomkUrVTbB6YuIwXP3s8qUTWa3cyMvK7cS53UCMN8A76vKUUbtpV6Nv3N0zZ3EQ9 /UedNaxVCxD++KR7sKZjTwyCrqBAmLFe7N3nLlV+wH1t+O7j6ohMz4WTok8Ry/VH O87J8Mg46Gidb8W/kqy7m2UnFtBAZ1de0MKF5E5bWtYqdNJ+1wbC9qhal8whOCaX 8rfeVL8PgP/HIwWKLQSIXJGzL1mFHD5gBoUX2WyCWrztX2Xf+LcxC60qT4XaLFS/ d99je5Vg =Ypb2 -----END PGP SIGNATURE----- --mDX6N1oNLAuF4Sxz-- From nobody Tue Apr 16 23:05:54 2024 X-Original-To: freebsd-arch@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 4VK05R4q9bz5HHPq for ; Tue, 16 Apr 2024 23:06:03 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-oi1-x233.google.com (mail-oi1-x233.google.com [IPv6:2607:f8b0:4864:20::233]) (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 4VK05Q5LqZz4sCD for ; Tue, 16 Apr 2024 23:06:02 +0000 (UTC) (envelope-from markjdb@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b="F+/xbvDd"; dmarc=fail reason="SPF not aligned (relaxed), DKIM not aligned (relaxed)" header.from=freebsd.org (policy=none); spf=pass (mx1.freebsd.org: domain of markjdb@gmail.com designates 2607:f8b0:4864:20::233 as permitted sender) smtp.mailfrom=markjdb@gmail.com Received: by mail-oi1-x233.google.com with SMTP id 5614622812f47-3c38eced701so2186170b6e.1 for ; Tue, 16 Apr 2024 16:06:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1713308757; x=1713913557; darn=freebsd.org; h=content-disposition:mime-version:message-id:subject:to:from:date :sender:from:to:cc:subject:date:message-id:reply-to; bh=3v/Jelplrp68G5jtPSVwGJsc+LLTSSnnUIqe0wZPAG4=; b=F+/xbvDdANOzccIkODd9XAqOhu/Dw8IrxtJlVl7cI9aIbGEUTIysD6oszdzGjMEixm vzWuQmaMyHafezHnbMuw44uur4sWTQoxyY68j+asjf6PQcxeLj37TKUtfbYSRgD4ra1H dmh8mmY2dnBm4e8bi+8GSqRP/4fEpBUuxuioqj+RoqSD5W7FMN75CFJsKlBktKZY5MHv tHcxLzQx1P5i8T96xLd1iaFgNPli5eLr9Qqbmc2n80zZ5oGQDsATK2hZ6/Gj/nveb1x1 vpYpUpvPU1s0nbMYpH/QrnIb7rSM8hLGQ7o6wfQOfoWJ9QNVlsBV96fg3pDQ4R8z79GO EAhw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1713308757; x=1713913557; h=content-disposition:mime-version:message-id:subject:to:from:date :sender:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=3v/Jelplrp68G5jtPSVwGJsc+LLTSSnnUIqe0wZPAG4=; b=vYDyAoJvfwqwqyxYPF5KUVCuYWroMdZ955aZThVOLaxLUccIclw/YNk24HBbxjVZx+ IDMxP0nbWaAwsxSuSbuAglW6ktF+gVXWUd3r48kLfykVy26D402wxouxV4J0z3OFW/F9 2iAFAKwaGt+Wt9kHQ/zQ526TkOgpPv3hYWbhPurJDME5rBY4kZIxjgDt2N4fRcNaIGQA 9LPBniWF1KxOOIXawUdRyQ2rsD6PO8nJNFM/XXZDYWeuhSWgPvDjbtQpMzbMhC3g61y2 F7+nKJaRTLhoHdh98pqIFPsMSLAwovNxkSQK62k7kHmoDes7A5TLeTRaty/PMTA6iYEi rptA== X-Gm-Message-State: AOJu0YxHFhGXp5ZdTh1Fl++MSOlpGlnmP7I/R6vmrrhZEGpbjXFIVyv5 YPjxHsYWwOSQV20d9DR+YDMopt98WQODJ309sYQW2y40mexmrpk1tFW0uw== X-Google-Smtp-Source: AGHT+IEIPe319d/llZ/IYn6YTgV5t/8rjqNjOMucqApRiHfrlicl1ihWQbIvVE20M4+DfPwTVOTTqw== X-Received: by 2002:a05:6808:219e:b0:3c5:ddc3:5fae with SMTP id be30-20020a056808219e00b003c5ddc35faemr17278878oib.6.1713308757517; Tue, 16 Apr 2024 16:05:57 -0700 (PDT) Received: from nuc (192-0-220-237.cpe.teksavvy.com. [192.0.220.237]) by smtp.gmail.com with ESMTPSA id g5-20020ac84685000000b0043496744c5dsm7607394qto.52.2024.04.16.16.05.56 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 16 Apr 2024 16:05:56 -0700 (PDT) Date: Tue, 16 Apr 2024 19:05:54 -0400 From: Mark Johnston To: freebsd-arch@freebsd.org Subject: requiring reserved NFS client ports by default Message-ID: List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.60 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MID_RHS_NOT_FQDN(0.50)[]; FORGED_SENDER(0.30)[markj@freebsd.org,markjdb@gmail.com]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20230601]; DMARC_POLICY_SOFTFAIL(0.10)[freebsd.org : SPF not aligned (relaxed), DKIM not aligned (relaxed),none]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; ARC_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; MIME_TRACE(0.00)[0:+]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MISSING_XM_UA(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; TO_DN_NONE(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_NEQ_ENVFROM(0.00)[markj@freebsd.org,markjdb@gmail.com]; DKIM_TRACE(0.00)[gmail.com:+]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arch@freebsd.org]; TO_DOM_EQ_FROM_DOM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-arch@freebsd.org]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::233:from] X-Rspamd-Queue-Id: 4VK05Q5LqZz4sCD It's common practice for NFS clients to bind to reserved ports (i.e., <= 1023) since some NFS servers require this as a weak security measure against attackers with network access to a server but without local privileges. FreeBSD's NFS server does not require clients to use privileged ports by default, but this can be changed by setting nfs_reserved_port_only=YES in rc.conf. I would like to propose flipping the default for nfs_reserved_port_only. This raises the bar a bit for a malicious agent able to execute unprivileged code on a machine with network access to an unauthenticated NFS server running FreeBSD. This behaviour would match the defaults on Linux (the per-export "secure" attribute) and OpenBSD. The downside is increased pressure on the limited range of reserved port numbers. However, the server will complain on the console if a request arrives on an unreserved port, so diagnosis should be easy, and most clients sport an option to not use a reserved port number (noresvport on FreeBSD), so one can configure client mounts to use them only where needed. And, the option is easy to disable on the server should that be necessary. My aim here is to provide a safer out-of-the-box behaviour. Any comments, objections, feedback? From nobody Wed Apr 17 02:35:21 2024 X-Original-To: arch@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 4VK4kz0pYQz5Hcgh for ; Wed, 17 Apr 2024 02:35:23 +0000 (UTC) (envelope-from 0100018ee9e8a381-2e0a8845-5321-4841-bfaf-184376e88112-000000@amazonses.com) Received: from a8-13.smtp-out.amazonses.com (a8-13.smtp-out.amazonses.com [54.240.8.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4VK4ky4sXmz4KD4 for ; Wed, 17 Apr 2024 02:35:22 +0000 (UTC) (envelope-from 0100018ee9e8a381-2e0a8845-5321-4841-bfaf-184376e88112-000000@amazonses.com) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=dqtolf56kk3wpt62c3jnwboqvr7iedax; d=tarsnap.com; t=1713321321; h=Message-ID:Date:MIME-Version:Subject:To:References:From:In-Reply-To:Content-Type:Content-Transfer-Encoding; bh=/Kcnmcw8KQzn1l/WEBjiUOGm9iR2gtUnnsiyle2UY9g=; b=WVqkH3CivJY0tTN6yWfyEAT7Adcy/VaLqZYfiK5DsBw5TiKELI5rwOWmiVQo6igb WlZC9B82ga3ecgme6K/RU7C9VCKdk/GTb+HJ/F8aCMh+rNw2qzJATzSy64v9H4u5jI5 QPawantrv2+/+YavQNf/agm+vEfDI3y1/NgW7g7s= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug; d=amazonses.com; t=1713321321; h=Message-ID:Date:MIME-Version:Subject:To:References:From:In-Reply-To:Content-Type:Content-Transfer-Encoding:Feedback-ID; bh=/Kcnmcw8KQzn1l/WEBjiUOGm9iR2gtUnnsiyle2UY9g=; b=tN76iiKDIkRiTFUI6WI22KnTJ52wNdJggAMv0yEYkfyamwV9xsXjRmbrlw1emtRi kMdgTXpCMnomctqqN9c9tNAYoavmEqpZ2ZocBhdF+m3QoNI5YYzmdaviVEQ80m+G+3J y4fFmf7Y/TbpCRGMbDgiNDNvuBpsNdYtBrPxEqFM= Message-ID: <0100018ee9e8a381-2e0a8845-5321-4841-bfaf-184376e88112-000000@email.amazonses.com> Date: Wed, 17 Apr 2024 02:35:21 +0000 List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@FreeBSD.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: enable INVARIANT_SUPPORT in GENERIC in release builds To: Lexi Winter , arch@freebsd.org References: Content-Language: en-US From: Colin Percival Autocrypt: addr=cperciva@tarsnap.com; keydata= xsFNBGWMSrYBEACdWRqDn3B3SKO7IG0/fGHYtfs26f3Q5QeAcasy1fQLniwGQWn5rlILhbCD K/jdNoDm5Zxq20eqyffoDNObCjnHgg4tGANdi+RmDy+7CDpE789H8dss9y7Pt5DlGGAXQQnt hxush3EYS/Ctprd9UUL/lzOOLOU1aNtzB84tNrJBtcJmL7OYHfyTSNFxvedqJrrasejIQOLI t/DQ89BPzz+vsKHz7FJPXh3fsVkzLA00DJYcfkgxyABfJNA7U6yMwd4DVSdx/SsvfIDMVXnu UXCXswo106WPZbYGlZPpq0wW6iibtTerJix+8AeuwXvl9O1p8yESK4ErkIxCnmghTSz+pdzj z/6xBRkdDM9VdZ0r+CzsaNXMpDOzFuKyjaiYBdgCLljbDnXIHFcqXenrZ7Xwkm09g/M4uVSh pIUG2RYa6tsHSQoGCp3f2RZv1znfViKQFbbL83QjtPA20AhseZSYbHp1FPhXyy9J0wkGL16L e99g6gdGeIRE82BZjBjKGDkoyDPq+oDRSFl8NtzmIKy+cfz00nViqcTF4bREXEawFGhlpO0X O9q8mijI9iFB6zaPBiSdJGBL5ML5qLTNCl8Zlf4m1TBvmRTqF/lzMHVXHidDoUhpSh/y3AFZ 1KrYc27ztJQywDJPJPWPbtY8YhFLFs377gfP8WldsZjzp8nvoQARAQABzSVDb2xpbiBQZXJj aXZhbCA8Y3BlcmNpdmFAdGFyc25hcC5jb20+wsGRBBMBCAA7FiEEglY7hNBiDtwN+4ZBOJfy 4i5lrT8FAmWMSyYCGwMICwkNCAwHCwMFFQoJCAsFFgMCAQACHgUCF4AACgkQOJfy4i5lrT+i Yg/+PYyJNoFuygtV5t/skcjYmvEC93mnazEvh+x99vGYZnGKeJ8NDOF4QCUzeHquOWxDi8Zl reXyswKcrIquPxxX6+YyGe97VbvLnez3ksfzOYRj1F4qV0Rq8ZNK51+bvIrbcS3SfDaRioAk D7WWwFor8y/hSwxYkfsKbtP5PRcem20JUxuC085zqWLaKv5t5n2CBzAGMjwJaQ3tM3AXVwWJ uJaHA6ot/6fntJlmkfcyCYyyr0D6b0guRj3STbZ2hNn5o2AI+f6LJJ31s2sPFjl6rs7fORf3 hFSNOHDd2HxfVBXFdQy24ROkC4orBBz2xh9GScjxxT/hbXkfufkubFubw7n0HkvHzA3UF+Qq A8JiI3n+d7ocsP0/5BQ2sZdeqPGJgHx6RkAMuW1tJ29wSvCN1qMgFwhYkpQdfvHlociQrimU fvlRfSrBEe8o7tvIuEdpvwvCZSTJqQbVoMw8UHFE7nzyCXUSab5h6PbjakCqim13ekVO2KFF TTPcz5o5jEeUY75tzbIwcDfFbT5KqNjWy06TVdM9VEJDHSfOfxHR3kSEwZ+tT2aTvL3grsUn gFwSNcj4Cl4CRFfUw8zVZY+7O7RiMlhBqykikvUurrdGKc1Scwa0yuppdA6eVvylyTWSQGrQ +uLWtV1LUKN7ZqKJWBkLPt9nS4XZWGyBvxOHYqjOwU0EZYxKtgEQANYfgbtUMVnhjxDHhWLp g5kLHK3YW0TfJKzpXqDB7NiqxHofn4OcbZnVC3MKggcbs9o1/UtsjnlsG8550PfiYkDXvPiO RJwgbGs6MGIDK797C6cnBLQ8xwBa9SL4cl5iQFnhWmt6vwnJ+an/cm5JpYves3wL7jV09qU9 57hkHXEUcl38r4FssZzVcLKPUVTa3Un+QGRTGDGe/f4ctjMaqv0ZCM+l2ixPhf/vqESrfSLv V/+T3dmtUfXjazO3SABvsHwxgGuTTYOlKoPCaebr+BRdqm0xeIShoIlhvTI8y4clchqx/Uxg UG5X2kvU13k3DS3Q8uLE4Et9x1CcZT6WGgBZSR6R0WfD0SDnzufNnRWJ0dEPA2MtJHE7+85R Vi9j/IgZV+y5Ur+bnPkjDG1s2SVciX5v9HQ0oilcBhvx0j5lGE9hhurD9F+fCvkr4KdbCknE 6Y8ce8pCNBUoB/DqibJivOzTk9K9MGB5x0De5TerIrFiaw3/mQC9nGeO9dtE7wvDJetWeoTq 4BEaCzpufNqbkpOaTQILr4V6Gp7M6v97g83TVAwZntz/q8ptwuKQPZ2JaSFLZn7oWUpYXA5s +SIODFHLn6iMoYpBQskHQjnj4lEPJadl4qj+ZKA89iDAKsniyoFXsbJe2CPbMS1yzBxKZq6K D/jpt7BOnuHr/JrXABEBAAHCwXYEGAEIACAWIQSCVjuE0GIO3A37hkE4l/LiLmWtPwUCZYxK tgIbDAAKCRA4l/LiLmWtP3jmEACQrh9gWe8F1Tkw3m6VoHKwLc5he4tX3WpQa//soPO6iGG3 S3WPruQ46NrAaAojoOcKI9UONDO5rxG0ZTX53S+lu2EO47jbcLwOCjaEpjKpDRt9ZXBQE8Xl mtBE9Bp3W9gpjB1nE3KNM1mJYgsK0QdRpwwfh4pVgGpOj8j23I6MCK+v99zEBnpgCn2GX8W/ kctRXHqWwndHysOJtRP/zrl7dDaABF1f9efUl0LL3TD3GJ9VDz+DNOin/uK2a1hiJo8QzTRk PpfUQ2ebzDsrd1i/pOWkMSkdH+rEu4AGrXWtaBwrMyrGkL6Icb6yO+P9/z0W2wlgBf3P1YRt JPgQt/Dj3yvA/UnaV/QmuVQPjl13o24UnJGsZM8XGnNdfWBKkC1Q6VXC4QT+dyBHYH9MuE9d 6oGl8pFM1+cTfEfbM62/rRoPkF1yHMsI/903VxEvuUIKfhEZAVLFyHldooNxuchntHQP9y8J 8Ou9bWYQP7MnEn+kwSwrZkjurfPkan+xQvp6dDYnj3V0GwA5pprBMaB928VIDVOv+1PNQI3t Cvk5VPv/skq+TJRMHW7bFSt8PRa91cUf1FOLIz9APDiJOzXkwxUEHGV3zPSaUhs1JYjyBeGT wDAvtLUdjOnRhEUOwlnIrztmvyciutjJoVzKEEjj5WXnHk9L9kQ1bpAjkjTONw== In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Feedback-ID: 1.us-east-1.Lv9FVjaNvvR5llaqfLoOVbo2VxOELl7cjN0AOyXnPlk=:AmazonSES X-SES-Outgoing: 2024.04.17-54.240.8.13 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:14618, ipnet:54.240.8.0/21, country:US] X-Rspamd-Queue-Id: 4VK4ky4sXmz4KD4 On 4/16/24 14:00, Lexi Winter wrote: > currently release version of GENERIC (or GENERIC-NODEBUG in main) does > not have INVARIANT_SUPPORT enabled. > > unfortunately, the presence or absense of this option breaks the KABI > because, as i understand it, modules built with INVARIANTS won't load on > a kernel without INVARIANT_SUPPORT. > > is there a reason INVARIANT_SUPPORT can't just be enabled by default? I think while it had much lower overhead than INVARIANTS, there was still a significant overhead cost at least in the early days. Maybe that's no longer the case. > this would remove one roadblock to separating kernel modules from the > kernel config in both pkgbase and ports, because there would be no need > to build a KABI-incompatible kernel just to build a single module with > INVARIANTS. If the overhead cost of INVARIANT_SUPPORT is no longer relevant, I'd be fine with including it in stable/15. Of course we can't turn it on for stable/1[34] for the ABI reasons you just mentioned. -- Colin Percival FreeBSD Release Engineering Lead & EC2 platform maintainer Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid From nobody Wed Apr 17 03:16:35 2024 X-Original-To: freebsd-arch@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 4VK5ff5SXHz5Hgf0 for ; Wed, 17 Apr 2024 03:16:42 +0000 (UTC) (envelope-from mike@karels.net) Received: from mail2.karels.net (mail2.karels.net [3.19.118.201]) (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 "freebsd", Issuer "freebsd" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4VK5ff3jSlz4NSb; Wed, 17 Apr 2024 03:16:42 +0000 (UTC) (envelope-from mike@karels.net) Authentication-Results: mx1.freebsd.org; none Received: from mail2.karels.net (localhost [IPv6:0:0:0:0:0:0:0:1]) by mail2.karels.net (8.18.1/8.18.1) with ESMTP id 43H3GFMH021763; Tue, 16 Apr 2024 22:16:35 -0500 (CDT) (envelope-from mike@karels.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=karels.net; s=mail2; t=1713323795; bh=s//gGDrPMB4+QtuFpB5iRU/MIWwkvm+sjVx6vHJL/Z8=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=b5o0OppcW/+8H4ve0QArCMraQ4OEa7+Nwv2AsV124jYeg5vdByUV+sQr+DvaPKlkm PnZYdWtxfwFtzpV2c4OuiZfRGFZ94ho/0ZfijaKoKEuFFRwhlo6inUsiN/DGu0fTYZ QRIed0oV8HKwnjCIGQ3+xIZwXFRDZtfZyCbpFd1saXJpa8o+pdyKq30jIh1cENLQqz 14QW1MzxLoso1DUDlTkVAKMiGApZQmCMxk4Y0/3ERKNr0fCklq6nL06aRaL08rpuTh +U8xiUqspIBtYQiZL6+nnSKgBeAu9gWarGfGbh7C+DflJWZiJL+8J8zVpyliZ9M4YS IBQ2lUWhsWsGQ== Received: from [10.0.2.130] ([73.62.165.147]) by mail2.karels.net with ESMTPSA id +RIPGP8+H2YBVQAAs/W3XQ:T2 (envelope-from ); Tue, 16 Apr 2024 22:16:35 -0500 From: Mike Karels To: Mark Johnston Cc: freebsd-arch@freebsd.org Subject: Re: requiring reserved NFS client ports by default Date: Tue, 16 Apr 2024 22:16:35 -0500 X-Mailer: MailMate (1.14r6028) Message-ID: <8666AC5F-F797-489F-944D-CD7B4D373766@karels.net> In-Reply-To: References: List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain 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:16509, ipnet:3.16.0.0/14, country:US] X-Rspamd-Queue-Id: 4VK5ff3jSlz4NSb On 16 Apr 2024, at 18:05, Mark Johnston wrote: > It's common practice for NFS clients to bind to reserved ports (i.e., <= > 1023) since some NFS servers require this as a weak security measure > against attackers with network access to a server but without local > privileges. FreeBSD's NFS server does not require clients to use > privileged ports by default, but this can be changed by setting > nfs_reserved_port_only=YES in rc.conf. > > I would like to propose flipping the default for nfs_reserved_port_only. > This raises the bar a bit for a malicious agent able to execute > unprivileged code on a machine with network access to an unauthenticated > NFS server running FreeBSD. This behaviour would match the defaults on > Linux (the per-export "secure" attribute) and OpenBSD. > > The downside is increased pressure on the limited range of reserved port > numbers. However, the server will complain on the console if a request > arrives on an unreserved port, so diagnosis should be easy, and most > clients sport an option to not use a reserved port number (noresvport on > FreeBSD), so one can configure client mounts to use them only where > needed. And, the option is easy to disable on the server should that be > necessary. My aim here is to provide a safer out-of-the-box behaviour. > > Any comments, objections, feedback? I think this is a good idea. It should block one class of surreptitious access by unprivileged users on a machine in the export list, and there doesn't seem to be much downside. Mike From nobody Wed Apr 17 03:53:06 2024 X-Original-To: arch@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 4VK6Sw1BjWz5Hkwq for ; Wed, 17 Apr 2024 03:53:20 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com [IPv6:2a00:1450:4864:20::530]) (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 4VK6Sv6VRNz4Z5l for ; Wed, 17 Apr 2024 03:53:19 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ed1-x530.google.com with SMTP id 4fb4d7f45d1cf-563cb3ba9daso5115229a12.3 for ; Tue, 16 Apr 2024 20:53:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1713325998; x=1713930798; 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=tlNDMJejlzh9ISbBW+NDEwghDc6NRoCqV8Dm6sAuZmw=; b=hxOtEn3AqZ2B3GH5lyrYu417Vqf4Bl8y1uxzx5mjD2+kpvVkgyatrORXPlRqk4cXcg kHmC8Kj2APNks7S/R8hJ9255C6KrR2LmhK43kFoi1KcoJIJuMB0G12iMvwOHTEYF20co s51rBXNspEbkPHqgxZ9Jrdhm/N1CV5552ZB7CVQOK37nSP4xsvtuetywPbvYpnWG3uGV rc9tslx/6ck/GyA7lmbvnwJDsl9f9WUUCtHcziZWPJVhR1mV1cR/dQj37PIFMmfp0iO2 fMhRKh7RtLWpzJ4fyVsyV/vRVFcC7wsA4ug6GqDCn1fF1jeKUQ+lFVNAKkG0X3CC++ky 0HHA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1713325998; x=1713930798; 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=tlNDMJejlzh9ISbBW+NDEwghDc6NRoCqV8Dm6sAuZmw=; b=F2ozQHA/WhcGgZg8AyWaMrsH6UaXJL6YAbnLESV1XTTzbp/IKCiVk3KkvU/pVytYYH f/MtDax/ivesJY5EdNHY9ew8IEC32tfHizVj9HblKI0cdUbKYyLuXLAttYhm4hUneuBn C+BHfv2i4KwY0UjX/8IYAETlEzeNcTwtO5zb689aZppkWZxXh8fPmzgU008OpC+rUKYV IV4sdhDh1Z3ERGh3zqcHyhRyIi7W9Txu+HJQ7B1ttruzqcKD3+zc7qL0+kJYN6fagBAN VMk09MFgNNMCgv+WCdCEYdX0pfnNXbpqwcqnld/McbbIiWe4WI2jHaRVvBxBTg2NJJdK GsNg== X-Forwarded-Encrypted: i=1; AJvYcCWxh51W7qxevwjuQOCfb+fdim4FmRT2K8jip/84R5t6WZ4+pAeyItQUvZA5+edCMA7MXp4BNvoXgCW+dq/NBYkM X-Gm-Message-State: AOJu0YwWvz4BDvQxNMATblmzWVHuwBONwg9iP+9L3MxUJVZTjEqLHlYE ZBaDa/iiT3d/YXAgX35NbWAFpL0iUOxnAEQDiVaK11/W4YXE0VTUM0hzXOPChfK5nuMFHQoIgrz RZMQv+mGiMfpJWXRVvJfOyHFigaFx+JrOJ0Zlow== X-Google-Smtp-Source: AGHT+IFUse/KDkxzKEVmK0Go2Dm04fKepszoUl16ych361J6cEQacKUWsB8j9MlzUFZ/AHYYVonf8o4TugUZ7nKLDAY= X-Received: by 2002:a17:907:7daa:b0:a55:57bb:35d6 with SMTP id oz42-20020a1709077daa00b00a5557bb35d6mr447793ejc.36.1713325998183; Tue, 16 Apr 2024 20:53:18 -0700 (PDT) List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@FreeBSD.org MIME-Version: 1.0 References: <0100018ee9e8a381-2e0a8845-5321-4841-bfaf-184376e88112-000000@email.amazonses.com> In-Reply-To: <0100018ee9e8a381-2e0a8845-5321-4841-bfaf-184376e88112-000000@email.amazonses.com> From: Warner Losh Date: Tue, 16 Apr 2024 21:53:06 -0600 Message-ID: Subject: Re: enable INVARIANT_SUPPORT in GENERIC in release builds To: Colin Percival Cc: Lexi Winter , arch@freebsd.org Content-Type: multipart/alternative; boundary="00000000000081b52d061642cba9" 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] X-Rspamd-Queue-Id: 4VK6Sv6VRNz4Z5l --00000000000081b52d061642cba9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Apr 16, 2024 at 8:35=E2=80=AFPM Colin Percival wrote: > On 4/16/24 14:00, Lexi Winter wrote: > > currently release version of GENERIC (or GENERIC-NODEBUG in main) does > > not have INVARIANT_SUPPORT enabled. > > > > unfortunately, the presence or absense of this option breaks the KABI > > because, as i understand it, modules built with INVARIANTS won't load o= n > > a kernel without INVARIANT_SUPPORT. > > > > is there a reason INVARIANT_SUPPORT can't just be enabled by default? > > I think while it had much lower overhead than INVARIANTS, there was still > a significant overhead cost at least in the early days. Maybe that's no > longer the case. > I thought it had no overhead (despite the comments saying it does). It only increases runtime from what I can see if INVARIANTS or WITNESS are defined. > > this would remove one roadblock to separating kernel modules from the > > kernel config in both pkgbase and ports, because there would be no need > > to build a KABI-incompatible kernel just to build a single module with > > INVARIANTS. > > If the overhead cost of INVARIANT_SUPPORT is no longer relevant, I'd be > fine with including it in stable/15. Of course we can't turn it on for > stable/1[34] for the ABI reasons you just mentioned > I think that it just exports more functions, so that's something that could be exported. Warner --00000000000081b52d061642cba9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Apr 16, 2024 at 8:35=E2=80=AF= PM Colin Percival <cperciva@tars= nap.com> wrote:
On 4/16/24 14:00, Lexi Winter wrote:
> currently release version of GENERIC (or GENERIC-NODEBUG in main) does=
> not have INVARIANT_SUPPORT enabled.
>
> unfortunately, the presence or absense of this option breaks the KABI<= br> > because, as i understand it, modules built with INVARIANTS won't l= oad on
> a kernel without INVARIANT_SUPPORT.
>
> is there a reason INVARIANT_SUPPORT can't just be enabled by defau= lt?

I think while it had much lower overhead than INVARIANTS, there was still a significant overhead cost at least in the early days.=C2=A0 Maybe that= 9;s no
longer the case.

I thought it had no ov= erhead (despite the comments saying it does). It
only increases r= untime from what I can see if INVARIANTS or WITNESS
are defined.<= br>
=C2=A0
> this would remove one roadblock to separating kernel modules from the<= br> > kernel config in both pkgbase and ports, because there would be no nee= d
> to build a KABI-incompatible kernel just to build a single module with=
> INVARIANTS.

If the overhead cost of INVARIANT_SUPPORT is no longer relevant, I'd be=
fine with including it in stable/15.=C2=A0 Of course we can't turn it o= n for
stable/1[34] for the ABI reasons you just mentioned
I think that it just exports more functions, so that's som= ething that could be exported.

Warner
--00000000000081b52d061642cba9-- From nobody Wed Apr 17 05:38:10 2024 X-Original-To: freebsd-arch@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 4VK8pC6NfHz5HtC5 for ; Wed, 17 Apr 2024 05:38:27 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic301-20.consmr.mail.gq1.yahoo.com (sonic301-20.consmr.mail.gq1.yahoo.com [98.137.64.146]) (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 did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4VK8pC00mVz4kHx for ; Wed, 17 Apr 2024 05:38:26 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=DKZ4HAc4; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.146 as permitted sender) smtp.mailfrom=marklmi@yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1713332304; bh=N0ULpPnI4Floqs9elZJLy778NzuIUmT1TlYhtEy4KE0=; h=From:Subject:Date:References:To:In-Reply-To:From:Subject:Reply-To; b=DKZ4HAc43gmghByEAksGtJaZ9D5ElWVZNS/8X9IH+bZmQcs8NrqGO40YTjarBEVo/ssPq5Tm4OcVrj9tTLgxm7Fi2z3YuGSlnij4puRCSZeoQFM1l214rVtpVwXvprAIbaPNa/dSkio/Fxn1dIwq6lBTCABSHD6ynCk7ZYSvBR2QP9896dQt6ZaEu5AOnt+BhEkA0/+kGFbu/N9nUea8rV99ba0sQh0jJ0rWCJBzFEf3dMwgHyNfMoO33cXdqEkf64jcVN1TkvpS4mYqIo54ClEgnqK2OsFvJC4K21hM4MMkV44ahDYvLtHGHvvKoVuCMnAUh0InFMyYeJJLkm3c8g== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1713332304; bh=rEC+SN3KreMIjKrVxFrdUOzQfD1yueaBCdqqIrNYAsl=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=spew1cy6QtMZzeK89cfOsEWWs8MiaBqiXx2r111ixEjyUGmhrSeyIUePWaHJSUeQZZKohx0rfJAjqYv7dZ9M83UiYg5VywGsIQlzVr+W9+gib5qktjs9Ozr+I+MVt2SSBke7mZSyby0UsuJzLst5yODrBxnmzKY9lI1zGtPsbywoIg0KIO38g4ewqyTNrCrPwSR6Sbyrx/m+a+ChzPaAnwmZMr+tEtiFUIODUe7g+uwAlKpu87sMFUo5XqHlDuP4fOKp+4/SF/uduvoPkT4mow+cBHox/eFGTKCaEqb1n2kBAAiA9MFmkIrnRWfKm2IkAqJIry39lB5A/V6CrofjSA== X-YMail-OSG: Akr2a9gVM1mkyN0Gu84l6KshBZhsPMJQF31bS_d8WehAPTWk_zcgQ_RJKHv2jIV 7xjdF.nDleSGDj0GQZO7XD65XWDz2E.gnwkU2lReiI7H4j0g5utTkcm7UWzhEO0Sa9Tct5CHIAsW KZtPO2uthi5bebp0dcUFY17pVEiMA0qK5Qqpl4mkx.83E_0NPC05zvD0Da81Av8XUn2cMWsT7Vro sIDDHOVBuellMyZqMy0XTPDIIc66KQzpsqJ9jYzLae_lBoyEtAxY89rTp3FhBlPnVRexwero9Gih ih..vMf8EzAFM4jYd8W2AANdjPt.bkf5_nIBLUWgi1p4obGTXqRN1yS3kYzK.BWh0b5K0n.Q9_QE aW1cUl9Lhd3cN6uw5dtUFDurrOdcSKtTxj5rDq_Bz4a8n6znTrDGfZOVrT3EK_tsW3rayfvqTora q_9LfimRF4pH1fXIook_JcxlA5IMsJC0WRfUGNHvHvrUdtUNM7NDYyzcuCAx2lT5_wWaOno9UE8G 4WkUS9fmLMZBvQTsJSUXPO8OV9U9KOWeKiP8n6VQ6dtaZVpT0zcYRVlb_wF.138EvVxoPLt8hh5B VI5fb_kQ0j6W72tfAFSgxS2rSDw5XwCqZbumqlMqUTLeASlDHikOeA3jBEsPKjoAzfYJyxNjqDhy 8V2C.x6Msrx4ljof9KO2sTfnV8ZgbT2Yz6G53237Qk7Ksi5oBpHR794wuQ5rwUO4t9AUw7jY8X8f ZMopFMHBA56NZXaHEbhI9974pwkmStqN02cqG9k0InETqetIPxE9gTUKawSpBWMPI94J_w4TK2g_ YoGdBj5yzfTsA0vI7uzwhj0F9IC240buIdUg_fGg4bTvTXwwWt9DoCGwhrRxZYgOhhRA8Nc6vKGD RznmUrD3xO4ptOW_TCtev0XL1Byl5hM2XRPEFTMi2HqWFCKHjxaa6Oz0p6x43dxq7wnALE7AT9Po 2sBTi1fKIl3sZqx2Q_fa4bqZRl8q3VeTAB1X2WKjbFWy97NjtcvqGianpvvBy.kW_jRXFKovL9Ye ehwGMW95PSfsWN2uint4GynbmdaAmjMKkJb8NwlzawmrCOWewOqmZAbPbChLBoBvhNE7fwJjuuP_ gb5HOgYBt4niknNXRyjcD7O_vb22vUFb0FqCMe3zs98vF1mQHcK553XqMR5QHS8jFNIjsi1CR0ni jur6Uw2x.9YSuj1bmsmCcnDrYov46t4duPF1GO8XQu0lBBrpzZ6k4hJ49h7uNd5VVV1GZjpczQKQ WSTj5RPa7kDAfgREE19Mw1oAuiTZFkV3LrQP.L0JtPQI_myxC_.svNHq7.NZMWoDPEDWnFn50jCy _CwY_8VxHu5oq.HHzuRkFirVOMEGAVredlihDwtWv1Exba6ktk3H6YvQqGn88z5BpiG5l6CgeKon So77AGG7NJbGdJXf0DkzGDLipkaFrNQRS1fJvvVercWTeUlMKFFlvRrsQ9J1RLBj7Fl7byurXRhf gdMkby5Jbr.EPObY5_K5dqq3KevqbU4X_77aOy5_9PNh4.vhP3s.rIXMELq.5A3k4DAQOVwb.j7k ED5nNavv2GMFXbnePn6RPM8qZwkGjnrO_uA_NLSLSfojzmtoaYMgssq5lpvHitIKI.RCp9v99tnr QeYJaHTbf1GUVVHAGs07qxR9Ky2TlxWmN1uccuYbjLdoVlmRC70YN3K22VcAHsiVmSlHtwFkbuxd nENrsqgnr.0CMWv46jTYhE8pYmrIeSBOBeQgwyvP0Mnzf5ykrSYRhVOI40eoyDqkTs4D63hTjEwm ad49lttluBNyLBmFJAGyPvuq.FzwPWhqQNeqH64UWl1pcruU1LBtEY3hMHfVwJWhK5Uw8MEQ2XwY WfJXxj4xS1aFd6X4DKXG7i4b.HU_NW4Obp1f0EPFXl.61HLLUfxtmyZg4OE4SwxUO_o.s88Unswc _WdYjEnSqOE5KpEqqMvPOeUuoEE1EJCCNmX_vwoxeAt7RkZqGT8bM1SCujy0eORAyZydNvqETAzg 2KJLHnDJMIJzDRhtzRSqwNAy9x0KjjlRy5xl2ouPUyjZDsoH9H0WrJFchYZJ1AuvZles.gaDGBcX XdVkoTKKCNynWGFmyg4LjTtklD8n2gk2ohgQ3Y9k4OI5LmB2km4rWF_53JCERJ12XmPdnoMFrnzI ARYNOCBKntHqUbB45_44ut28wMbntBTVplzBwOHd5rShGy8NUVlmNd5X2EmaBpQuml0L6nBDMgOG uWJnOF9BvgyjZexC6LSIV4Gzg6SBlOq7uVKLTyPucURzP1ISUupUONY16Yw-- X-Sonic-MF: X-Sonic-ID: 08442a97-a983-45f2-b9f7-2cc1a3cb6038 Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.gq1.yahoo.com with HTTP; Wed, 17 Apr 2024 05:38:24 +0000 Received: by hermes--production-gq1-59c575df44-f4snh (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 18cf053057630b6d2b2104c65110c64a; Wed, 17 Apr 2024 05:38:21 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@FreeBSD.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.500.171.1.1\)) Subject: Re: enable INVARIANT_SUPPORT in GENERIC in release builds Date: Tue, 16 Apr 2024 22:38:10 -0700 References: <8AAD5999-A107-480F-9854-73A0785EDD59@yahoo.com> <83EA0609-EBB4-4E14-AD6F-5F5564C5D78E@yahoo.com> To: freebsd-arch In-Reply-To: <83EA0609-EBB4-4E14-AD6F-5F5564C5D78E@yahoo.com> Message-Id: <4E93DED0-8848-4A41-B86D-1295FBA12238@yahoo.com> X-Mailer: Apple Mail (2.3774.500.171.1.1) X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.50 / 15.00]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; MV_CASE(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; MIME_GOOD(-0.10)[text/plain]; TO_DN_ALL(0.00)[]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; FROM_HAS_DN(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; MLMMJ_DEST(0.00)[freebsd-arch@freebsd.org]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.146:from]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RCVD_IN_DNSWL_NONE(0.00)[98.137.64.146:from] X-Rspamd-Queue-Id: 4VK8pC00mVz4kHx [Just sending to the list this time, which also was missing.] On Apr 16, 2024, at 21:03, Mark Millard wrote: [Just a resend fixing a Email address that I messed up.] On Apr 16, 2024, at 20:57, Mark Millard wrote: Colin Percival wrote on Date: Wed, 17 Apr 2024 02:35:21 UTC : > On 4/16/24 14:00, Lexi Winter wrote: >> currently release version of GENERIC (or GENERIC-NODEBUG in main) = does >> not have INVARIANT_SUPPORT enabled. >>=20 >> unfortunately, the presence or absense of this option breaks the KABI >> because, as i understand it, modules built with INVARIANTS won't load = on >> a kernel without INVARIANT_SUPPORT. >>=20 >> is there a reason INVARIANT_SUPPORT can't just be enabled by default? >=20 > I think while it had much lower overhead than INVARIANTS, there was = still > a significant overhead cost at least in the early days. Maybe that's = no > longer the case. >=20 >> this would remove one roadblock to separating kernel modules from the >> kernel config in both pkgbase and ports, because there would be no = need >> to build a KABI-incompatible kernel just to build a single module = with >> INVARIANTS. >=20 > If the overhead cost of INVARIANT_SUPPORT is no longer relevant, I'd = be > fine with including it in stable/15. I think the context here is intended to be more like (aarch64 example): = https://pkg.freebsd.org/FreeBSD:15:aarch64/base_latest/FreeBSD-kernel-gene= ric-nodebug-15.snap20240416014449.pkg with: = https://pkg.freebsd.org/FreeBSD:15:aarch64/base_latest/FreeBSD-kernel-gene= ric-nodebug-dbg-15.snap20240416014449.pkg These are from a release style build of main [so: 15] but via FreeBSD's own PkgBase distribution. # ls -C1 /boot/kernel*/kernel /boot/kernel.CA76-DBG/kernel /boot/kernel.CA76-NODBG.good/kernel /boot/kernel.CA76-NODBG.old/kernel /boot/kernel.CA76-NODBG/kernel /boot/kernel.GENERIC-DEBUG.good/kernel /boot/kernel.GENERIC-MMCCAM/kernel /boot/kernel.GENERIC-NODEBUG.good/kernel /boot/kernel.GENERIC-NODEBUG/kernel /boot/kernel/kernel The /boot/kernel.GENERIC-NODEBUG/ is from the likes of the above generic-nodebug-15 (but older). The /boot/kernel.CA76-*/ are my personal builds. (I'll not show where debug files go.) I was very happy to finally have official release of main to test for problem repeatability for release-style builds without my build(s) involved. Yea, I've also had rare examples where the likes of: = https://pkg.freebsd.org/FreeBSD:15:aarch64/base_latest/FreeBSD-kernel-gene= ric-15.snap20240416014449.pkg with: = https://pkg.freebsd.org/FreeBSD:15:aarch64/base_latest/FreeBSD-kernel-gene= ric-dbg-15.snap20240416014449.pkg got differing behavior, including generic-nodebug-15 failing where generic-15 worked silently. Having INVARIANT_SUPPORT might mess up being able to check on official-release-style vs. personal-build distinctions as I've been doing. The /boot/kernel/kernel is from the likes of the above generic-15 (but older). [I do not really use /boot/kernel.GENERIC-MMCCAM/ (yet?).] I will note that I do not normally build modules that trace back to a port build being involved or the like: just what buildworld buildkernel sorts of activity build normally. I'm actively using such kernels, having installed the PkgBase ones and my own tailored build and picking which to use when. (I'm not claiming my usage pattern should drive what FreeBSD does.) > Of course we can't turn it on for > stable/1[34] for the ABI reasons you just mentioned. =3D=3D=3D Mark Millard marklmi at yahoo.com =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Wed Apr 17 10:16:13 2024 X-Original-To: arch@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 4VKGz149d5z5GZgJ for ; Wed, 17 Apr 2024 10:16:29 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (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 did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4VKGz10tgdz4R41 for ; Wed, 17 Apr 2024 10:16:29 +0000 (UTC) (envelope-from kostikbel@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: from tom.home (kib@localhost [127.0.0.1] (may be forged)) by kib.kiev.ua (8.18.1/8.18.1) with ESMTP id 43HAGE9t015705; Wed, 17 Apr 2024 13:16:17 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 43HAGE9t015705 Received: (from kostik@localhost) by tom.home (8.18.1/8.18.1/Submit) id 43HAGDKg015704; Wed, 17 Apr 2024 13:16:13 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 17 Apr 2024 13:16:13 +0300 From: Konstantin Belousov To: Warner Losh Cc: Colin Percival , Lexi Winter , arch@freebsd.org Subject: Re: enable INVARIANT_SUPPORT in GENERIC in release builds Message-ID: References: <0100018ee9e8a381-2e0a8845-5321-4841-bfaf-184376e88112-000000@email.amazonses.com> List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=4.0.0 X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-14) on tom.home 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:6939, ipnet:2001:470::/32, country:US] X-Rspamd-Queue-Id: 4VKGz10tgdz4R41 On Tue, Apr 16, 2024 at 09:53:06PM -0600, Warner Losh wrote: > On Tue, Apr 16, 2024 at 8:35 PM Colin Percival wrote: > > > On 4/16/24 14:00, Lexi Winter wrote: > > > currently release version of GENERIC (or GENERIC-NODEBUG in main) does > > > not have INVARIANT_SUPPORT enabled. > > > > > > unfortunately, the presence or absense of this option breaks the KABI > > > because, as i understand it, modules built with INVARIANTS won't load on > > > a kernel without INVARIANT_SUPPORT. > > > > > > is there a reason INVARIANT_SUPPORT can't just be enabled by default? > > > > I think while it had much lower overhead than INVARIANTS, there was still > > a significant overhead cost at least in the early days. Maybe that's no > > longer the case. > > > > I thought it had no overhead (despite the comments saying it does). It > only increases runtime from what I can see if INVARIANTS or WITNESS > are defined. > > > > > this would remove one roadblock to separating kernel modules from the > > > kernel config in both pkgbase and ports, because there would be no need > > > to build a KABI-incompatible kernel just to build a single module with > > > INVARIANTS. > > > > If the overhead cost of INVARIANT_SUPPORT is no longer relevant, I'd be > > fine with including it in stable/15. Of course we can't turn it on for > > stable/1[34] for the ABI reasons you just mentioned > > > > I think that it just exports more functions, so that's something that could > be exported. No, it does not. For instance, for buffer cache, INVARIANTS_SUPPORT makes buffer lock asserts into real calls into lockmgr. It might do something similar to the inpcb locks as well. Fixing such case and making INVARIANTS_SUPPORT indeed only export some functions would be a pre-requisite to enabling it for all users. But then, it raises a question, what are the KBI differences between no-SUPPORT and SUPPORT kernels are, except exported functions? From nobody Wed Apr 17 20:14:27 2024 X-Original-To: freebsd-arch@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 4VKXF20rt2z5H3gh for ; Wed, 17 Apr 2024 20:14:30 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from omta002.cacentral1.a.cloudfilter.net (omta002.cacentral1.a.cloudfilter.net [3.97.99.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4VKXF15Zxwz4P7m; Wed, 17 Apr 2024 20:14:29 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Authentication-Results: mx1.freebsd.org; none Received: from shw-obgw-4003a.ext.cloudfilter.net ([10.228.9.183]) by cmsmtp with ESMTPS id x806ruQ2HdrxExBfprQGdy; Wed, 17 Apr 2024 20:14:29 +0000 Received: from spqr.komquats.com ([70.66.152.170]) by cmsmtp with ESMTPSA id xBforyHW0ByQrxBfprfmew; Wed, 17 Apr 2024 20:14:29 +0000 X-Authority-Analysis: v=2.4 cv=UOF+Hzfy c=1 sm=1 tr=0 ts=66202da5 a=y8EK/9tc/U6QY+pUhnbtgQ==:117 a=y8EK/9tc/U6QY+pUhnbtgQ==:17 a=kj9zAlcOel0A:10 a=raytVjVEu-sA:10 a=1QTDH3R-AAAA:8 a=YxBL1-UpAAAA:8 a=6I5d2MoRAAAA:8 a=EkcXrb_YAAAA:8 a=5fe8LRJQsHvezNVJpSAA:9 a=CjuIK1q_8ugA:10 a=A7PbjfUNzwAiWwc5k9lq:22 a=Ia-lj3WSrqcvXOmTRaiG:22 a=IjZwj45LgO3ly-622nXo:22 a=LK5xJRSDVpKd5WXXoEvA:22 Received: from slippy.cwsent.com (slippy [10.1.1.91]) by spqr.komquats.com (Postfix) with ESMTP id D7B1AAA; Wed, 17 Apr 2024 13:14:27 -0700 (PDT) Received: by slippy.cwsent.com (Postfix, from userid 1000) id C547810C; Wed, 17 Apr 2024 13:14:27 -0700 (PDT) X-Mailer: exmh version 2.9.0 11/07/2018 with nmh-1.8+dev Reply-to: Cy Schubert From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.cschubert.com/ To: Mike Karels cc: Mark Johnston , freebsd-arch@freebsd.org Subject: Re: requiring reserved NFS client ports by default In-reply-to: <8666AC5F-F797-489F-944D-CD7B4D373766@karels.net> References: <8666AC5F-F797-489F-944D-CD7B4D373766@karels.net> Comments: In-reply-to Mike Karels message dated "Tue, 16 Apr 2024 22:16:35 -0500." List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@FreeBSD.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 17 Apr 2024 13:14:27 -0700 Message-Id: <20240417201427.C547810C@slippy.cwsent.com> X-CMAE-Envelope: MS4xfHqsXU8bxT8Dxrdfzrhg8W8rB2Y2xoZPEG8NTtxEs6Gf4dYibf0kPXxqgiNzngM7Yazg45hTaIEOmuOI4lUigVukEt2GMaM2hg0OAcipTrtxRVVVCsm/ 697Blex02YRXBTjn3JBK2sfBjwoMk+DdCvfIJH2K9GYRktgR/eVzbsOn2OgVxFn1qsxn5SilZBMxuN1od/NLC8+DoI1KpS8k1QPX4CCprV3+AK32NFjxKNL6 xfIb2utBkchhFsxXuAM2Ah08ypVCyuUn6KR42AOxb4o= 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:16509, ipnet:3.96.0.0/15, country:US] X-Rspamd-Queue-Id: 4VKXF15Zxwz4P7m In message <8666AC5F-F797-489F-944D-CD7B4D373766@karels.net>, Mike Karels write s: > On 16 Apr 2024, at 18:05, Mark Johnston wrote: > > > It's common practice for NFS clients to bind to reserved ports (i.e., <= > > 1023) since some NFS servers require this as a weak security measure > > against attackers with network access to a server but without local > > privileges. FreeBSD's NFS server does not require clients to use > > privileged ports by default, but this can be changed by setting > > nfs_reserved_port_only=YES in rc.conf. > > > > I would like to propose flipping the default for nfs_reserved_port_only. > > This raises the bar a bit for a malicious agent able to execute > > unprivileged code on a machine with network access to an unauthenticated > > NFS server running FreeBSD. This behaviour would match the defaults on > > Linux (the per-export "secure" attribute) and OpenBSD. > > > > The downside is increased pressure on the limited range of reserved port > > numbers. However, the server will complain on the console if a request > > arrives on an unreserved port, so diagnosis should be easy, and most > > clients sport an option to not use a reserved port number (noresvport on > > FreeBSD), so one can configure client mounts to use them only where > > needed. And, the option is easy to disable on the server should that be > > necessary. My aim here is to provide a safer out-of-the-box behaviour. > > > > Any comments, objections, feedback? > > I think this is a good idea. It should block one class of surreptitious > access by unprivileged users on a machine in the export list, and there > doesn't seem to be much downside. > > Mike Agreed. -- Cheers, Cy Schubert FreeBSD UNIX: Web: https://FreeBSD.org NTP: Web: https://nwtime.org e^(i*pi)+1=0 From nobody Wed Apr 17 21:41:06 2024 X-Original-To: arch@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 4VKZ9D6tzRz5HCK7 for ; Wed, 17 Apr 2024 21:41:20 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ej1-x635.google.com (mail-ej1-x635.google.com [IPv6:2a00:1450:4864:20::635]) (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 4VKZ9D3r0Nz4ZBJ for ; Wed, 17 Apr 2024 21:41:20 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ej1-x635.google.com with SMTP id a640c23a62f3a-a526d381d2fso232471566b.0 for ; Wed, 17 Apr 2024 14:41:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1713390078; x=1713994878; 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=+m9rfAKflSysNI6FQrVhDUorWxZHTeUAW2KI7EGdHkc=; b=Y31WAaEORrCXBpIUMeXbLwMIjd10ygSA3wFsXqQru1TV8fBQZ09i/gkCPG0LsxQyyL afaAafwhxXGWxuLQG+mD0tBtHZtiGuF5PIFID37taOZequoEhugWNoeHw8jXlpP8pKM0 PS2eJXcyiOiK85VAGS+OKPr8Yzpmv+Dj//99rkfQpU4FxEUyu8lua2hts281Dw255XMd O+2IYzVxg7Mde24LRb7LHs65BbEG7iwM8Lkr5lbhzL/Y6lk0dfEJKG2pJmZ3kHckgkvo C/5ep+ne3aR/BLpbwcH4bzP3ECfdq+CYGNNLs/vrIGE+4XKpdtC5rhBmwrXcMFcPoU3f zWhg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1713390078; x=1713994878; 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=+m9rfAKflSysNI6FQrVhDUorWxZHTeUAW2KI7EGdHkc=; b=hikb0mXg/HaK+6mll4N9cBPemohubem8qIL5+Rv04Bw8jSiQ3iiO+b485Oifsy8TC6 ssuINfmvPKWU6KECrskRjRCMON5VE7A8ieepXEl0xwL/oWm1cxpwv8DSBZdi7BJ6oYN8 qdX//c5XTllZZAhI1u7ZuZA5ZtcReNVfHhNlq9G/tkgrf9Mojoe8+/0Drk336xTlF0ue aVvnOZQwj628luoaCMi2Gjuvwh8oRqay+QEkUH3rF/3FsS9l+yIyVA3TvEmO4Bo00+ma U4gyoFE/Z9+RLSGCVbFxFICipvQbkvPTeH+ASje/n7xlu7fvk47VlphmkqKnJYeOVw10 bMnQ== X-Forwarded-Encrypted: i=1; AJvYcCWIzdQ4dOokX20qE23so4R1MUXo/uWJMyCqNterspXVQ39nYOQktqKBMQ2WyAnJOCuAporTAw1R7bKAbJ9fVTga X-Gm-Message-State: AOJu0YxjJiiHAXKirBdcPYZ+M2MIeSbkC68RNNMSVK6Mb8SVKz0i5fpm 1aWRy9EcM2v9+LfCCH0CFC6Tsc1J/558eRIaFxes6Hve/tgGvPyzx0rcv0KD823RXpZDw149Tn7 ByPFsUxpCdIuA3tTN72MihBHvACnzwkn37v0+Qg== X-Google-Smtp-Source: AGHT+IG4KgBpg0EukW4Lq68BCYJHnSlbuBk0L5w6aIHLvNzkqN4W/bGgMqjstWZ5eO3EYqmNKpII2rxuSVuzGjx3r+s= X-Received: by 2002:a17:906:b199:b0:a4e:9a13:5090 with SMTP id w25-20020a170906b19900b00a4e9a135090mr267016ejy.9.1713390078338; Wed, 17 Apr 2024 14:41:18 -0700 (PDT) List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@FreeBSD.org MIME-Version: 1.0 References: <0100018ee9e8a381-2e0a8845-5321-4841-bfaf-184376e88112-000000@email.amazonses.com> In-Reply-To: From: Warner Losh Date: Wed, 17 Apr 2024 15:41:06 -0600 Message-ID: Subject: Re: enable INVARIANT_SUPPORT in GENERIC in release builds To: Konstantin Belousov Cc: Colin Percival , Lexi Winter , arch@freebsd.org Content-Type: multipart/alternative; boundary="000000000000fb43c5061651b65a" 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] X-Rspamd-Queue-Id: 4VKZ9D3r0Nz4ZBJ --000000000000fb43c5061651b65a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Apr 17, 2024 at 4:16=E2=80=AFAM Konstantin Belousov wrote: > On Tue, Apr 16, 2024 at 09:53:06PM -0600, Warner Losh wrote: > > On Tue, Apr 16, 2024 at 8:35=E2=80=AFPM Colin Percival > wrote: > > > > > On 4/16/24 14:00, Lexi Winter wrote: > > > > currently release version of GENERIC (or GENERIC-NODEBUG in main) > does > > > > not have INVARIANT_SUPPORT enabled. > > > > > > > > unfortunately, the presence or absense of this option breaks the KA= BI > > > > because, as i understand it, modules built with INVARIANTS won't > load on > > > > a kernel without INVARIANT_SUPPORT. > > > > > > > > is there a reason INVARIANT_SUPPORT can't just be enabled by defaul= t? > > > > > > I think while it had much lower overhead than INVARIANTS, there was > still > > > a significant overhead cost at least in the early days. Maybe that's > no > > > longer the case. > > > > > > > I thought it had no overhead (despite the comments saying it does). It > > only increases runtime from what I can see if INVARIANTS or WITNESS > > are defined. > > > > > > > > this would remove one roadblock to separating kernel modules from t= he > > > > kernel config in both pkgbase and ports, because there would be no > need > > > > to build a KABI-incompatible kernel just to build a single module > with > > > > INVARIANTS. > > > > > > If the overhead cost of INVARIANT_SUPPORT is no longer relevant, I'd = be > > > fine with including it in stable/15. Of course we can't turn it on f= or > > > stable/1[34] for the ABI reasons you just mentioned > > > > > > > I think that it just exports more functions, so that's something that > could > > be exported. > > No, it does not. For instance, for buffer cache, INVARIANTS_SUPPORT > makes buffer lock asserts into real calls into lockmgr. It might do > something similar to the inpcb locks as well. > Why not make those INVARIANTS then? All the ones for mutexes (which is the bulk of the other uses) just provide the routines, but don't actually make things slow unless one or both of INVARIANTS and WITNESS are included. But I see this in kern_lock.c, which I'm not sure about: #ifndef INVARIANTS #define _lockmgr_assert(lk, what, file, line) #endif which looks like it too requires INVARIANTS. What am I missing? > Fixing such case and making INVARIANTS_SUPPORT indeed only export some > functions would be a pre-requisite to enabling it for all users. > > But then, it raises a question, what are the KBI differences between > no-SUPPORT and SUPPORT kernels are, except exported functions? > I think it is only exported functions. I didn't see anything other than adding calls or defining functions... Warner --000000000000fb43c5061651b65a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Apr 17, 2024 at 4:16=E2=80=AF= AM Konstantin Belousov <kostikbel= @gmail.com> wrote:
On Tue, Apr 16, 2024 at 09:53:06PM -0600, Warner Losh wrote:
> On Tue, Apr 16, 2024 at 8:35=E2=80=AFPM Colin Percival <cperciva@tarsnap.com>= wrote:
>
> > On 4/16/24 14:00, Lexi Winter wrote:
> > > currently release version of GENERIC (or GENERIC-NODEBUG in = main) does
> > > not have INVARIANT_SUPPORT enabled.
> > >
> > > unfortunately, the presence or absense of this option breaks= the KABI
> > > because, as i understand it, modules built with INVARIANTS w= on't load on
> > > a kernel without INVARIANT_SUPPORT.
> > >
> > > is there a reason INVARIANT_SUPPORT can't just be enable= d by default?
> >
> > I think while it had much lower overhead than INVARIANTS, there w= as still
> > a significant overhead cost at least in the early days.=C2=A0 May= be that's no
> > longer the case.
> >
>
> I thought it had no overhead (despite the comments saying it does). It=
> only increases runtime from what I can see if INVARIANTS or WITNESS > are defined.
>
>
> > > this would remove one roadblock to separating kernel modules= from the
> > > kernel config in both pkgbase and ports, because there would= be no need
> > > to build a KABI-incompatible kernel just to build a single m= odule with
> > > INVARIANTS.
> >
> > If the overhead cost of INVARIANT_SUPPORT is no longer relevant, = I'd be
> > fine with including it in stable/15.=C2=A0 Of course we can't= turn it on for
> > stable/1[34] for the ABI reasons you just mentioned
> >
>
> I think that it just exports more functions, so that's something t= hat could
> be exported.

No, it does not. For instance, for buffer cache, INVARIANTS_SUPPORT
makes buffer lock asserts into real calls into lockmgr. It might do
something similar to the inpcb locks as well.

Why not make those INVARIANTS then? All the ones for mutexes (which = is the bulk of the other uses) just provide the routines, but don't act= ually make things slow unless one or both of INVARIANTS and WITNESS are inc= luded.

But I see this in kern_lock.c, which I'= m not sure about:

#ifndef INVARIANTS
#define _l= ockmgr_assert(lk, what, file, line)
#endif

= which looks like it too requires INVARIANTS. What am I missing?
= =C2=A0
Fixing such case and making INVARIANTS_SUPPORT indeed only export some
functions would be a pre-requisite to enabling it for all users.

But then, it raises a question, what are the KBI differences between
no-SUPPORT and SUPPORT kernels are, except exported functions?

I think it is only exported functions. I didn't= see anything other than adding calls or defining functions...
Warner=C2=A0
--000000000000fb43c5061651b65a-- From nobody Thu Apr 18 10:00:12 2024 X-Original-To: arch@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 4VKtYz0nYxz5GWLs for ; Thu, 18 Apr 2024 10:00:23 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (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 did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4VKtYy4xQsz4mWs for ; Thu, 18 Apr 2024 10:00:22 +0000 (UTC) (envelope-from kostikbel@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: from tom.home (kib@localhost [127.0.0.1] (may be forged)) by kib.kiev.ua (8.18.1/8.18.1) with ESMTP id 43IA0DZc068367; Thu, 18 Apr 2024 13:00:16 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 43IA0DZc068367 Received: (from kostik@localhost) by tom.home (8.18.1/8.18.1/Submit) id 43IA0Cs3068359; Thu, 18 Apr 2024 13:00:12 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 18 Apr 2024 13:00:12 +0300 From: Konstantin Belousov To: Warner Losh Cc: Colin Percival , Lexi Winter , arch@freebsd.org Subject: Re: enable INVARIANT_SUPPORT in GENERIC in release builds Message-ID: References: <0100018ee9e8a381-2e0a8845-5321-4841-bfaf-184376e88112-000000@email.amazonses.com> List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=4.0.0 X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-14) on tom.home 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:6939, ipnet:2001:470::/32, country:US] X-Rspamd-Queue-Id: 4VKtYy4xQsz4mWs On Wed, Apr 17, 2024 at 03:41:06PM -0600, Warner Losh wrote: > On Wed, Apr 17, 2024 at 4:16 AM Konstantin Belousov > wrote: > > > On Tue, Apr 16, 2024 at 09:53:06PM -0600, Warner Losh wrote: > > > On Tue, Apr 16, 2024 at 8:35 PM Colin Percival > > wrote: > > > > > > > On 4/16/24 14:00, Lexi Winter wrote: > > > > > currently release version of GENERIC (or GENERIC-NODEBUG in main) > > does > > > > > not have INVARIANT_SUPPORT enabled. > > > > > > > > > > unfortunately, the presence or absense of this option breaks the KABI > > > > > because, as i understand it, modules built with INVARIANTS won't > > load on > > > > > a kernel without INVARIANT_SUPPORT. > > > > > > > > > > is there a reason INVARIANT_SUPPORT can't just be enabled by default? > > > > > > > > I think while it had much lower overhead than INVARIANTS, there was > > still > > > > a significant overhead cost at least in the early days. Maybe that's > > no > > > > longer the case. > > > > > > > > > > I thought it had no overhead (despite the comments saying it does). It > > > only increases runtime from what I can see if INVARIANTS or WITNESS > > > are defined. > > > > > > > > > > > this would remove one roadblock to separating kernel modules from the > > > > > kernel config in both pkgbase and ports, because there would be no > > need > > > > > to build a KABI-incompatible kernel just to build a single module > > with > > > > > INVARIANTS. > > > > > > > > If the overhead cost of INVARIANT_SUPPORT is no longer relevant, I'd be > > > > fine with including it in stable/15. Of course we can't turn it on for > > > > stable/1[34] for the ABI reasons you just mentioned > > > > > > > > > > I think that it just exports more functions, so that's something that > > could > > > be exported. > > > > No, it does not. For instance, for buffer cache, INVARIANTS_SUPPORT > > makes buffer lock asserts into real calls into lockmgr. It might do > > something similar to the inpcb locks as well. > > > > Why not make those INVARIANTS then? All the ones for mutexes (which is the > bulk of the other uses) just provide the routines, but don't actually make > things slow unless one or both of INVARIANTS and WITNESS are included. > > But I see this in kern_lock.c, which I'm not sure about: > > #ifndef INVARIANTS > #define _lockmgr_assert(lk, what, file, line) > #endif > > which looks like it too requires INVARIANTS. What am I missing? Right, I mean that some parts of INVARIANTS_SUPPORT needs to be cleaned first ... > > > > Fixing such case and making INVARIANTS_SUPPORT indeed only export some > > functions would be a pre-requisite to enabling it for all users. > > > > But then, it raises a question, what are the KBI differences between > > no-SUPPORT and SUPPORT kernels are, except exported functions? > > > > I think it is only exported functions. I didn't see anything other than > adding calls or defining functions... > ... and then this option can be removed altogether, by providing the exported functions unconditionally. From nobody Thu Apr 18 17:24:11 2024 X-Original-To: arch@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 4VL4QJ3lgtz5HFBF for ; Thu, 18 Apr 2024 17:24:24 +0000 (UTC) (envelope-from lexi@le-fay.org) Received: from fuchsia.eden.le-Fay.ORG (fuchsia.eden.le-fay.org [81.187.47.195]) by mx1.freebsd.org (Postfix) with ESMTP id 4VL4QH2kWrz53Cg for ; Thu, 18 Apr 2024 17:24:23 +0000 (UTC) (envelope-from lexi@le-fay.org) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=le-fay.org header.s=fuchsia header.b=hcI0Ge8U; dmarc=none; spf=pass (mx1.freebsd.org: domain of lexi@le-fay.org designates 81.187.47.195 as permitted sender) smtp.mailfrom=lexi@le-fay.org Received: from iris.eden.le-Fay.ORG (iris.eden.le-fay.org [IPv6:2001:8b0:aab5:106:3::6]) by fuchsia.eden.le-Fay.ORG (Postfix) with ESMTP id C7C3D907C for ; Thu, 18 Apr 2024 17:24:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=le-fay.org; s=fuchsia; t=1713461054; bh=jJzAxS23KJYtxStGB9xlBLtH0Z9kCCXxqihlsrkb/Qo=; h=Date:From:To:Subject; b=hcI0Ge8UCK68M8twAukkxVWmsbE5u6Sod5JaqIIXFYep6D3TSOvi8ccKBIPKBDXJD 4dz7VVVuNfakEAheBHSLzOlIFc4rQZSnHwzr2Q1dygocQrQMw5uwoLJsKze+33f2LW tZICaUr2HktpD/GFTCfVbissP3aI9v/uhIv4rktk= Received: from ilythia.eden.le-fay.org (ilythia.eden.le-fay.org [IPv6:2001:8b0:aab5:106:3::10]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (secp384r1) server-digest SHA384) (No client certificate requested) by iris.eden.le-Fay.ORG (Postfix) with ESMTPSA id 42A942C0416 for ; Thu, 18 Apr 2024 18:24:14 +0100 (BST) Date: Thu, 18 Apr 2024 18:24:11 +0100 From: Lexi Winter To: arch@freebsd.org Subject: mailwrapper behaviour if mailer.conf can't be opened Message-ID: List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@FreeBSD.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="KN3V09NECx4TDrFV" Content-Disposition: inline X-Spamd-Bar: ----- X-Spamd-Result: default: False [-5.50 / 15.00]; SIGNED_PGP(-2.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[le-fay.org:s=fuchsia]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; R_SPF_ALLOW(-0.20)[+ip4:81.187.47.195]; RCVD_NO_TLS_LAST(0.10)[]; DKIM_TRACE(0.00)[le-fay.org:+]; FROM_HAS_DN(0.00)[]; DMARC_NA(0.00)[le-fay.org]; TO_MATCH_ENVRCPT_ALL(0.00)[]; ARC_NA(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; MISSING_XM_UA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:20712, ipnet:81.187.0.0/16, country:GB]; TO_DN_NONE(0.00)[]; MID_RHS_MATCH_FROMTLD(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[arch@freebsd.org]; MLMMJ_DEST(0.00)[arch@freebsd.org]; DWL_DNSWL_NONE(0.00)[le-fay.org:dkim] X-Rspamd-Queue-Id: 4VL4QH2kWrz53Cg --KN3V09NECx4TDrFV Content-Type: text/plain; charset=us-ascii Content-Disposition: inline hello, i submitted this change request: https://github.com/freebsd/freebsd-src/pull/969 which was rejected for needing more discussion, so i'd like to discuss that. the current behaviour is that if mailwrapper cannot open mailer.conf for any reason, it calls back to _PATH_DEFAULTMTA. i think this behaviour is bad, because: - if the default MTA has not been configured, it may not be able to deliver mail - if the admin has configured a different MTA, mailwrapper should not fall back to a different MTA because of transient errors - this may hide mail delivery errors from applications by delivering the mail to the wrong MTA instead of returning a failure with my change, mailwrapper will fall back to _PATH_DEFAULTMTA if mailer.conf doesn't exist, which preserves mail functionality if the admin has deleted mailer.conf for some reason. but if mailer.conf can't be opened for any other reason, it will exit with EX_OSERR, returning an error to the application. this was previously discussed on the PR: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=25218 where the argument was made that it's better to make a 'last ditch' attempt to deliver mail if mailer.conf can't be opened. i disagree with this, for the reasons above, and in addition because modern systems generally do not rely on mail delivery to report serious errors -- they are monitored by an external NMS. --KN3V09NECx4TDrFV Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGzBAABCAAdFiEEuwt6MaPcv/+Mo+ftDHqbqZ41x5kFAmYhVzkACgkQDHqbqZ41 x5n7ugv+JfAc7KEA8XQzMMBG5Xif+KeE7WehlO9ewO7BuatETsW5wgtqL74H9NwS W1jt1UqwWxL9myFmw4fD88bLFNxXRZAahBfB5m27pm2FBxXnIqqSSwQb3fpVKhEv jGkiI24YzWyRGmC7Da/rpW6wX0L72EvCxb+QoTzf1pp1dyEmFamPwQa72ErUr05W tI2Teg/q/mbMzuHNGDH2cJ+TI/CIAK1Aa8bTAyFpVqvxUpyrd/Hq420YZvkDG2f6 b6cWmWIAnrJr/y3I+qAc6Yte4hXs/Zp+eUJwc8pPiBdSCOtS8DJWcGr7UYjAbBCl Fi1HcO64yDxqSRx09zLksg2hxZXWxc89MhIBTT5kGIvki7O3sZB+4ypJIUE7Nayp Nktr9I1f2b1pAWd0gLmV+E0QNTsMqjuX3MjGuB5D/5epBmuPV8D5KTlvX6RnnecI gslBZVTyZIp/wJmxKEDk6sp/yTbD+K7jEdcWsZDWNzseJ/uYTEL9DBLAqYTLgFlD S8AipxtS =7/Im -----END PGP SIGNATURE----- --KN3V09NECx4TDrFV-- From nobody Thu Apr 18 23:35:19 2024 X-Original-To: freebsd-arch@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 4VLDfJ61yRz5HK8q for ; Thu, 18 Apr 2024 23:35:20 +0000 (UTC) (envelope-from brooks@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 4VLDfJ5G1Xz4mGf; Thu, 18 Apr 2024 23:35:20 +0000 (UTC) (envelope-from brooks@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1713483320; 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; bh=tY5DxwhvcT4vDv44gNOWOblxKu0eqfYXxFeex/+tZnE=; b=lQIuOu2F6Q2UopKY33bqHs5LQKK3facDtmUKjrDAWP4Y+4c7rqd/IT7LJ8ejxN4iv/k7sQ RLukIf4ZRekuSsYa/0NTwMO041ghyHmTxjohFd5RFMZ+s2cuY9jd78jKvsqDYbcLr4Bzgz 09p3hvHgK6wEQ59dkkrbLWbdp89SDysDFTNJVcyQ3nV5oGyCE/+7gpHSXi98BKhxQIn9OA MLkx8/1d3ditBGCnFTpimMLQVw2hUgPNRzRcHM3fhr1s9iRDoy25qICDcoKJiJjIL4Gh3F iHRlRewBWMjkSRYspK4m9wa3yPCs4SxKWr0uTLb86gDrVbf2sq+AuZfNMNsbkQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1713483320; a=rsa-sha256; cv=none; b=ay6zwMzHh68n4FjjW+pA43UQVNLib1vOn0IhInDtpPpP0yaYqvUHxwdN6xz5WZ/Z0MjwnA gNhf5BeeOj64GNv4DDIiTxqVXR7COellv4+cx2eesAVMr5KtEMdF4HerUVgspGoU8zfX/o 894CMGPLVvDF3BvloE1yQN2JqMT4njBwRZVq5wMX2njldv2TweA0CBYQ56Mmquu/vOy4yi cnfQsXfQv1lMRVr+157uChhjzTpuK6Kxo7qNcZlLepuGPZvB7Ud352Y9CX950o9oSELqsf g5mjfpYTaXX9WX8gkfaGiDvWHlNzfnKFk4L5d/6HBBbcV8QeciZEulPOoXBzaQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1713483320; 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; bh=tY5DxwhvcT4vDv44gNOWOblxKu0eqfYXxFeex/+tZnE=; b=xO59jS+8ZjUWkfn0l2NJSpQwX4Nxp1XKW5ngfJ1oH9jn77U1rQzmRImE3/JJCCEdxJLMk3 SPVHUvZ2E6zsyezJRRf53ccSir3jU6pX80+QYCk8NnJlNOQR4ObfIQEkTmscfMFonFmxF2 KrcegMWP8Bay5KlNVuqHYi297/SuE7ninOv4j2zLBAdXFm8EcTZjg/vTSd3HvyYpsF6Ab/ uHL3RhQp62kXedqdEKgFBPqZ9BAr/6qJ7QiE0/Hi64v+Ax3JKgpq4r7SBKM7Lt4IRdckfq pL9em1Xov30s6H0jNGT7gBATGxbzwKfcfuUcnwpHGcctPjyFggl6LdgZe7dD6A== Received: from spindle.one-eyed-alien.net (spindle.one-eyed-alien.net [199.48.129.229]) (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 did not present a certificate) (Authenticated sender: brooks/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4VLDfJ4cM7zHlx; Thu, 18 Apr 2024 23:35:20 +0000 (UTC) (envelope-from brooks@freebsd.org) Received: by spindle.one-eyed-alien.net (Postfix, from userid 3001) id A7DC63C019B; Thu, 18 Apr 2024 23:35:19 +0000 (UTC) Date: Thu, 18 Apr 2024 23:35:19 +0000 From: Brooks Davis To: freebsd-arch@freebsd.org Cc: Michael Dexter Subject: RFC: linking with --no-undefined-version Message-ID: List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline As of LLVM 16, lld default to --no-undefined-version which means that if a symbol is listed in the symbol version map it must be present or lld will fail to link. This is good because it prevents that accidental loss of symbols which breaks our ABI compatibility. Unfortunately, it's somewhat complicating because our symbol version maps may vary per-architecture or based on options. As a result we added --undefined-version to LDFLAGS. In the process of validating my libsys work I decided I wanted to enable this option to make sure I wasn't losing symbols along the way. I added WITH(OUT)_UNDEFINED_SYMBOLS control this behavior and worked to resolve issues in the build with WITHOUT_UNDEFINED_SYMBOLS enabled. I've got tinderbox building successfully with just a few patches outstanding. I've hung them off the following review that sets WITHOUT_UNDEFINED_SYMBOLS by default: https://reviews.freebsd.org/D44216 There are probably still some issues to be fixed with non-default options, but I'm not in a position to discover all of them. Hopefully Michael's build options survey will turn them up. They are generally easy to fix and various revisions associated with the above review provide examples. I'm looking for feedback on flipping the switch so we start detecting regressions by default. -- Brooks P.S. This isn't the complete ABI story, but it at least prevents the worst regressions. I have a first cut at something more complete (including symbol versions but short of a full ABI checker) at https://reviews.freebsd.org/D44271 From nobody Thu Apr 18 23:44:31 2024 X-Original-To: freebsd-arch@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 4VLDs42tqhz5HLX8 for ; Thu, 18 Apr 2024 23:44:40 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (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 did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4VLDs35yX2z4mj9; Thu, 18 Apr 2024 23:44:39 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Authentication-Results: mx1.freebsd.org; none Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.17.1/8.17.1) with ESMTP id 43INiVPS028488; Thu, 18 Apr 2024 16:44:31 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) DKIM-Filter: OpenDKIM Filter v2.10.3 troutmask.apl.washington.edu 43INiVPS028488 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=troutmask.apl.washington.edu; s=troutmask; t=1713483871; bh=rSK6USDa0WMXZ+31t/kGf36h0AgCveHU3mkWmlzQ94w=; h=Date:From:To:Cc:Subject:Reply-To:References:In-Reply-To:From; b=Gjed5Jr0+3AS1d9YY8I7EA39SnD/1ON5CSmBr8r2EePsPPYxD536g2Jq+NEHGtdb4 OEyf3P7E2OUcmp3YQUFdyUL+75w8EEwzXGjr17NHSSTDZW/c/jB8r+h9kNW4SBeOx3 fOEx83ioyA2Iid3fWuoL6/SJpp1bKStOtTkL3Z5ZEWlhnE3DCC9HC7IEbu1M0tBfEm Tb/hugHOaZcmGLa7NL+tgcBvvcrm/D3l63ui0HDWkf0D6Ug5HyToJGtet3yiVcthmQ EMW9MtT4sY/8ctRgsnePLtefkrxmqzB494nmtlMscKXbJ/xX5C46PbKKnzEcG08a64 S/ejTtKlTGsCQ== Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.17.1/8.17.1/Submit) id 43INiVcB028487; Thu, 18 Apr 2024 16:44:31 -0700 (PDT) (envelope-from sgk) Date: Thu, 18 Apr 2024 16:44:31 -0700 From: Steve Kargl To: Brooks Davis Cc: freebsd-arch@freebsd.org, Michael Dexter Subject: Re: RFC: linking with --no-undefined-version Message-ID: Reply-To: sgk@troutmask.apl.washington.edu References: List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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:73, ipnet:128.95.0.0/16, country:US] X-Rspamd-Queue-Id: 4VLDs35yX2z4mj9 On Thu, Apr 18, 2024 at 11:35:19PM +0000, Brooks Davis wrote: > As of LLVM 16, lld default to --no-undefined-version which means that if > a symbol is listed in the symbol version map it must be present or lld > will fail to link. This is good because it prevents that accidental loss > of symbols which breaks our ABI compatibility. Unfortunately, it's > somewhat complicating because our symbol version maps may vary > per-architecture or based on options. As a result we added > --undefined-version to LDFLAGS. > Just to be clear, does this extend into /usr/ports? I only have 3020 *.so in /usr/local/lib. I can image that some software package may have missing symbols. -- Steve From nobody Thu Apr 18 23:49:48 2024 X-Original-To: freebsd-arch@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 4VLDz06y6tz5HLbJ for ; Thu, 18 Apr 2024 23:49:48 +0000 (UTC) (envelope-from brooks@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 4VLDz06KLlz4nfm; Thu, 18 Apr 2024 23:49:48 +0000 (UTC) (envelope-from brooks@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1713484188; 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: in-reply-to:in-reply-to:references:references; bh=oAXsEmPpqV0z5/JGHgemb/GmzzAMoqef3JVDfwY+HAQ=; b=hZkGNB2yntYT8sUS0CafzoFPRRZI5bC967BegjEcYdBRT/GXmZ3QP2ngiLB16yhiefTve6 YLVTkKVW4VYE87drLtUl0MUreeyPJV9YxmIVpy19ZVZGbJS73Ky2JYxZ/wZ7TmgDjewxng FnAlQDAIPf1IRGq5rUYCCqLaGWrvkEfPlNelpGZIbd2pjsRR5/OCsukNqJrQ8mW7BpZk1Z FRAjB/PjRIkourc/dtkjoRGMhZY8r1B0KchI5lgmqFls39RgbJwOrSadwGkW/JiAD/nnUU DCF2jOSqDr9F/zHexxkXNCFrd/b4U3Cr9zNT8EEcaAk3waFndkC5kPKnNuOOUQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1713484188; a=rsa-sha256; cv=none; b=ELhBTUaSl82NDaw8dDI70iWF8RobJUkUQ5QrtHpMXeDgsKQSGiTOgl78NiagHffkak4ql9 vuHSSP0AaBwZoVfCXObN15F8KxRhqHF1BggvT/XA9OjnzsldupQ/CQxOVKgn95wVSYU8Ft XDgk0cxLsocvwsuYfH0YNxob23Lg7dGITkV41bka4LIm21Mcsz/J1kzZvOs38mCJiJZyEA tBwKcR+Rz63xEgMPYiTi1/b5Mi4fQg6tAthwtWNCGOAZgtK6Qc6ctoixLaSiHtK9HF/s22 KYHJRe3GFO3NxEkbCMypDtCKRN097My+tZiVBN1mOyuQRk4oRO4KVL2qbhOKZA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1713484188; 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: in-reply-to:in-reply-to:references:references; bh=oAXsEmPpqV0z5/JGHgemb/GmzzAMoqef3JVDfwY+HAQ=; b=fvL9iZ6i2BpTvRmarA0Q54HsdYqI7nxPHaEI6pYSc0AwNZdIx3cBTNG/4ojBbSzoza7SGB bCfXeEMhStbPXir+mTYPRJjUKXxUX9jsiQl0pitQQd2L+3Zn5ljD02vre6+kv2zH0qzPVV QBg8TUKqwywMV9+Rc5lbpOqjDkoheAhiWzzqSn0itD5VTyAEbb9axpfO9vuL0Ojy+5Qq7Z cGUFi8dLoITee+tVXO5/5UOtFJFBitDuWDmsOyslWFnpHAPhbBmb1wMHm+UTWIAb6zrcsD wxGE9PAA8U+qIYUwZiMoZuli81BNvJztZfOxm5FGk7ZAjOjB2fjQmpF6NavlIA== Received: from spindle.one-eyed-alien.net (spindle.one-eyed-alien.net [199.48.129.229]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) (Authenticated sender: brooks/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4VLDz05cK6zKV7; Thu, 18 Apr 2024 23:49:48 +0000 (UTC) (envelope-from brooks@freebsd.org) Received: by spindle.one-eyed-alien.net (Postfix, from userid 3001) id 7EFB73C019B; Thu, 18 Apr 2024 23:49:48 +0000 (UTC) Date: Thu, 18 Apr 2024 23:49:48 +0000 From: Brooks Davis To: Steve Kargl Cc: freebsd-arch@freebsd.org, Michael Dexter Subject: Re: RFC: linking with --no-undefined-version Message-ID: References: List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: On Thu, Apr 18, 2024 at 04:44:31PM -0700, Steve Kargl wrote: > On Thu, Apr 18, 2024 at 11:35:19PM +0000, Brooks Davis wrote: > > As of LLVM 16, lld default to --no-undefined-version which means that if > > a symbol is listed in the symbol version map it must be present or lld > > will fail to link. This is good because it prevents that accidental loss > > of symbols which breaks our ABI compatibility. Unfortunately, it's > > somewhat complicating because our symbol version maps may vary > > per-architecture or based on options. As a result we added > > --undefined-version to LDFLAGS. > > > > Just to be clear, does this extend into /usr/ports? I only have 3020 *.so > in /usr/local/lib. I can image that some software package may have > missing symbols. Just the base system and things that use bmake infrastructure from base (e.g., programs that got kicked out of base like ftpd), but dim@ already fixed lots of symbol files in ports so I don't expect major issues. -- Brooks From nobody Fri Apr 19 00:00:41 2024 X-Original-To: freebsd-arch@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 4VLFCd3LFtz5HMY4 for ; Fri, 19 Apr 2024 00:00:45 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (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 did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4VLFCd27tFz4pf7; Fri, 19 Apr 2024 00:00:44 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Authentication-Results: mx1.freebsd.org; none Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.17.1/8.17.1) with ESMTP id 43J00g1m028650; Thu, 18 Apr 2024 17:00:42 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) DKIM-Filter: OpenDKIM Filter v2.10.3 troutmask.apl.washington.edu 43J00g1m028650 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=troutmask.apl.washington.edu; s=troutmask; t=1713484842; bh=MKqBbeTb5KBCJGOjv3a9jm49YavHaQFKkpilLMMTmvg=; h=Date:From:To:Cc:Subject:Reply-To:References:In-Reply-To:From; b=kXZHD/MYgdQDG8iDFMsg4B3yYy+yzxlPE5i6bJYT7LcAlFe3YGSHt1YFs5x0YSppe Ncw66jxWceDipdD8AOhKonQmLw1b0uGnsxLHnMoWIuQpANKzk9It/3sNIWcNAbfRX1 rzkJXEosoAGxlC7auuqyJ7vxdZUTTgdTgX45VB/BMeyWXtuTc8W3GB/0OOpsrAvFTa uf2egohuUEC2PJBnU+y89m5f36hrT2gDsciFlkchFL9bDc3AfCmxetq/MwVFBbCueD C1l0Oplyq1O7aJvvYs1xdDt59cN4gj4rfXRqC3WZRuOBVQGaXgPKHYev1A8rieXweP +RzmP85T47V7w== Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.17.1/8.17.1/Submit) id 43J00fJ4028649; Thu, 18 Apr 2024 17:00:41 -0700 (PDT) (envelope-from sgk) Date: Thu, 18 Apr 2024 17:00:41 -0700 From: Steve Kargl To: Brooks Davis Cc: freebsd-arch@freebsd.org, Michael Dexter Subject: Re: RFC: linking with --no-undefined-version Message-ID: Reply-To: sgk@troutmask.apl.washington.edu References: List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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:73, ipnet:128.95.0.0/16, country:US] X-Rspamd-Queue-Id: 4VLFCd27tFz4pf7 On Thu, Apr 18, 2024 at 11:49:48PM +0000, Brooks Davis wrote: > On Thu, Apr 18, 2024 at 04:44:31PM -0700, Steve Kargl wrote: > > On Thu, Apr 18, 2024 at 11:35:19PM +0000, Brooks Davis wrote: > > > As of LLVM 16, lld default to --no-undefined-version which means that if > > > a symbol is listed in the symbol version map it must be present or lld > > > will fail to link. This is good because it prevents that accidental loss > > > of symbols which breaks our ABI compatibility. Unfortunately, it's > > > somewhat complicating because our symbol version maps may vary > > > per-architecture or based on options. As a result we added > > > --undefined-version to LDFLAGS. > > > > > > > Just to be clear, does this extend into /usr/ports? I only have 3020 *.so > > in /usr/local/lib. I can image that some software package may have > > missing symbols. > > Just the base system and things that use bmake infrastructure from base > (e.g., programs that got kicked out of base like ftpd), but dim@ already > fixed lots of symbol files in ports so I don't expect major issues. > Thanks for the clarification. Looks like a beneficial change. PS: Thanks for the work on libsys. -- Steve From nobody Sat Apr 20 01:22:42 2024 X-Original-To: arch@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 4VLv014SMbz58ysc for ; Sat, 20 Apr 2024 01:22:57 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-lf1-f43.google.com (mail-lf1-f43.google.com [209.85.167.43]) (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 4VLv006c8Vz4h5F for ; Sat, 20 Apr 2024 01:22:56 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=freebsd.org (policy=none); spf=pass (mx1.freebsd.org: domain of carpeddiem@gmail.com designates 209.85.167.43 as permitted sender) smtp.mailfrom=carpeddiem@gmail.com Received: by mail-lf1-f43.google.com with SMTP id 2adb3069b0e04-51ab47ce811so1838777e87.1 for ; Fri, 19 Apr 2024 18:22:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1713576175; x=1714180975; 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=wCHnSuwobVzNE60gIZ8y66wLzUmzkkTcJvQzEEYyxJA=; b=AsACEbsVNSBbd1YWXZTuOIS/U2JBq4pImQ8RD67nDR8maQAh7GKUJTT73aZDVQkrnJ kVBVyCBbSAKbICO7yr5wn1K1IGYhz64iWvC6AgMoUsMQxAHE96ylEVD8v/U15DwyJj6z dvLmRMsg7uuJ8s195d5FB16F69CjOoCZnrqI/J+DKlJb4sGmwU8O4L0uNkWkMIhutuyN mx0Dt7ClirdKpmnK3B+oJuG5xqbU13BRJf5C1gbhFgiHezzxCuJlaP9WI11MDpih+HRC Q0zMHjUeVnKrrGwkdpxkLi2id4kslLFabo41liw7hAll35CFzC0lPksFud+g4IGujm4y oMEw== X-Gm-Message-State: AOJu0YyqCOfKGK9OdFrU2JpHWIbW88mwMTavLUZ9AuLs/6qiE2H/Gt1B fE5ursOTSr4ZfK43kLsMoKJoND+HxpMsLxHiUkvNMoKrJJVNfuofanZGLByeZvKdIH8XdIKpeT0 hPIBowoqlSyT9LvEyvfateHtBrVh2UQ== X-Google-Smtp-Source: AGHT+IGo7SetabidhicPDQZ2F26i1tSQb1bqtIWro/X4rIRKGopA8X6ExJIetK6DA0dT2Fo2ra0tleHJ09+3ndlw3mI= X-Received: by 2002:ac2:5d50:0:b0:51a:cafd:3830 with SMTP id w16-20020ac25d50000000b0051acafd3830mr1577917lfd.7.1713576174599; Fri, 19 Apr 2024 18:22:54 -0700 (PDT) List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@FreeBSD.org MIME-Version: 1.0 References: In-Reply-To: From: Ed Maste Date: Fri, 19 Apr 2024 21:22:42 -0400 Message-ID: Subject: Re: mailwrapper behaviour if mailer.conf can't be opened To: Lexi Winter Cc: arch@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.83 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.93)[-0.935]; FORGED_SENDER(0.30)[emaste@freebsd.org,carpeddiem@gmail.com]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17:c]; MIME_GOOD(-0.10)[text/plain]; DMARC_POLICY_SOFTFAIL(0.10)[freebsd.org : SPF not aligned (relaxed), No valid DKIM,none]; ARC_NA(0.00)[]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FREEFALL_USER(0.00)[carpeddiem]; TO_DN_SOME(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; RCVD_COUNT_ONE(0.00)[1]; RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.167.43:from]; RCPT_COUNT_TWO(0.00)[2]; R_DKIM_NA(0.00)[]; FROM_NEQ_ENVFROM(0.00)[emaste@freebsd.org,carpeddiem@gmail.com]; FROM_HAS_DN(0.00)[]; MISSING_XM_UA(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_TLS_LAST(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[arch@freebsd.org]; MLMMJ_DEST(0.00)[arch@freebsd.org]; RCVD_IN_DNSWL_NONE(0.00)[209.85.167.43:from] X-Rspamd-Queue-Id: 4VLv006c8Vz4h5F On Thu, 18 Apr 2024 at 13:24, Lexi Winter wrote: > > i submitted this change request: > > https://github.com/freebsd/freebsd-src/pull/969 Mark, Warner and I discussed this today and we agree with the arguments you made. One thing I think we should still do is describe the behaviour in mailwrapper(8), indicating that we fall back to the default MTA if mailer.conf does not exist. From nobody Sat Apr 20 13:46:33 2024 X-Original-To: arch@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 4VMCVK0xllz5HpJ2 for ; Sat, 20 Apr 2024 13:46:49 +0000 (UTC) (envelope-from lexi@le-fay.org) Received: from fuchsia.eden.le-Fay.ORG (fuchsia.eden.le-fay.org [81.187.47.195]) by mx1.freebsd.org (Postfix) with ESMTP id 4VMCVJ5qG6z4P2l; Sat, 20 Apr 2024 13:46:48 +0000 (UTC) (envelope-from lexi@le-fay.org) Authentication-Results: mx1.freebsd.org; none Received: from iris.eden.le-Fay.ORG (iris.eden.le-fay.org [IPv6:2001:8b0:aab5:106:3::6]) by fuchsia.eden.le-Fay.ORG (Postfix) with ESMTP id B5AC49436; Sat, 20 Apr 2024 13:46:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=le-fay.org; s=fuchsia; t=1713620799; bh=GgfGWh5WfKZyShHyqGb/LvGhdaddTncUf8fILZyAeCs=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=RdQ0Q9RicLyQ6q2uOqu3vwVZ0G/n+hwsI9X4dI+N+ovIkE9VWlXO67rU+bJszxExT z6/VYJIXlAw1ah0XNUH3DZtQwiJgVw+lJNsHu5Ha8OAkIkDW2Zpqgq/98dF/JbkHPz QxGodIfnp1Fj09bsZY9qph4RYh7i0vlfhvP/T+sI= Received: from ilythia.eden.le-fay.org (ilythia.eden.le-fay.org [IPv6:2001:8b0:aab5:106:3::10]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (secp384r1) server-digest SHA384) (No client certificate requested) by iris.eden.le-Fay.ORG (Postfix) with ESMTPSA id 20E8A2C0416; Sat, 20 Apr 2024 14:46:39 +0100 (BST) Date: Sat, 20 Apr 2024 14:46:33 +0100 From: Lexi Winter To: Ed Maste Cc: arch@freebsd.org Subject: Re: mailwrapper behaviour if mailer.conf can't be opened Message-ID: References: List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@FreeBSD.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="1UIgcB68cdbNpXY2" Content-Disposition: inline In-Reply-To: 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:20712, ipnet:81.187.0.0/16, country:GB] X-Rspamd-Queue-Id: 4VMCVJ5qG6z4P2l --1UIgcB68cdbNpXY2 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Ed Maste: > Mark, Warner and I discussed this today and we agree with the > arguments you made. One thing I think we should still do is describe > the behaviour in mailwrapper(8), indicating that we fall back to the > default MTA if mailer.conf does not exist. that seems reasonable; i see this is already merged, but i'll submit another PR for the manpage update. (please prod me about that if i forget!) --1UIgcB68cdbNpXY2 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGzBAABCAAdFiEEuwt6MaPcv/+Mo+ftDHqbqZ41x5kFAmYjxzcACgkQDHqbqZ41 x5lPMQv/SE17y+yViFqLb2ZNinE1HFj2mMONV7N1VS3UugjCLVT1ry7+7mPZzlve 0XgMYebjlS984McgaDqG9iTgm+jFyw0+PlS3FdkUbVUh26EPlhpgN9MAF2Bl3sK8 ukFi3tg+llZ3fdK+Vl3qD/tgI0/7eQhJVYNLOq0rlp5M1/Iz5HXywpMlPsBvq8si q6ceMKqSCN9ZEvoBdrWovz5ap9W1T1pBjsfskKSU7DWjaf+RDs0ARjmUHOp6v6Iw jN+XduFd0Dp76sHTMwbUaHJYj0/qptKwiqASw1YD3PPxLndjFVOtF+inPjXmD6Ck Wq0vaF0mjGtVNZJ2K0Lcoy5SPxZ2MFphMoNQdT45CGl5IwuRK7LrkEy5vbis7kPt 1+lfog6ZhxClqMNeNQ0iJkvYBPm1n6GgNdX9Vr/kO5y8w+56MOEOxw3U8WOtFYfv /yv55zonUyBWBTwDIsXOmVvPQhPU5CmrGfhz1Lc5Yo2sRU6CMvSy5EgKxXyD68g0 Fsl/PISW =N8Aj -----END PGP SIGNATURE----- --1UIgcB68cdbNpXY2--