Return to proposals.mdwn CVS log

Up to [NetBSD Developer Wiki] / wikisrc / users / kamil

Try to tweak font size

    1: Projects proposal
    2: 
    3: Two kinds of tasks:
    4: 
    5:  - sanitization,
    6:  - fuzzing.
    7: 
    8: And in particular sanitization in the context of:
    9: 
   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).
   13: 
   14: Fuzzing covers:
   15: 
   16:  - userland programs and libraries,
   17:  - the kernel.
   18: 
   19: A typical project consist of:
   20: 
   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.
   26: 
   27: #### Port the LLVM DataFlow sanitizer to NetBSD (MKSANITIZER).
   28: 
   29: Not started and not researched.
   30: 
   31: #### Port Scudo to NetBSD (MKSANITIZER).
   32: 
   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.
   37: 
   38: #### Port LLVM CFI to NetBSD (MKSANITIZER).
   39: 
   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.
   43: 
   44: #### Port SafeStack to MKSANITIZER.
   45: 
   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.
   49: 
   50: #### Research and reimplement safestack shared between MKLIBCSANITIZER and the kernel.
   51: 
   52: Already done by Fuchsia, a research OS from Google.
   53: The feature must be C++ free, similar to micro-UBSan.
   54: 
   55: #### Port the LLVM cov, profile, xray, and sancov profiling to NetBSD.
   56: 
   57: Most of this already works, but investigation
   58: of the failing tests is needed.
   59: 
   60: A quick comparison (as explained by an upstream developer):
   61: 
   62: ##### cov
   63: 
   64: Did my test execute everything?
   65: 
   66: ##### profile
   67: 
   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.
   71: 
   72: ##### xray
   73: 
   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.
   78: 
   79: ##### sancov
   80: 
   81: Record the degree to which possible paths/data are covered
   82: by fuzz testing, in order to direct the fuzzer itself.
   83: 
   84: #### Research LLVM cov, profile and sancov in the NetBSD kernel. Compare it to Linux and FreeBSD KCOV.
   85: 
   86: Port as much as possible to the NetBSD kernel.
   87: 
   88: #### Research LLVM XRay as a replacement of DTrace in the NetBSD kernel.
   89: 
   90: This is a tricky feature with userland assumptions.
   91: Upstream is looking forward to this research and offers assistance.
   92: 
   93: #### Port AFL Triforce kernel fuzzer to NetBSD.
   94: 
   95: A port to OpenBSD already exists. Port and eliminate bugs.
   96: 
   97: #### Integration of rumpkernel (the NetBSD kernel) with userland tools.
   98: 
   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.).
  102: 
  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.