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