Conrad Meyer

This page is primarily intended for my own use. If you're going to make changes to it, please drop me a note letting me know. Thanks.

I'm interested in cryptographic algorithms, amd64, and a usable desktop operating system. Also a usable server operating system, debugging enhancements, and good developer documentation.

• My open reviews on Phabricator that need review

• FenestrasX RNG algorithm
  • Diff adding majority of implementation
  • mostly trivial arc4random(9) integration
  • integration into userspace arc4random(3)
• libsiginfo (user version of sysctl kern.tty_info_kstacks)
• random(4), other:
  • random source deregistration safety
  • rename random(9) – currently implemented as the utterly horrible rand(3). “pseudorand()”?
    • Probably bring in (default 128B state) random(3) (sans initstate, srandom) to replace rand(3) in first step. Name it after its function: lfsr128().
    • Optionally, bring in faster/better new non-CS PRNGs like some PCG variant or xoroshiro variant (256 ??) or SplitMix?
    • Optionally, transition current uses of pseudorand/lfsr128 to other non-CS PRNGs slowly
  • Buffer arc4random(9) like arc4random(3) (really rebase on the userspace variant entirely)

• Random:
  • Randomdev entropy harvesting:
    • Early entropy via timer + coinflip? (Aka, jitter entropy; Fuschia has an implementation, LWN article (2015))
    • Pass entropy from loader (EFI loader) for early seeding? Yes: despite BIOS being largely untrustworthy (incompetence, not malice), there is no reason to believe it is harmful (unless Fortuna uses it to unblock in the absense of all other entropy, but we need a plan for that generally). See prior work https://reviews.freebsd.org/D20780.
    • Scale randomdev harvest to multi-CPU; single ring will certainly be point of contention and likely why we are too costly for high rate sources like ether and uma. (Well, we might always be too high for those, but maybe we can use 0.001% of those without too bad of impact?) Scale first.
  • Source de-registration safety / object lifetimes (nothing protects concurrent modification/access of sources_list).
  • Interface for sampling raw source output for SP800-90B testing on live systems
  • Interface for live compression testing of weak entropy sources as a really crappy sp800-90b test (useful for detecting totally broken RNGs, not adversarial ones)
  • Mathy paper on creating pure random bits from weak sources; maybe there is something we can glean for initial seeding.
  • Pseudo-random: Add PCG as a faster/better random(3) to sys/libkern and lib/libutil and document in random.3/random.9 as a better option
• Add some basic HyperV vmbus device drivers for:
  • unknown pnpinfo classid=525074dc-8985-46e2-8057-a307dc18a502 deviceid=... (dynamic memory / balloon)
  • unknown pnpinfo classid=cfa8b69e-5b4a-4cc0-b98b-8ba1a1f3f95a deviceid=... (mouse)
  • unknown pnpinfo classid=da0a7802-e377-4aac-8e77-0558eb1073f8 deviceid=... (framebuffer)
• Make (GEOM) device aliases more sane (i.e., symlinks instead of independent devfs nodes that aren't even the same inode)
• Upstream (from OneFS):
  • sysctl_limit (non-controversial?))
  • ddb show bufv / show bobj?
• Dump
  • Add a EKCD dump mode with a MAC, i.e., Chacha-poly?
    • EKCD by default with per-host keys?
  • Can we use accelerated intrinsics that require FPU context in dump? (Sure, why not?)
  • Lift dump write coalescing out of netdump into MI dump code
• efibootmgr (bcran@ doing some work in this area):
  • DDB configuration (at least 'nextboot -k' functionality is present, supposedly)
  • Have nextboot use it instead of nextboot.conf on EFI systems (once feature parity is achieved)
  • Was: ConradMeyer/DDBNextBoot
  • See also https://lists.freebsd.org/pipermail/freebsd-arch/2017-August/018287.html
• UFS + gmirror corruption recovery (would only help checksummed blocks, which is some metadata for now — not data)
• Crypto TODO: ifunc-select, accelerated aes, chacha?
• Build arc4random_uniform into the kernel (first draft r346410, reverted r346420, should complete at some time)
• Reduce insanity of sysctlmemlk, wiring, etc.
• WireGuard
  • Needs some (missing) crypto primitives:
    • ChaCha20 + Poly1305 IETF AEAD construction
    • Curve25519 ECDH
    • HKDF
    • Some existing BSDL work to integrate with NetBSD! Exciting.
    • And OpenBSD
    • All primitives available from Microsoft SymCrypt with tests (and terrible code style, but who cares)
