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

On Mon, May 27, 2019, 8:23 PM Enji Cooper <yaneurabeya_at_gmail.com> wrote:

>
> 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> wrote:
>
>>
>> > On May 27, 2019, at 08:27, 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> 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 :/.
>

Except it would take a lot of work to make the compat options a module.
Also, we need them for the upgrade path... I'm still not convinced a
warning would be more beneficial than the concern it would generates...

Warner