On 26.09.2019 19:13, Maxime Villard wrote: > 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...). As I have proposed. MUSL+LTP for catching functional regressions/bugs AND fuzzing to catch crashes can be good enough to keep it trusted. The kernel certainly needs a lot of bug fixes, but instead of disabling this crucial feature it is better to find a way to make it more trusted. But this is a non-trivial amount of work an likely won't be done without a stimulation. I'm fine to switch sysctl to enable it on boot.
Attachment:
signature.asc
Description: OpenPGP digital signature