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

On Mon, 13 May 2024 17:21:23 +0000
Brooks Davis <[email protected]> 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 <[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.

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<n> 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    <[email protected]>