tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Proposal, again: Disable autoload of compat_xyz modules



Le 26/09/2019 à 18:19, Kamil Rytarowski a écrit :
On 26.09.2019 15:55, Kamil Rytarowski wrote:
On 26.09.2019 15:06, Mouse wrote:
[...] compat_linux and compat_linux32 [...]

Keeping them enabled for the <1% users interested means keeping
vulnerabilities for the >99% who don't use these features.

Are the usage numbers really that extreme?  Where'd you get them?  I
didn't think there were any mechanisms in place that would allow
tracking compat usage.


I depend on compat_linux/compat_linux32 in at least 4 applications. I
don't use them daily, but frequently.

There are use-cases where linux_compat* is to be or not to be for NetBSD
as host. (At least one commercial user of NetBSD depends on it as well.)

In general it is fine to disable linux_compat* unless we can ensure its
correctness with regression tests and continuous fuzzing. As I discussed
with one developer, we could test linux_compat with faked/light linux
libc, unfortunately it still did not realize.



I have managed to get light cross-toolchain producing Linux binaries.

The only dependency is musl (+gmake to build it).

It works almost out of the box (I had to manually build certain files).

The only think that is required to be tuned is to add a dummy gnu_debuglink.

https://nxr.netbsd.org/xref/src/sys/compat/linux/common/linux_exec_elf32.c#214

The kernel shall have a fallback, and probably parse .intrp string and
look for 'ld-musl' in it.

$ cat m.c


#include <stdio.h>

int
main(int argc, char **argv)
{
	printf("Hello world!\n");

	return 0;
}
$ musl-gcc m.c


$ objcopy --add-gnu-debuglink=/dev/null ./a.out
$ file a.out
a.out: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically
linked, interpreter /lib/ld-musl-x86_64.so.1, not stripped
$ ./a.out


Hello world!

Another step is to build LTP with musl-gcc and run the tests.

https://github.com/linux-test-project/ltp (LTP supports musl)

There will be some patches involved.

The question is how to setup the tests for it? anita + picking these
packages from pkgsrc?

Making a setup with a syzbot instance for linux32/linux64 target should
be not that difficult.

Unfortunately all that needs some work in various projects, integration,
upstreaming code (to LTP?) etc and maybe TNF could spare someone to do it.

Also linux_compat is getting more and more irrelevant as time pass due
to shortage in our futex code (lack of robust futexes).


This is slowly worked on.

I think you are confused.

Fuzzing does not act as a perfusion to keep something artificially alive.

Part of the compat_linux bugs and vulns I fixed recently were found with a
simple fuzzing VM I set up. Yet, does it really change anything? My proposal
is unchanged. The attack surface is huge, I've been able to exercise only a
subset of the syscalls. Now big pullups need to be done, and no one is willing
to do them. The scanner bot also has found bugs that couldn't be found with
fuzzers.

Disabling certain compat options preserves the functionality, significantly
reduces the attack surface, and eases maintenance as well. At least the bugs
do not qualify as critical vulnerabilities if the feature is disabled.

Fuzzing does not reduce the attack surface, and does not constitute "active
maintenance" either (like pulling up, writing advisories, etc...).


Home | Main Index | Thread Index | Old Index