Re: Removal of compat-FreeBSD

[Marc Balmer <marc%msys.ch@localhost>]

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.