Le 15/02/2015 20:34, David Holland a écrit :
On Sun, Feb 15, 2015 at 04:31:36PM +0100, Maxime Villard 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.
> The problem is that these bugs affect the i386 users, most of which don't
> use compat_freebsd. This compatibility layer comes at the cost of security,
> and is - as I/you said - very incomplete.
By this same reasoning we should not have any binary compat code at
all. The only thing you've cited that's different about the freebsd
compat code is that it's out of date -- the proper response to that is
to update it. It's not like freebsd's syscall ABI is secret or
anything.
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.
Cheers,
--
Jean-Yves Migeon