Date: Mon, 13 May 2024 17:21:23 +0000 From: Brooks Davis <brooks@freebsd.org> To: John Baldwin <jhb@freebsd.org> Cc: Warner Losh <imp@bsdimp.com>, Konstantin Belousov <kostikbel@gmail.com>, henrichhartzer@tuta.io, Freebsd Arch <freebsd-arch@freebsd.org> Subject: Re: Disabling COMPAT_FREEBSD4/5/6/7/9 in default kernel configurations Message-ID: <ZkJMEzZRtHfSvkVE@spindle.one-eyed-alien.net> In-Reply-To: <1d4afad4-250b-4c1c-8206-279a92a26ae4@FreeBSD.org> References: <NxZrrMD--3-9@tuta.io> <Zj84HLfYP_Psx4Me@kib.kiev.ua> <CANCZdfpjYe%2B03hhyeFWM2yvhDkZFS7U02r72iO7JhYtcsg4zaw@mail.gmail.com> <1d4afad4-250b-4c1c-8206-279a92a26ae4@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <kostikbel@gmail.com> > > 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<n> 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<n> to modules is non-trivial. I tend to think that removing the ports has no benefit and we should keep them around. -- Brooks
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?ZkJMEzZRtHfSvkVE>