Re: [gsoc] syscall/libc fuzzer proposal

[Elad Efrat <elad%NetBSD.org@localhost>]

On Sat, Mar 20, 2010 at 2:31 PM, Jordan Gordeev <jgordeev%dir.bg@localhost> 
wrote:
> On 3/20/10 7:54 PM, Elad Efrat wrote:
>>
>> Strongly seconded. There are so many great ways to improve NetBSD and
>> wasting time and money on fuzzing is about as suboptimal as it gets.
>
> Please, list some of them.

Sure.

We need to finish abstracting stuff to kauth(9), and then might
consider changing to type-safe KPIs. There's also fileassoc(9) that
can solve a lot of problems (most recently the PaX ELF flags thing) by
providing file-system independent metadata storage -- completing its
kernel parts and perhaps providing a way to make it persistent is
important. I'd also like to see Veriexec gaining digital signature
support, now that NetPGP is in the base (and there's the per-page
fingerprints feature that needs to be somewhat debugged and enabled),
as well as a capabilities secmodel being added, even if as an
experiment. We just recently discussed a centralized daemon to
correlate security events and act upon them; this is probably not that
hard to implement. (Especially if you "modularize out" the correlation
bit :) Personally I'd also like to see PaX UDEREF done for us as well.

Of course, our network stack needs tons of improvements; we started
that a while ago by making socket options use real types rather than
mbufs and we still have a long way to go in that regard. I'd like to
see some of the improvements OpenBSD/FreeBSD added being looked at -
multiple routing tables, virtualization of the stack, etc., even if
it's to end up saying "not worth it."

Then there's also the issue of clean interfaces for passing data
to/from the kernel. Kvm(3) is a mess, and I'd like to see at least a
move towards sysctl, but preferably this needs to be solved in a
proplib-kinda way (I don't think "performance" is a goal for these
reporting tools).

Every one of the above has long-term prospects much better than
working on "fuzzing," and this is just a quick "OTOH" list; I'm sure
the folks who are doing work in UVM and the file-systems can list tons
of other ways to strengthen the foundations rather than introduce
"fuzzing" tools, even if we're looking to encapsulate something as a
GSoC project.

-e.