On Sat, Mar 20, 2010 at 2:31 PM, Jordan Gordeev <jgord...@dir.bg> 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.