From nobody Mon May 13 02:11: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 4Vd2zb5fpSz5JygR for ; Mon, 13 May 2024 02:11:39 +0000 (UTC) (envelope-from philip@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 4Vd2zb5Ddwz44X0; Mon, 13 May 2024 02:11:39 +0000 (UTC) (envelope-from philip@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1715566299; 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=e1bD70vl+N+ed2SHluY43FvbkeEnszH20wIDzTYPEIQ=; b=JYjc/nbjRI+JBtcMSamEUJ7Cdd2E+qmTaIbS3b21LsD0f67f/69Hj3IMFZcMtJ1U4hCoTo iX+5ihPUmjly6TMqeldqJkgL4XUi6OkIrU4MjBub3ksyla4wPj+lnkqHvPP3EmrGtxCzw4 3iHSqIl7yaCvtRj7KqnZpiOXpj6n4jw5NRAkj6Yebie9uS5njVDi5rq66zPZ1iPuyLyHga D2UNStb7yJQx6AspARCSOBHi5yf+v4sK3ulqfH+ZVevhO65awGt1mPx7EjMm8HU+FSOO9f TeGGQ3eUlQXXyYE2AC5FeTQgkkRzMucM8k1+St+cWYfd4saPBis4i+NA97GOVg== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1715566299; a=rsa-sha256; cv=none; b=Ds3saaSgIEeQZcn7ii+BAlVqEn8Yqi3tWeofXiTVuHFXTHG6eUBf77rqKeT2ZQca7j9GoH NFIjlclOBniXEUE9TUIAuLzU2zf+Onls7vVoh/wLAecYkJ3KX+xC+S6gj/ewziayP5Otzz 2/frOdgnqPx0LUvLnj0CpkSKWddB6IZDmKzn+Tn2A68gf++dWo6I6h0MsW6cbJOGWZlElX zKtTvY+lDXlA4croDEE98YMvQFhEGKiz6NYeX0Ddk4Z4YKpRMiwjkDxMok6SHmsXAYV/t3 Yrrla/xgLonYxXwmyS1rIQkxom1Y87/s5OaqIVX+7ucb1j3KfIr372sXibcJtQ== 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=1715566299; 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=e1bD70vl+N+ed2SHluY43FvbkeEnszH20wIDzTYPEIQ=; b=FhfXVG0yn3fffnoZjqBpOW/4sMarZrVcY8Rqw6xUvlgE8km/BBOW4JtJufNzNTQyoUm+eE 0FlDpzMdRZWAZnphVGP+MhB1iLHyK+jI5j3QZvx54nyAHA9gXeC55tsteC05qThskM+WMn xgcizEt2zznLUhxkFwlqK8T0mvKerulDz+nUua9KziofJ2sfQoC8A6B6z7iOVlUfqXDSOc scke+sJxoMCCFnVfVfwqJIKkhxaHyq12gFqneIf4iogAlini92DAzn7nAtyj515oeGZblS X6/bjJvSskVMVFaOIIuBppXexQAboO8Pl9l0dVmVfgij/1bvucCwazN3hHzmxA== Received: from fauth2-smtp.messagingengine.com (fauth2-smtp.messagingengine.com [103.168.172.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 did not present a certificate) (Authenticated sender: philip/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4Vd2zb41mSz1F10; Mon, 13 May 2024 02:11:39 +0000 (UTC) (envelope-from philip@freebsd.org) Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailfauth.nyi.internal (Postfix) with ESMTP id 266ED1200066; Sun, 12 May 2024 22:11:39 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Sun, 12 May 2024 22:11:39 -0400 X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledrvdegfedgheehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvvefufffokfgjfhggtgesthdtmhdtredttdenucfhrhhomheprfhhihhl ihhpucfrrggvphhsuceophhhihhlihhpsehfrhgvvggsshgurdhorhhgqeenucggtffrrg htthgvrhhnpeeukefhkedtfeffieduhffgieevtddukefgfeeufefggfelhfduhfdvgfel veeggfenucffohhmrghinhepfhhrvggvsghsugdrohhrghdpghhithhhuhgsrdgtohhmne cuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepphhhihhl ihhpodhmvghsmhhtphgruhhthhhpvghrshhonhgrlhhithihqdduudeiiedviedvgeekqd dvfeehudektddtkedqphhhihhlihhppeepfhhrvggvsghsugdrohhrghesthhrohhusghl vgdrihhs X-ME-Proxy: Feedback-ID: ia691475d:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sun, 12 May 2024 22:11:37 -0400 (EDT) From: Philip Paeps To: henrichhartzer@tuta.io Cc: Freebsd Arch Subject: Re: Disabling COMPAT_FREEBSD4/5/6/7/9 in default kernel configurations Date: Mon, 13 May 2024 10:11:31 +0800 X-Mailer: MailMate (1.14r6030) Message-ID: <990315F7-098D-4AE5-8F3B-7B6732F1275F@freebsd.org> 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; format=flowed On 2024-05-11 07:38:38 (+0800), henrichhartzer@tuta.io wrote: > Warner suggested that I run this by the list. In 2018, a bug report > was made for disabling COMPAT_FREEBSD4/5/6/7/9 (there's no 8). 6 years > later, I imagine this would be as good of a time as any to do this if > there's no obvious problems doing so. > > Here's the bug report: > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=231768 > > And a pull request in the spirit of the original patch: > https://github.com/freebsd/freebsd-src/pull/1228 > > I imagine if this sounds like a good idea, it would land in 15.0. > Users could always recompile kernels with the old ABI functionality as > needed. I feel like we're all a little curious if anything still uses > this, and making this kind of change is probably the best way to find > out. I think this is a terrible idea. Removing things to find out what breaks is not the way we do things in FreeBSD. Users who don't care about compatibility can build their own kernels. Many users do. Our defaults however should be backwards compatible. > Appreciate any feedback on this and hopefully we can reach some kind > of consensus on how to proceed in 2024. One of the things users like about FreeBSD is our backwards compatibility. What's wrong with being able to run old software without having to fight? Philip From nobody Mon May 13 11:28:43 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 4VdHLt723Vz5K33M for ; Mon, 13 May 2024 11:29:10 +0000 (UTC) (envelope-from janm@transactionware.com) Received: from mail3.transactionware.com (mail.transactionware.com [203.14.245.7]) by mx1.freebsd.org (Postfix) with SMTP id 4VdHLs0k0xz4qkk for ; Mon, 13 May 2024 11:29:08 +0000 (UTC) (envelope-from janm@transactionware.com) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of janm@transactionware.com designates 203.14.245.7 as permitted sender) smtp.mailfrom=janm@transactionware.com Received: (qmail 47824 invoked by uid 907); 13 May 2024 11:29:00 -0000 Received: from i5E86AEB1.versanet.de (HELO smtpclient.apple) (94.134.174.177) (smtp-auth username janm, mechanism plain) by mail3.transactionware.com (qpsmtpd/0.84) with (ECDHE-RSA-AES256-GCM-SHA384 encrypted) ESMTPSA; Mon, 13 May 2024 21:29:00 +1000 Content-Type: text/plain; charset=utf-8 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: Disabling COMPAT_FREEBSD4/5/6/7/9 in default kernel configurations From: Jan Martin Mikkelsen In-Reply-To: Date: Mon, 13 May 2024 13:28:43 +0200 Cc: Freebsd Arch Content-Transfer-Encoding: quoted-printable Message-Id: References: To: henrichhartzer@tuta.io X-Mailer: Apple Mail (2.3774.500.171.1.1) X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.69 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.990]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ip4:203.14.245.0/24]; MIME_GOOD(-0.10)[text/plain]; RCVD_NO_TLS_LAST(0.10)[]; ASN(0.00)[asn:17559, ipnet:203.14.245.0/24, country:AU]; MIME_TRACE(0.00)[0:+]; TO_DN_SOME(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_COUNT_ONE(0.00)[1]; ARC_NA(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; R_DKIM_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MLMMJ_DEST(0.00)[freebsd-arch@freebsd.org]; DMARC_NA(0.00)[transactionware.com]; FROM_HAS_DN(0.00)[] X-Rspamd-Queue-Id: 4VdHLs0k0xz4qkk > On 11. May 2024, at 01:38, henrichhartzer@tuta.io wrote: > In my opinion, if all goes well, it may be wise to remove the old code = in the next major version. Could do the full list, or just FreeBSD 4 and = 5 compatibility, for instance. Barring notable negative feedback, of = course. There are many reasons for running old binaries. Removing old code is = obviously a Bad Idea=E2=84=A2. For example, the last FreeBSD version of p4d (the Perforce server) is = compiled for FreeBSD 10. I know there have been cases where I have found = it useful to run old binaries for many different reasons. Regards, Jan M. From nobody Mon May 13 16:59:34 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 4VdQh82dmJz5KcFd for ; Mon, 13 May 2024 16:59:36 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (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 4VdQh81xGnz4J54; Mon, 13 May 2024 16:59:36 +0000 (UTC) (envelope-from jhb@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1715619576; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=e6N7tT3LFUzywj6OvRIUwkU+llk4ZxyilRhBqZBvySE=; b=dpicXYjJv5uU4HD1RTvAcoCVnQT0MHN/e1vWZY6I1L00orNar0UczOvdDAyv9vusxFKbPR rGLSdvr/DLzSfE1tV6Ti8pK/k+bGO5qA/2dIPD3foQE+R8u1vqf2/lLnctjSTOS4Lo5cgI /e0lrS8nZhzG53kLF8XCiPFAzMlNyNYIUHsSIU8SSP0gymHdN/LpBM5Os8uHFSyruGT0m3 Tw7c5i5X8fAJ9mpMLgYp2YKw5A/aoeE87ry6++VyjIg78WSAQxoo6/wnCtJonVzTmL9Lb8 JzNA1leRR68PwYs9IZkgtqNxlIK2zbWFG28JSSef/EU6r+yZSt39R8/DDdq6rQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1715619576; a=rsa-sha256; cv=none; b=Mw7VE9JJ78E2jMBZRNV3iwsc88hq9BJ83XBsjEWhci5T0esddVBLqnBG1XsEvQXFdNwwDM GjTHGe6skb/SzmeX0BuErzIQhV3MhHqTm9eZcUPbIf8Tc4ASfy8lOpxL9yTYbVvPcrPKfU yv5b+kmPdkZh2YbsHZsD9Vqyd1piNgAa4epgMbUIFCketMizkfR3eFuUVv/kHJjIqmHZad RWwaZ6dCfMkhICXRLq36aV5REHJIshFJYHiUkiHDCqoEVOKf1ad/mN4GHhzjpf5F4+TSKq wRUrXd+UFlT7n2ENDxlLSXYBjiVOzmWAEuZMkb5+ROKhLHSksiO1Bl90QsOtaw== 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=1715619576; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=e6N7tT3LFUzywj6OvRIUwkU+llk4ZxyilRhBqZBvySE=; b=aKJ2/xmsyiPUUmp5xnQRhYGc1EX1vCAIgcN47LnF81BuV+SO8sIk99RTprdXTcXbMIEU9K nG16iI4MjH6VLu10Mn6gyp/QY9NaUvsIPBaknzJS9TQ3pA12BSfYPbCMryY3JvXAWLv44o iXylof5tydLNg8DYEMa5icWQKQkhSpllKpeXDSd2sx6iqgL+dRxr1yWVjzM69uJSZBo7h1 bPFpLrnnEHzhwNVSIAONqGKATm+hwFDjlhramVfChBKZfKJe2850Qj5sGIF8TF3CTBCoWL DBfdyq7+UgduccC0ph8X49K8KYXy9S3cc2cDZ1XtmepRdeubYqu607W50KQfCg== Received: from [IPV6:2601:644:937f:4c50:2061:c930:d4a1:6767] (unknown [IPv6:2601:644:937f:4c50:2061:c930:d4a1:6767]) (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) (Authenticated sender: jhb) by smtp.freebsd.org (Postfix) with ESMTPSA id 4VdQh75H1TzJxr; Mon, 13 May 2024 16:59:35 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Message-ID: <1d4afad4-250b-4c1c-8206-279a92a26ae4@FreeBSD.org> Date: Mon, 13 May 2024 09:59:34 -0700 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: Disabling COMPAT_FREEBSD4/5/6/7/9 in default kernel configurations Content-Language: en-US To: Warner Losh , Konstantin Belousov Cc: henrichhartzer@tuta.io, Freebsd Arch References: From: John Baldwin In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 5/11/24 7:01 AM, Warner Losh wrote: > On Sat, May 11, 2024, 3:19 AM Konstantin Belousov > wrote: > >> On Sat, May 11, 2024 at 01:38:38AM +0200, henrichhartzer@tuta.io wrote: >>> In my opinion, if all goes well, it may be wise to remove the old code >> in the next major version. Could do the full list, or just FreeBSD 4 and 5 >> compatibility, for instance. Barring notable negative feedback, of course. >> >> Strongly disagree. You are breaking ABI compat for users, for what gain? >> >> I do not care about disabling options in GENERIC (but then they must appear >> in LINT). >> > > > This sums up my view as well. Fine to not be in GENERIC, but removal is a > bridge too far. Same here. However, what I haven't really seen anywhere in this thread is a clear articulation for _why_ to remove these options for GENERIC. The reasons I can think of for removing from GENERIC are: 1) Shrinking the size of .text in GENERIC. GENERIC is not MINIMAL, but it is also not KITCHENSINK. While there is some binary-only software around that requires older versions, I strongly suspect that it is a rare use case and requiring a custom kernel is not too large of an imposition on users who need that. 2) Reducing the attack surface available via system calls (which is what COMPAT_FREEBSD is mostly about). I suspect that the theoretical surface here is larger than the practical one, but it's not zero. If there are in fact binary-only programs built against older releases that are widely used, then that might be a counter balance to the range of options removed from GENERIC. I think though that just removing from GENERIC does not mean we should axe the ports. misc/compatN need to stick around for the options to still work in a custom kernel, and they are very cheap to build (just tarring up binaries). Also, converting COMPAT_FREEBSD to modules is non-trivial. -- John Baldwin From nobody Mon May 13 17:21:23 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 4VdR9J09ygz5Kf9X for ; Mon, 13 May 2024 17:21:24 +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 4VdR9H6rgjz4L5Y; Mon, 13 May 2024 17:21:23 +0000 (UTC) (envelope-from brooks@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1715620884; 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=myZKxGvx796XyqYEpbm+sBIjBei2s6pqZampk5bU+dw=; b=bwB6uZZ1cAPMlxWRHduNWjKPkrWkbxDrSZj0cPOO+xPinrNNyosCqG/Z2Yv9NhL6KIFk3t Z6hcYGvR6gdMmtYj6jI5X3yPlb/Ic4sRqDZislCkmIhQRkMu0ZCAOzE2AdFMX8A+qW+3r3 NIPhBVog2msKrmkrPca8yVjuWNp0btt06Fnsq7GMQrJ8B1MT9YvB2GQr70QZHbjngSQmtO k1CCDPgS4AfqdmrtcqYw+o46NwB3A0fE9TwZYWcvrGbWHrgmJc4Rg6aGWVjcxIh1NAFikb BqjCF7CjZxV2GmsLFiFGAs9N5+mm6fstWbPXVexCETthEj7Lz7v2d9KE9EqjKw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1715620884; a=rsa-sha256; cv=none; b=TCUIiIFQvd27pjBJscDXLKD6z+jzCxhAmwEmDvSOaPCa0mud2CzLpptwISxjO8z/9FhBda oBe848VcyNaajj8kDxrA39YnatvTl1JmPmSfgh2G1NuEBJvPA2Nct76P8uSICe0WvHXFSO GUFRChYLlRnjNjk75MTw2+519/Hc0wksZZCjg8h+nW12LCca04C7R5vMDzWW/rm7xSEdYC OS8NY945IglLNtEF9h5RNpxwHAripFLRQU8xKBciLasDbzdluRvovy7tBJu3ucmRR8dhKk WaZuIKzIW+GV5L0OhcUbK88FIwhTK7GmwcjktUWCKD8GlGb5GQN9PGZ4WZoJyw== 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=1715620884; 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=myZKxGvx796XyqYEpbm+sBIjBei2s6pqZampk5bU+dw=; b=j2uYCWRvxPEYp5od2vLjbptC8fd21cSnZWSJ0cJLrOkpF3rZ2FE0k5NnHXefau7/5/hfXT w008RfKzwh2Sv7NuLASPX/RpnE4NSYUcmPQ60QtPK5T8NmDxtnrhEKbjbJVa/sRATPicNc La6lsBFih0izwEsDGX1vZCA2SF3PrY057C+oYT6b3VJaq2h7zbk64LBm2FyQfPhCGD0KKP jRe+cmWVq/HYqVo6Buwp0KpKFhhYpB4NjhJ56Ey4xcJK+MQ69eVYVoYo2qM6SOOstoSOeK OhI35ig2XSEbs3jXJmlbXsYbLi0mbgLWo/oWS7sz+20y73wKQ3GjGOHFixcieA== 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 4VdR9H6H7BzJbr; Mon, 13 May 2024 17:21:23 +0000 (UTC) (envelope-from brooks@freebsd.org) Received: by spindle.one-eyed-alien.net (Postfix, from userid 3001) id 8667C3C019B; Mon, 13 May 2024 17:21:23 +0000 (UTC) Date: Mon, 13 May 2024 17:21:23 +0000 From: Brooks Davis To: John Baldwin Cc: Warner Losh , Konstantin Belousov , henrichhartzer@tuta.io, Freebsd Arch Subject: Re: Disabling COMPAT_FREEBSD4/5/6/7/9 in default kernel configurations Message-ID: References: <1d4afad4-250b-4c1c-8206-279a92a26ae4@FreeBSD.org> 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: <1d4afad4-250b-4c1c-8206-279a92a26ae4@FreeBSD.org> On Mon, May 13, 2024 at 09:59:34AM -0700, John Baldwin wrote: > On 5/11/24 7:01 AM, Warner Losh wrote: > > On Sat, May 11, 2024, 3:19???AM Konstantin Belousov > > wrote: > > > > > On Sat, May 11, 2024 at 01:38:38AM +0200, henrichhartzer@tuta.io wrote: > > > > In my opinion, if all goes well, it may be wise to remove the old code > > > in the next major version. Could do the full list, or just FreeBSD 4 and 5 > > > compatibility, for instance. Barring notable negative feedback, of course. > > > > > > Strongly disagree. You are breaking ABI compat for users, for what gain? > > > > > > I do not care about disabling options in GENERIC (but then they must appear > > > in LINT). > > > > > > > > > This sums up my view as well. Fine to not be in GENERIC, but removal is a > > bridge too far. > > Same here. > > However, what I haven't really seen anywhere in this thread is a clear > articulation for _why_ to remove these options for GENERIC. The reasons I > can think of for removing from GENERIC are: > > 1) Shrinking the size of .text in GENERIC. GENERIC is not MINIMAL, but it > is also not KITCHENSINK. While there is some binary-only software around > that requires older versions, I strongly suspect that it is a rare use > case and requiring a custom kernel is not too large of an imposition on > users who need that. I worry a bit that we'll see breakage if we don't include things in GENERIC. That's especially true for the things that aren't the system call entries. > 2) Reducing the attack surface available via system calls (which is what > COMPAT_FREEBSD is mostly about). I suspect that the theoretical > surface here is larger than the practical one, but it's not zero. I think making the system calls loadable wouldn't be a huge amount of work and would limit the most obvious attack surface. For some COMPAT_FREEBSD# cases this may be all of it. Others you might need to add a COMPAT_SUPPORT_FREEBSD# which we might consider keeping in GENERIC. Making that split would help us better understand the attack surface. > If there are in fact binary-only programs built against older releases that > are widely used, then that might be a counter balance to the range of > options removed from GENERIC. > > I think though that just removing from GENERIC does not mean we should axe > the ports. misc/compatN need to stick around for the options to still work > in a custom kernel, and they are very cheap to build (just tarring up > binaries). Also, converting COMPAT_FREEBSD to modules is non-trivial. I tend to think that removing the ports has no benefit and we should keep them around. -- Brooks From nobody Mon May 13 18:23:40 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 4VdSYC6MCyz5Kkcm for ; Mon, 13 May 2024 18:23:43 +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 4VdSYC1h0Dz4VGg for ; Mon, 13 May 2024 18:23:43 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of cy.schubert@cschubert.com has no SPF policy when checking 3.97.99.33) smtp.mailfrom=cy.schubert@cschubert.com Received: from shw-obgw-4004a.ext.cloudfilter.net ([10.228.9.227]) by cmsmtp with ESMTPS id 6TQksJ5QpdrxE6aKssW2mo; Mon, 13 May 2024 18:23:42 +0000 Received: from spqr.komquats.com ([70.66.152.170]) by cmsmtp with ESMTPSA id 6aKqsO82aWhyf6aKrsAjRD; Mon, 13 May 2024 18:23:42 +0000 X-Auth-User: cschuber X-Authority-Analysis: v=2.4 cv=MenPuI/f c=1 sm=1 tr=0 ts=66425aae a=y8EK/9tc/U6QY+pUhnbtgQ==:117 a=y8EK/9tc/U6QY+pUhnbtgQ==:17 a=xqWC_Br6kY4A:10 a=IkcTkHD0fZMA:10 a=TpHVaj0NuXgA:10 a=7Qk2ozbKAAAA:8 a=pGLkceISAAAA:8 a=YxBL1-UpAAAA:8 a=6I5d2MoRAAAA:8 a=EkcXrb_YAAAA:8 a=vFlytZMyU8xvk1uq6A8A:9 a=QEXdDO2ut3YA:10 a=1lyxoWkJIXJV6VJUPhuM: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 8AE6310DB; Mon, 13 May 2024 11:23:40 -0700 (PDT) Received: from slippy (localhost [IPv6:::1]) by slippy.cwsent.com (Postfix) with ESMTP id 78F8F325; Mon, 13 May 2024 11:23:40 -0700 (PDT) Date: Mon, 13 May 2024 11:23:40 -0700 From: Cy Schubert To: Warner Losh Cc: Konstantin Belousov , henrichhartzer@tuta.io, Freebsd Arch Subject: Re: Disabling COMPAT_FREEBSD4/5/6/7/9 in default kernel configurations Message-ID: <20240513112340.64ebe859@slippy> In-Reply-To: References: Organization: KOMQUATS X-Mailer: Claws Mail 3.19.1 (GTK+ 2.24.33; amd64-portbld-freebsd15.0) 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-Transfer-Encoding: quoted-printable X-CMAE-Envelope: MS4xfHQGdjZenuqGTCSdsSugCGWXy5M//xIoI7lranjrt+a1Da4gYVYA27fQnXMk298lPsQ7wyPJn+bmif+cCy2Uwyq5zdHTamY2jJa+MXEocajORh5pTUpX d32Gv99Uqtgx08x4trb2L0tQWFTVU5OWXxSyyEoLoljOCqtZ0keVgViFv9cUHMJxq1gEqI8ES4FX0iWhfk+xNTLzmaciRqmCl52o7u6hoVgVY31dA7SPlkyq f4X+VD8J6p6c7Ap2t5rx7rSaZu8fTa1aJU4dfhLMc+O+rYu/Y0qUcR9C86cdeS3W X-Spamd-Bar: - X-Spamd-Result: default: False [-1.68 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; AUTH_NA(1.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.98)[-0.982]; MID_RHS_NOT_FQDN(0.50)[]; RCVD_IN_DNSWL_LOW(-0.10)[3.97.99.33:from]; MIME_GOOD(-0.10)[text/plain]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; ASN(0.00)[asn:16509, ipnet:3.96.0.0/15, country:US]; MIME_TRACE(0.00)[0:+]; HAS_ORG_HEADER(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_NA(0.00)[no SPF record]; MLMMJ_DEST(0.00)[freebsd-arch@freebsd.org]; RCVD_COUNT_THREE(0.00)[4]; FROM_HAS_DN(0.00)[]; FREEMAIL_CC(0.00)[gmail.com,tuta.io,freebsd.org]; R_DKIM_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DMARC_NA(0.00)[cschubert.com]; RCPT_COUNT_THREE(0.00)[4] X-Rspamd-Queue-Id: 4VdSYC1h0Dz4VGg On Sat, 11 May 2024 08:01:05 -0600 Warner Losh wrote: > On Sat, May 11, 2024, 3:19=E2=80=AFAM Konstantin Belousov > wrote: >=20 > > On Sat, May 11, 2024 at 01:38:38AM +0200, henrichhartzer@tuta.io wrote: > > > In my opinion, if all goes well, it may be wise to remove the old code > > in the next major version. Could do the full list, or just FreeBSD 4 an= d 5 > > compatibility, for instance. Barring notable negative feedback, of cour= se. > > > > Strongly disagree. You are breaking ABI compat for users, for what gai= n? > > > > I do not care about disabling options in GENERIC (but then they must ap= pear > > in LINT). > > >=20 >=20 > This sums up my view as well. Fine to not be in GENERIC, but removal is a > bridge too far. >=20 > Warner >=20 Agreed. --=20 Cheers, Cy Schubert FreeBSD UNIX: Web: https://FreeBSD.org NTP: Web: https://nwtime.org e^(i*pi)+1=3D0 From nobody Tue May 14 22:20:15 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 4Vf9lw05xrz5L6cd for ; Tue, 14 May 2024 22:20:28 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from www121.sakura.ne.jp (www121.sakura.ne.jp [153.125.133.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 4Vf9ls2yz0z4Xtw; Tue, 14 May 2024 22:20:24 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of junchoon@dec.sakura.ne.jp designates 153.125.133.21 as permitted sender) smtp.mailfrom=junchoon@dec.sakura.ne.jp Received: from kalamity.joker.local (123-1-21-232.area1b.commufa.jp [123.1.21.232]) (authenticated bits=0) by www121.sakura.ne.jp (8.17.1/8.17.1/[SAKURA-WEB]/20201212) with ESMTPA id 44EMKG01063554; Wed, 15 May 2024 07:20:16 +0900 (JST) (envelope-from junchoon@dec.sakura.ne.jp) Date: Wed, 15 May 2024 07:20:15 +0900 From: Tomoaki AOKI To: Brooks Davis Cc: John Baldwin , Warner Losh , Konstantin Belousov , henrichhartzer@tuta.io, Freebsd Arch Subject: Re: Disabling COMPAT_FREEBSD4/5/6/7/9 in default kernel configurations Message-Id: <20240515072015.cf36e92b38e22b267380318a@dec.sakura.ne.jp> In-Reply-To: References: <1d4afad4-250b-4c1c-8206-279a92a26ae4@FreeBSD.org> Organization: Junchoon corps X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd14.0) 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-Transfer-Encoding: 7bit X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.46 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.76)[-0.762]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ip4:153.125.133.16/28]; ONCE_RECEIVED(0.10)[]; MIME_GOOD(-0.10)[text/plain]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_ONE(0.00)[1]; RCVD_VIA_SMTP_AUTH(0.00)[]; HAS_ORG_HEADER(0.00)[]; ARC_NA(0.00)[]; TO_DN_SOME(0.00)[]; ASN(0.00)[asn:7684, ipnet:153.125.128.0/18, country:JP]; FREEMAIL_CC(0.00)[freebsd.org,bsdimp.com,gmail.com,tuta.io]; MID_RHS_MATCH_FROM(0.00)[]; R_DKIM_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; DMARC_NA(0.00)[sakura.ne.jp]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MLMMJ_DEST(0.00)[freebsd-arch@freebsd.org]; RCVD_TLS_LAST(0.00)[]; RCPT_COUNT_FIVE(0.00)[6] X-Rspamd-Queue-Id: 4Vf9ls2yz0z4Xtw On Mon, 13 May 2024 17:21:23 +0000 Brooks Davis wrote: > On Mon, May 13, 2024 at 09:59:34AM -0700, John Baldwin wrote: > > On 5/11/24 7:01 AM, Warner Losh wrote: > > > On Sat, May 11, 2024, 3:19???AM Konstantin Belousov > > > wrote: > > > > > > > On Sat, May 11, 2024 at 01:38:38AM +0200, henrichhartzer@tuta.io wrote: > > > > > In my opinion, if all goes well, it may be wise to remove the old code > > > > in the next major version. Could do the full list, or just FreeBSD 4 and 5 > > > > compatibility, for instance. Barring notable negative feedback, of course. > > > > > > > > Strongly disagree. You are breaking ABI compat for users, for what gain? > > > > > > > > I do not care about disabling options in GENERIC (but then they must appear > > > > in LINT). > > > > > > > > > > > > > This sums up my view as well. Fine to not be in GENERIC, but removal is a > > > bridge too far. > > > > Same here. > > > > However, what I haven't really seen anywhere in this thread is a clear > > articulation for _why_ to remove these options for GENERIC. The reasons I > > can think of for removing from GENERIC are: > > > > 1) Shrinking the size of .text in GENERIC. GENERIC is not MINIMAL, but it > > is also not KITCHENSINK. While there is some binary-only software around > > that requires older versions, I strongly suspect that it is a rare use > > case and requiring a custom kernel is not too large of an imposition on > > users who need that. > > I worry a bit that we'll see breakage if we don't include things in > GENERIC. That's especially true for the things that aren't the system > call entries. > > > 2) Reducing the attack surface available via system calls (which is what > > COMPAT_FREEBSD is mostly about). I suspect that the theoretical > > surface here is larger than the practical one, but it's not zero. > > I think making the system calls loadable wouldn't be a huge amount > of work and would limit the most obvious attack surface. For some > COMPAT_FREEBSD# cases this may be all of it. Others you might need > to add a COMPAT_SUPPORT_FREEBSD# which we might consider keeping in > GENERIC. Making that split would help us better understand the attack > surface. Hm, I've missed the point (attack surface). So if once syscalls becomes available as module, unattended autoload (as I described on my previous post) wouldn't be a good idea. Maybe providing MINIMAL kernel without old ABI/KBI support in conjunction with GENERIC kernel with current form could be better. And would need to allow selecting which kernel to be installed on bsdinstall (or upcoming GUI installer?). > > If there are in fact binary-only programs built against older releases that > > are widely used, then that might be a counter balance to the range of > > options removed from GENERIC. > > > > I think though that just removing from GENERIC does not mean we should axe > > the ports. misc/compatN need to stick around for the options to still work > > in a custom kernel, and they are very cheap to build (just tarring up > > binaries). Also, converting COMPAT_FREEBSD to modules is non-trivial. > > I tend to think that removing the ports has no benefit and we should > keep them around. > > -- Brooks I strongly suspect that there would be binaries (including libraries) for old ABI/KBI, which are never in the ports tree and the developers provided them no longer maintaining (even rebuilding for newer ABI/KBI) the codes, are running sanely in the wild. Assuming something like Bug211837 [1]. [1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211837 -- Tomoaki AOKI