Date: Mon, 13 May 2024 09:59:34 -0700 From: John Baldwin <jhb@FreeBSD.org> To: Warner Losh <imp@bsdimp.com>, Konstantin Belousov <kostikbel@gmail.com> Cc: henrichhartzer@tuta.io, Freebsd Arch <freebsd-arch@freebsd.org> Subject: Re: Disabling COMPAT_FREEBSD4/5/6/7/9 in default kernel configurations Message-ID: <1d4afad4-250b-4c1c-8206-279a92a26ae4@FreeBSD.org> In-Reply-To: <CANCZdfpjYe%2B03hhyeFWM2yvhDkZFS7U02r72iO7JhYtcsg4zaw@mail.gmail.com> References: <NxZrrMD--3-9@tuta.io> <Zj84HLfYP_Psx4Me@kib.kiev.ua> <CANCZdfpjYe%2B03hhyeFWM2yvhDkZFS7U02r72iO7JhYtcsg4zaw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
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.
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.
--
John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1d4afad4-250b-4c1c-8206-279a92a26ae4>