Am 15.02.15 um 16:31 schrieb Maxime Villard: > Le 14/02/2015 08:40, David Holland a écrit : >> On Fri, Feb 13, 2015 at 07:05:00PM +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: > > > http://mail-index.netbsd.org/source-changes/2014/06/21/msg055758.html > > This is a NULL pointer dereference, triggerable from userland. It was > introduced 6 years ago in this commit: > > > http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/compat/freebsd/freebsd_sched.c?only_with_tag=MAIN#rev1.17 > > 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. > > > http://mail-index.netbsd.org/source-changes/2014/10/10/msg059293.html > > This is a bug that causes the kernel to read from a userland pointer. If it > points to kernel memory, it reads kernel memory; if it points to an unmapped > page, the kernel crashes. This bug was introduced in the first revision, 9 > years ago. If in 9 years nobody can find such an obvious bug, it clearly > means nobody gives a shit about it. > > > 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. > > I understood that people need it for tw_cli, and that it is apparently the > *only* reason why we still have it. Therefore, I suggest we disable it by > default in the GENERIC kernels, simply to prevent users from being affected > by future bugs. tw_cli users can still recompile their kernel with > COMPAT_FREEBSD, or load the kernel module. > > You might argue it will rot if we disable it by default. See: it has been > rotting for 10 years now. > > >> It's clearly old, >> and not very complete, but I don't see anything so terribly >> objectionable. >> >> (other than that all the syscall marshalling code should be >> autogenerated; but that's a topic for a different bikeshed) >> >
I agree.
