> On May 27, 2019, at 7:20 PM, Warner Losh <i...@bsdimp.com> wrote: > > On Mon, May 27, 2019, 6:49 PM Enji Cooper <yaneurab...@gmail.com > <mailto:yaneurab...@gmail.com>> wrote: > > > On May 27, 2019, at 08:27, rai...@ultra-secure.de > > <mailto:rai...@ultra-secure.de> wrote: > > > > Am 2019-05-27 17:05, schrieb Conrad Meyer: > >> Hi Rainier, > >> On Mon, May 27, 2019 at 7:47 AM <rai...@ultra-secure.de > >> <mailto:rai...@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 _______________________________________________ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
