On Sun, Feb 15, 2015 at 04:31:36PM +0100, Maxime Villard wrote: > > > > Our norms for significant changes are more or less about consensus or > > > > preponderance of opinion. So far you've said that you want to > > > > remove/disable this, and a number of people have said they use it. No > > > > one else has spoke up in favor of disabling. > > > > > > Perhaps because I am the only one who read the code? > > > > I just read the code. What's so horrible about it? > > What is so horrible? Well, you're right, it no longer is. But since obvious > things apparently need some explanation: > [...]
Ok, it has had some bugs. Great. Syscall argument handling bugs are bad, but... they're still bugs, they happen. Until we have a static analysis tool that checks user vs. kernel pointers (and we replace code that plays fast and loose with the distinction, of which we have too much) this will remain a risk. > 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. > 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. -- David A. Holland [email protected]
