Re: Removal of compat-FreeBSD

[Maxime Villard <max%M00nBSD.net@localhost>]

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)
>