Le 16/02/2015 02:50, David Holland a écrit :
On Mon, Feb 16, 2015 at 12:13:07AM +0100, Jean-Yves Migeon wrote: > > > The funny thing is that a simple, *valid* call to sched_getparam() > > > crashes the system. Clearly, it means that in 6 years, nobody > > > tested it. As I stated, we should normally have received a bug > > > report from someone, but we didn't. It either means there's an > > > insidious conspiracy against us, or, nobody uses it. > > > >sched_getparam() is hardly a main-line function. I could easily > >imagine running compat binaries for years and never happening to use > >one that calls it. So I think your reasoning is suspect. > > Arguable perhaps, but not suspect. We all know that nasty bugs lie in > unused/rarely used code, yet they are still there to play with if someone > wants to. And there goes bad press. The big difference between this and a > crappy ioctl is that the ioctl works only when the hardware behind is > present. No, the logic was "nobody stepped on this bug in this obscure corner, therefore nobody uses the code".
Which is rather accurate: nobody uses that part of the compat code, yet it exists and is exposed to userland. The part that I find arguable is the generalization.
Let's face it: the more a code is used and exposed the more you find programming errors, be it through executions, auto/non-automated regressions tests, fuzz, etc. compat_freebsd is seldomly used, so less stress-tested that native.
> I hardly see the point in updating such compat code, unless some new binary > requires a more recent freebsd API/ABI. In that particular case better move > to compat_linux (I hardly see who would provide a FreeBSD binary without a > Linux one nowadays). > > Or deprecate old code gradually by making it root-only first (at least for > syscall related stuff) then squash it at a later time. You're missing the point. The same logic could be used to argue for removing compat_linux as well.
Any part of a code that bitrots. But depending on the part involved, risk/benefit ratio has to be taken into account. compat_linux has its needs; there are hundreds/thousands of products out there that are Linux-only. Less so for other compat stuff (or rare file-systems, network protocols, and so on).
This reminds me of the discussions I had a few years back for i386/amd64 and GENERIC/MODULAR/MONOLITHIC/... kernels. It is a matter of balance between what should be in, or out, or stay out but eventually loaded in dynamically.
Everyone has its tastes, both view make sense, but it is easier to deal with the few people that require specific code on a case by case basis rather than asking for a big swipe of all NetBSDs out there because someone found an exploitable bug in a rarely used code. module(7) offer some advantages in this regard when compared to builtins.
-- Jean-Yves Migeon