1: Projects proposal
3: Two kinds of tasks:
5: - sanitization,
6: - fuzzing.
8: And in particular sanitization in the context of:
10: - MKSANITIZER (using the default runtime ported to NetBSD),
11: - MKLIBCSANITIZER (a reimplementation of the runtime inside libc),
12: - kernel (a reimplementation of the userland runtime, usually inspired by the counterpart in a different OS).
14: Fuzzing covers:
16: - userland programs and libraries,
17: - the kernel.
19: A typical project consist of:
21: - work directly on the LLVM trunk version, unless the feature is available in a stable release,
22: - if needed, porting and upstreaming of NetBSD support to LLVM,
23: - validation of the feature against upstream test-suite, porting the tests to it,
24: - addition of ATF (automated test framework in NetBSD) regression tests covering the new feature,
25: - integration with MKSANITIZER/MKLIBCSANITIZER/kernel.
27: # Port the LLVM DataFlow sanitizer to NetBSD (MKSANITIZER).
29: Not started and not researched.
31: # Port Scudo to NetBSD (MKSANITIZER).
33: There is a draft port, however tests are designed against the
34: GNU malloc(3) API (mallinfo). Porting or reimplementing the
35: tests for jemalloc(3) is needed. The feature might be fully
36: functional with local patches, but its status is unknown.
38: # Port LLVM CFI to NetBSD (MKSANITIZER).
40: This project certainly needs commitment and connection of
41: all the toolchain pieces together. It might require work
42: on programs like ar(1), ld(1), and dynamic ELF loader.
44: # Port SafeStack to MKSANITIZER.
46: The port is done. All tests pass. It needs research and
47: integration as the MKSANITIZER option. It might work
48: out of the box, but it's not tested and not researched.
50: # Research and reimplement safestack shared between MKLIBCSANITIZER and the kernel.
52: Already done by Fuchsia, a research OS from Google.
53: The feature must be C++ free, similar to micro-UBSan.
55: # Port the LLVM cov, profile, xray, and sancov profiling to NetBSD.
57: Most of this already works, but investigation
58: of the failing tests is needed.
60: A quick comparison (as explained by an upstream developer):
62: ## cov
64: Did my test execute everything?
66: ## profile
68: Record optimizer-relevant details of what was executed.
69: Profile can have performance overhead where useful, as
70: long as it doesn't skew the profile or make it unusable.
72: ## xray
74: Record programmer-relevant details of what was
75: executed. Xray must have *absolute* minimal overhead
76: when *not* doing anything, but ability dynamically
77: to enable this kind of tracing is necessary.
79: ## sancov
81: Record the degree to which possible paths/data are covered
82: by fuzz testing, in order to direct the fuzzer itself.
84: # Research LLVM cov, profile and sancov in the NetBSD kernel. Compare it to Linux and FreeBSD KCOV.
86: Port as much as possible to the NetBSD kernel.
88: # Research LLVM XRay as a replacement of DTrace in the NetBSD kernel.
90: This is a tricky feature with userland assumptions.
91: Upstream is looking forward to this research and offers assistance.
93: # Port AFL Triforce kernel fuzzer to NetBSD.
95: A port to OpenBSD already exists. Port and eliminate bugs.
97: # Integration of rumpkernel (the NetBSD kernel) with userland tools.
99: Slice the NetBSD kernel in userland as a library,
100: and integrate fuzzers with the subsystems (network
101: stack, syscall layer, SCSI stack, filesystems, etc.).
103: There is a research project in which rumpkernel has been
104: successfully fuzzed on the syscall layer with AFL. The layer
105: accepts input generated by the fuzzer via standard input stream.
CVSweb for NetBSD wikisrc <wikimaster@NetBSD.org> software: FreeBSD-CVSweb