Re: __memcpy_chk family of functions

From: Warner Losh <imp_at_bsdimp.com>
Date: Tue, 21 May 2024 13:20:09 UTC
On Tue, May 21, 2024 at 12:16 AM Dag-Erling Smørgrav <des@freebsd.org>
wrote:

> Marcin Cieslak <saper@saper.info> writes:
> > I have updated some binary packages using pkg(8) but neglected to
> > rebuild the world and my favourite web browsers no longer started
> > complaining about the undefined symbol __memcpy_chk@FBSD_1.8
> >
> > Would that be a good idea to add that information to the Handbook and
> > possible bump FreeBSD_version and add this info to UPDATING?
>
> The purpose of UPDATING is to document changes that break backward
> compatibility, i.e. running old binaries on a newer world.  What
> happened here is that you tried to run newer binaries on an older world,
> an issue of _forward_ compatibility, which we've never promised.
> Besides, an entry in UPDATING wouldn't have helped you since your source
> tree predated the change that would have added it.
>

Also, our forward compatibility guarantees are extremely weak.  At most the
outer
bounds are around a sliding window to upgrade from source, using root in
single user
on the console. So having to revert to an old kernel to build a new kernel
when there's
a problem, or having to revert to an old kernel to rebuild old sources. And
even then
it's not something we test, so it's likely broken or broken once you get a
hair's width
away from that path. Plus, with BEs and the easy ability to roll back to
the prior BE,
even this level of forward compat is likely to decay further in the future.

Warner