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: 1. Port the LLVM DataFlow sanitizer to NetBSD (MKSANITIZER).
29: Not started and not researched.
31: 2. 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: 3. 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: 4. 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: 5. 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: 6. 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 -> Did my test execute everything?
64: profile -> Record optimizer-relevant details of what was executed.
65: Profile can have performance overhead where useful, as
66: long as it doesn't skew the profile or make it unusable.
68: xray -> Record programmer-relevant details of what was
69: executed. Xray must have *absolute* minimal overhead
70: when *not* doing anything, but ability dynamically
71: to enable this kind of tracing is necessary.
73: sancov -> Record the degree to which possible paths/data are covered
74: by fuzz testing, in order to direct the fuzzer itself.
76: 7. Research LLVM cov, profile and sancov in the NetBSD kernel. Compare it to Linux and FreeBSD KCOV.
78: Port as much as possible to the NetBSD kernel.
80: 8. Research LLVM XRay as a replacement of DTrace in the NetBSD kernel.
82: This is a tricky feature with userland assumptions.
83: Upstream is looking forward to this research and offers assistance.
85: 9. Port AFL Triforce kernel fuzzer to NetBSD.
87: A port to OpenBSD already exists. Port and eliminate bugs.
89: 10. Integration of rumpkernel (the NetBSD kernel) with userland tools.
91: Slice the NetBSD kernel in userland as a library,
92: and integrate fuzzers with the subsystems (network
93: stack, syscall layer, SCSI stack, filesystems, etc.).
95: There is a research project in which rumpkernel has been
96: successfully fuzzed on the syscall layer with AFL. The layer
97: accepts input generated by the fuzzer via standard input stream.
CVSweb for NetBSD wikisrc <wikimaster@NetBSD.org> software: FreeBSD-CVSweb