Re: Disabling COMPAT_FREEBSD4/5/6/7/9 as a default kernel option

> On May 27, 2019, at 7:20 PM, Warner Losh <imp_at_bsdimp.com> wrote:
> 
> On Mon, May 27, 2019, 6:49 PM Enji Cooper <yaneurabeya_at_gmail.com <mailto:yaneurabeya_at_gmail.com>> wrote:
> 
> > On May 27, 2019, at 08:27, rainer_at_ultra-secure.de <mailto:rainer_at_ultra-secure.de> wrote:
> > 
> > Am 2019-05-27 17:05, schrieb Conrad Meyer:
> >> Hi Rainier,
> >> On Mon, May 27, 2019 at 7:47 AM <rainer_at_ultra-secure.de <mailto:rainer_at_ultra-secure.de>> wrote:
> >>> I have a 32bit FreeBSD 6 binary that I'll need for a bit until the
> >>> department who is technically responsible for the service gets around
> >>> redoing that service.
> >> Even if this proposal is approved, it would only affect 13+.  You
> >> could still run your FreeBSD 6 binary in a 32-bit 12 VM in a 13+
> >> Bhyve.  But do consider lighting a fire under whatever department
> >> thinks it's ok to deploy like that :-).
> >> Take care,
> >> Conrad
> > 
> > 
> > I thought so, too.
> > 
> > I don't really want to run the abandonware of a RADIUS-server any longer than necessary (as absurd as that sounds).
> > 
> > It's also running a recursive nameserver (previously also authoritative) that is still hard-coded in CPE and computers behind firewalls.
> > 
> > I first wanted to virtualize it (it's not a big problem) - but this way the problem is just dragged out: "But it still works, does it and we have no time".
> > 
> > Everybody now knows that the clock is ticking, literally.
> > 
> > Oh, I also remember George Neville-Neil talking about a - what - FreeBSD 4 binary that a certain search-engine had lost the sources for and was running on FreeBSD 7 with compat4.
> > (We also have a client who literally begged us to leave a decade-old Solaris box running through 2019 and half of 2020 so they could continue to do their bookkeeping on a home-grown java-app that I suspect they, too have lost the sources to...). It's running jdk15 and getting that thing to run under anything semi-decent doesn't seem to have worked-out too well.
> > So, people pray for the best and don't prepare for the worst.
> > 
> > 
> > Other stuff I can think of:
> > - very old Netbackup-Clients (like 5-series), though I doubt they still work on recent releases, because 7.71 (last official version and intended for FreeBSD 11) stopped working on FreeBSD12, sadly)
> > - certain pre-compiled VMWare Tools Modules? Pre open-source-tools (I can never make up my mind if it's VMWare-open-Tools or Open-VMWare-Tools or something different)
> > 
> > 
> > What ever people do with COMPAT4-9 - it's bordering the pathological.
> 
> I’ll counter the OP’s suggestion a bit:
> 
> It would be nice if the compat options were modularized and printed out an EOS warning when loaded, so the user was aware that the modules are not supported by FreeBSD, in terms of security and whatnot.
> 
> How is that relevant? They just control system calls, not any userland libraries that might or might not have a security exposure. Plus, if not done right you either startle the horses for no reason, or you run the risk of a console DoS if you print something on each system call…

My point was to suggest basically controlling the syscall table (like linux does for instance). If a compat module was loaded, it would print out the warning. Not on each syscall entry. That would be insanity as far as performance degradation would be concerned :/.
-Enji