Date: Mon, 27 May 2019 20:29:33 -0600 From: Warner Losh <imp@bsdimp.com> To: Garrett Cooper <yaneurabeya@gmail.com> Cc: Rainer Duffner <rainer@ultra-secure.de>, "Conrad E. Meyer" <cem@freebsd.org>, voidanix@420blaze.it, freebsd-current <freebsd-current@freebsd.org>, owner-freebsd-current@freebsd.org Subject: Re: Disabling COMPAT_FREEBSD4/5/6/7/9 as a default kernel option Message-ID: <CANCZdfpBnS8VMoDK=j7fYoFCUTDM55nJVX_GPg031uwnLkFWoA@mail.gmail.com> In-Reply-To: <24F2196F-A5A9-4BBA-B4D4-D6721B42A7C8@gmail.com> References: <ff7bfe10b7953d066e0f087b8d422b89@420blaze.it> <eaaf7d3d03dbbee0bebd2769d25fcd54@ultra-secure.de> <CAG6CVpXEixt1Y%2BLAGmKBGRzo3i%2BKYxwSLzh24eLyxtb54Fj_Tw@mail.gmail.com> <2d16a2a9ac5c090f196674d40d0cb398@ultra-secure.de> <3E7C1D63-996E-4AA0-A0A4-455B996BB9D6@gmail.com> <CANCZdfp3ORMJ%2BW6EHswn4AHQWtsRk4wWRHmZO-nn5HEvFB-SYg@mail.gmail.com> <24F2196F-A5A9-4BBA-B4D4-D6721B42A7C8@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, May 27, 2019, 8:23 PM Enji Cooper <yaneurabeya@gmail.com> wrote: > > On May 27, 2019, at 7:20 PM, Warner Losh <imp@bsdimp.com> wrote: > > On Mon, May 27, 2019, 6:49 PM Enji Cooper <yaneurabeya@gmail.com> wrote: > >> >> > On May 27, 2019, at 08:27, rainer@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@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 aroun= d >> >>> 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 wa= y >> the problem is just dragged out: "But it still works, does it and we hav= e >> 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 a= nd >> 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 h= ave >> lost the sources to...). It's running jdk15 and getting that thing to ru= n >> 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 stil= l >> work on recent releases, because 7.71 (last official version and intende= d >> 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=E2=80=99ll counter the OP=E2=80=99s 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 n= ot >> 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 ri= sk > of a console DoS if you print something on each system call=E2=80=A6 > > > My point was to suggest basically controlling the syscall table (like > linux does for instance). If a compat module was loaded, it would print o= ut > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfpBnS8VMoDK=j7fYoFCUTDM55nJVX_GPg031uwnLkFWoA>