Re: Disabling COMPAT_FREEBSD4/5/6/7/9 in default kernel configurations

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 <[email protected]>
> > wrote:
> > 
> > > On Sat, May 11, 2024 at 01:38:38AM +0200, [email protected] 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