• Investigate paste to terminal buffer size limitations (1920 bytes at 9600; 'pstat -t' INQ; 23040 bytes at 115200)
• Add a real VDSO and move shared page hack stuff to it
  • Generate cfi unwind directives for sigcode (sigtramp.S)
• getcontext/setcontext/swapcontext libc wrappers that only need to invoke syscalls if signal mask actually changes.
• GDB: DDB commands via monitor ... (qRcmd)
• ILOG (logging, with like, levels. configurable by file and even specific log sites. it's nice, I promise. WIP. Needs a manpage.)

• bus_dma.9 (some of this is stale after JHB's improvements):
  • Break up bus_dma.9 into reasonable chunks
    • Leave bus_dma.9 as overview; describe two main workflows (static command buffers, dynamic data)
  • Document when load callback can be expected to be synchronous
  • Be explicit that map may be NULL in success case
  • Document that absense of BUS_DMA_NOWAIT does not guarantee success
• procstat
  • Protocol column for unicode streams seems factually inaccurate

• lsblk interesting similarish goal shell program here
• Zprezto pkg integration?
• pkg parallel fetch

• ustack portion of SIGINFO stacks
• unifdef cleanup, capabilities for cdefs.h cleanup for gcc 4
• procstat: Multiple options at a time would be cool
• Look into extattr bugs
• Periodic (like, weekly) “disk cleanup” TRIM pass of unused filesystem blocks, like Windows 10. Integration with UFS needed.
• Bhyve MONITOR/MWAIT?
• Fix bhyveload/userload (forked from loader?) to be able to write disk (for e.g., nextboot)
• netdumpd can reduce caps further (procstat -Cf)
• Figure out how to adapt to screen
• Valgrind-FreeBSD bugs
  • Failing tests that need to be addressed before valgrind-freebsd can be upstreamed
• VM images with serial access? Either default or a special “insecure” “cloud” .conf

• USB debug support would be cool (work with Daniel)
• Can we add debugging / invariants to help https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194643 ?
• Re-add idle page zeroing w/ DMA engine(s)
  • Probably needs generic DMA engine framework (unfortunately xdma(4) not suitable)
• Would be nice if USB stack didn't shit itself unplugging a multi-function USB (maybe CD CAM bug instead, who knows)
• NBD support (Net block device)
• Non-block device re-root support
• Support for AMD encrypted memory, like r344353
  • The newer models have guest-controlled memory encryption, protecting them (maybe) from other guests?
• ddb commands from an unstopped kernel? Usually ddb printers “take” appropriate locks, but lock paths bypass in ddb mode; if some are missed, this could be unsafe.
• stack(9) API cleanups
  • Just provide one API that works, not 3 APIs that need special knowledge of thread internals to use correctly
  • Define *minimum* frames we can store, and compress (delta, zigzag, streamVbyte) for better efficiency. It seems in practice we can achieve something like 3/8-4/8 compression on stacks without much difficulty.
    • Limited benefit? Reducing minimum size would be somewhat significant for WITNESS, various MEMDEBUG modes, Lockmgr debug. Doesn't matter for release kernels really
• CTF-based structhole for DDB? https://www.freebsd.org/cgi/man.cgi?query=ctf&sektion=5

• Pursue Userspace WITNESS and lock profiling work from a past GSoC
• Port the abigail package ABI checker to pkg(1) (when debuginfo exists)
  • Bapt points out http://lvc.github.io/abi-compliance-checker/
  • https://fedoraproject.org/wiki/Taskotron/Tasks/dist.abicheck

• See also https://wiki.debian.org/Hardening
• Look into Syzkaller more, ask Mark about his setup

• Zstd compression in more places?
  • Compressed relocations
  • Compressed debuginfo, CTF? (Maybe not CTF if kernel must directly map it.)
  • kldload(8) support for compressed modules?

• pciutils reading extended xHCI capabilities (upstream)

• Steal as many good ideas from Google Abseil (Apache 2 license) as we can. It's C++, not C, so some adaptation of ideas is required (at least for kernelspace). Examples include:
  • Their userspace mutexes have maybe something like WITNESS. We'd like that functionality in userspace.
  • Btree maps are something we can/should use more of in FreeBSD for large datastructures with lookup (point or range) requirements, so long as they do not have pointer stability requirements and M_WAITOK is permitted.
  • Hash tables with better-than-naive performance characteristics.
  • Plethora of debugging utilities that may provide food for thought
  • Ditto synchronization, although for Kernel and C we've largely adopted ConcurrencyKit instead, and that works quite well.
  • Time routines, food for thought