Re: ABI guarantees

On Mon, Aug 18, 2025 at 12:42 PM John Baldwin <jhb@freebsd.org> wrote:

> On 8/15/25 02:25, Konstantin Belousov wrote:
> > I think that now is the time to discuss the project ABI stability
> guarantees
> > that we provide for the system as the whole.  My personal opinion always
> is
> > that FreeBSD should aim at providing the perfect compatibility.  This can
> > be formulated at two levels:
> > - from high level view, an app depending on the base library or kernel
> >    feature, should never break.
> > - a view from the low side would list the technical aspects of things,
> >    that allows to provide the guarantee of the high level view.
> >
> > We have a lot of facilities to allow the base system evolution while
> still
> > having the stability of interfaces.  I might try to enumerate all that
> > features, below is incomplete but representative list of examples:
> > - versioning of dsos, both as dso version, and fine-grained symbol
> versions
> > - definition of boundaries, where we provide the binary consumers a view
> >    on implementation  (e.g. syscall interfaces, kernel compat syscalls).
> > - rtld tricks to provide expected execution environments from older
> >    releases on modern systems.
> > - kernel support for old binaries formats, older p_osrel, ELF notes to
> >    record compilation environment of the binary, etc.
>
> Note that p_osrel is not perfect for dynamic binaries as an old binary on
> a newer system might use a newer version of shared library that is compiled
> against a newer ABI.
>
> Another gaping hole we have is sysctl().  We have no versioning of the ABI
> expected by callers.  Statically assigned MIBs can deal with this by
> bumping
> the constant for the MIB, but most MIBs use OID_AUTO and sysctlbyname()
> both of which bypass that.
>

This is one of the biggest areas of code in bsd-user: To export the u area
via sysctl.


> > So, do we as the project strive to fullfill this goal?  Note that ABI
> compat
> > is not a grading scale: if system fail running some binary, then the
> compat
> > failed.  This is why the feature is hard, in addition to the lot of
> subtle
> > technical details to care about, there needs to be a constistent efforts
> > to properly maintain it.
>
> I do disagree slightly about the scale.  In particular, I think for kernel
> KPIs used by kernel modules (not userspace), we already have a de-facto
> sliding scale.  We do try to keep some kernel modules working across
> minor releases (like a NIC driver or perhaps a filesystem), but we do not
> constrain the development of things like the VM system such that drm-kmod
> is stable.  We also make no promises for any kernel module across major
> branches, and in fact encode an explicit MODULE_DEPEND to disallow loading
> them.
>

Yea. We have very weak and limited compatibility on the same branch for
kernel modules. And we mostly have stuff that's working by accident:
there's no testing tools to ensure compat. Plus, some things like LinuxKPI
are overly inlined, encoding far too many offsets in the clients, which is
a big driver of drmkmod not working from minor release to minor release. It
would be a heavy lift to fix those design decision: It's possible, but it a
lot of grunt work.


> For userspace I do think we want a higher bar, but I'm not sure that a bar
> of "no binary can ever stop working" is fully feasible.  The Secure RPC
> case is an example where we've removed the necessary crypto bits because
> they are insecure and deprecated.  I would probably rather have stubs
> for the libc symbols that fail immediately rather than keeping around the
> implementation in the Secure RPC case.  That might depend on your
> definition
> of stability.  Are stub symbols that permit an executable to still load
> and execute but encounter errors if using the stubs considered an ABI
> compat shim or ABI breakage?  What about cases where we can't support
> the old semantics?  In 14.0 (I think) I removed kernel support for several
> insecure crpyto algorithms that are formally deprecated for IPsec, and
> we no longer support configuring them via setkey(8) or the like.  The
> binaries still work, but they will get an error back from the system call
> if they use a deprecated algorithm.  Is that ABI breakage?
>

Yes. The goals for ABI stability is to run old binaries that used supported
interfaces on newer versions of FreeBSD. We've never had formal support
documents. And we certainly have no testing of the assurances that we give
to our users are working out.

So in general, we should keep things working, keep the old implementation
around, but no longer exposed. However, for cases like DES where the
functionality was broken by external forces (eg the crypto algorithms no
longer hide content), I see that as something out of our control. We don't
have to support that since they are already de-facto broken and/or are too
dangerous to use. We have no evidence of use, even, for this use case, so
there comes a time that we'll have to spend our limited resources on what
we can support, and do like John suggests and have stubs that insta-fail so
that old binaries still work to the extent that they don't use the feature.
Such decisions should be relatively rare, but deliberative and intentional.
In this case, I'd fall onto the side of support being limited to saying we
don't support it.

Warner