--- title: Introduction to µUBSan - a clean-room reimplementation... description: An in-depth engineering writeup describes µUBSan, a clean-room reimplementation of the Undefined Behavior Sanitizer runtime built from scratch for NetBSD,... canonical: https://daily.dev/posts/introduction-to-ubsan---a-clean-room-reimplementation-of-the-undefined-behavior-sanitizer-runtime-kcqjgqfgz twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: Introduction to µUBSan - a clean-room reimplementation of the Undefined Behavior Sanitizer runtime | daily.dev og:description: An in-depth engineering writeup describes µUBSan, a clean-room reimplementation of the Undefined Behavior Sanitizer runtime built from scratch for NetBSD,... og:url: https://daily.dev/posts/introduction-to-ubsan---a-clean-room-reimplementation-of-the-undefined-behavior-sanitizer-runtime-kcqjgqfgz og:image: https://api.daily.dev/og/posts/KCqJgqfGZ.png og:image:alt: Introduction to µUBSan - a clean-room reimplementation of the Undefined Behavior Sanitizer runtime og:image:width: 1200 og:image:height: 630 og:locale: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # Introduction to µUBSan - a clean-room reimplementation of the Undefined Behavior Sanitizer runtime **[Lobsters](https://daily.dev/sources/lobsters)** · 20 min read · 0 upvotes · 0 comments ## Summary An in-depth engineering writeup describes µUBSan, a clean-room reimplementation of the Undefined Behavior Sanitizer runtime built from scratch for NetBSD, since Clang's C++ runtime and the Linux GPL implementation weren't suitable for libc/kernel use. Written as a single portable C file, it supports nearly all UBSan checks except vptr, uses a single-line reporting format instead of multiline stack traces to avoid locking issues, and skips implementing __ubsan_on_report() due to thread-safety complexity. It operates in three modes: kUBSan (kernel), uUBSan inside libc via MKLIBCSANITIZER, and a standalone library for ATF regression tests. Reporting channels differ by context (printf/panic in kernel; stdout/stderr/syslog in userland, configurable via LIBC_UBSAN). Thirty-eight ATF test scenarios validate the implementation, and numerous undefined-behavior bugs have already been found and fixed across NetBSD subsystems, with some fixes ported to FreeBSD. The runtime is BSD-2-clause licensed for reuse by other operating systems. Next planned work includes porting honggfuzz's ptrace attach functionality and continuing the Address Sanitizer port to the NetBSD kernel. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Questions this post answers ### Why did NetBSD write its own UBSan runtime instead of using the Clang/LLVM one directly? The original Clang/LLVM UBSan runtime is written in C++ with features unavailable in libc and the NetBSD kernel, and the Linux kernel's native C runtime is GPL-licensed and behind upstream in supported checks. NetBSD's µUBSan is a clean-room, BSD-2-clause licensed, single self-contained C file usable in the kernel, libc, and standalone ATF tests without triggering undefined behavior itself. _Teams weighing license and portability constraints for low-level tooling can track cases like this on daily.dev._ ### Which UBSan check does NetBSD's µUBSan runtime not support? µUBSan supports every UBSan report type except -fsanitize=vptr, because vptr requires low-level C++ routines to introspect vtables and dynamic type compatibility, which the C-only runtime deliberately avoids. All other checks are performed in inlined instrumented code, with the runtime mainly handling deserializing reports into messages. _Developers evaluating sanitizer coverage gaps can follow deep dives like this on daily.dev._ ### How can I enable the Undefined Behavior Sanitizer in the NetBSD kernel? Enable the KUBSAN option in the kernel configuration file (for example sys/arch/amd64/conf/GENERIC), uncommenting 'options KUBSAN', then build with './build.sh kernel=GENERIC'. This activates kUBSan, which shares the same µUBSan runtime as the userland version but reports issues via printf(9) or panic(9) instead of stdout/stderr/syslog. _Kernel developers configuring sanitizer builds can keep up with setup details like this on daily.dev._ ## Community take How the wider developer community reacted, aggregated from 2 discussions and 131 comments across lobsters, hackernews (as of 2026-08-12). **TL;DR:** Discussion splits into a long, sprawling argument about whether shipping a library as a single .c file is good practice, plus a tangent (on another platform) about BSD/LLVM/GCC licensing politics; both threads drift well away from the technical substance of µUBSan itself. **Sentiment:** 30% positive · 55% mixed · 15% skeptical **The case for** - Single-file distribution is praised as easy to integrate, port, and adapt for different libcs or embedded/cross-compilation targets. - Some argue file size (~1300 lines) is small enough that splitting it into multiple files wouldn't meaningfully help. - A few note it avoids dependency/package-management headaches since you just drop in one file. **The pushback** - Critics argue linking multiple files is a well-supported, basic C skill and that single-file libraries train beginners toward bad practices. - Some worry a monolithic file mixes interface and implementation, discouraging modularity and complicating future feature growth. - The term 'clean-room' is called out as misleading/imprecise since no actual IP-isolation process is documented. - One commenter questions why a full clean rewrite was needed when the original UBSan license is permissive enough to reuse or patch. - One comment calls the effort duplicated work that patches to the existing LLVM implementation might have addressed instead. **By community** - lobsters (heated): A tangential argument breaks out over BSD vs Linux security tooling and LLVM vs GCC licensing, with pushback on overstated claims about BSD superiority. - hackernews (heated): Most of the thread is a long back-and-forth debate about the merits and drawbacks of single-file C libraries, with more measured technical questions about the clean-room terminology and runtime purpose mixed in. **Hottest debate:** Whether distributing a library as a single self-contained .c file is a good practice or one that trains developers in bad habits versus normal multi-file linking. **Open questions** - Why was a full clean-room rewrite necessary given the original UBSan runtime's permissive license? - Is the runtime API shared or compatible between GCC and LLVM/Clang implementations? - What does this accomplish that patches to the existing LLVM implementation couldn't? **Highlights** > >I've decided to write the whole µUBSan runtime as a single self-contained .c soure-code file, as it makes it easier for it to be reused by every interested party. I don't really get why people do this. Linking is one of the easiest and most broadly supported features of C environments on every platform. > — [Sir\_Cmpwn on hackernews · 9 comments](https://news.ycombinator.com/item?id=17716520) > There seems to be several different discussions which are taking place as a response to your comment. It might be good to have a more consolidated reference since different people are attacking different aspects of your argument, so of which are a little unfair.[I am not a native speaker so I may have misunderstood some points or will misrepresent them] Reasons why people like single file libs: * Easy for a beginner to use. * No non-obvious dependencies. (check includes to see them) * Easy to repackage for multiple OS's * Easy to understand since each reference is in the same file. * Typically simpler and have fewer features(which can help one focus on the main issues.) * No need for either static or dynamic linking, although it is basically the same as static linking in some ways. * Eliminates the need for dependency management. Reasons against single file libraries: * No isolation of components. (The interface and implementation are in the same file) * Adding new feature may make the library too complicated(which can lead to some features being denied) * A bit harder to maintain. Since the interface and implementation are the same, some users may depend on internal interfaces. Which can inhibit changes needed for performance. * May encourage bad behaviour, since the user need never learn to link against a third party library. If the culture changes enough there may be many people contributing who are not able to use standard tools in the standard way. (The idea that beginners should learn the culture that is used by the toolmakers.) Hopefully this is useful for someone, and I hope I did not misrepresent any opinions.[Also huge fan of Drew] > — [abenedic on hackernews](https://news.ycombinator.com/item?id=17718534) > Why was a clean-room approach necessary here? The UIUC License used by UBSan is extremely permissive, so going through extra effort to avoid creating a derivative work doesn't make much sense to me. > — [alexhutcheson on hackernews · 3 comments](https://news.ycombinator.com/item?id=17717236) > It's sad to see so much duplicated effort. What does this accomplish that a few patches to the llvm implementation couldn't? > — [berti on hackernews](https://news.ycombinator.com/item?id=17720883) > > I absolutely love that the BSDs are switching to llvm. What does this news story have to do with LLVM? > — [pstef on lobsters · 3 points, 1 comments](https://lobste.rs/s/7txupx/introduction_ubsan_clean_room#c_banhih) **Source threads** - [lobsters](https://lobste.rs/s/7txupx/introduction_ubsan_clean_room) · 11 points · 11 comments - [hackernews](https://news.ycombinator.com/item?id=17715252) · 182 points · 120 comments ## Similar posts on daily.dev - [NetBSD Blog](https://daily.dev/posts/netbsd-blog-91tulmtsi) · Hacker News · 0 upvotes · 0 comments - [The Sanitizers Handbook: Memory, Initialization, and Races](https://daily.dev/posts/the-sanitizers-handbook-memory-initialization-and-races-3hzwtj43v) · freeCodeCamp · 0 upvotes · 0 comments - [Everything in C is undefined behavior](https://daily.dev/posts/everything-in-c-is-undefined-behavior-lf4o5xfht) · Hacker News · 21 upvotes · 1 comments --- Tags: [#c](https://daily.dev/tags/c), [#kernel-development](https://daily.dev/tags/kernel-development) [View this post on daily.dev](https://daily.dev/posts/introduction-to-ubsan---a-clean-room-reimplementation-of-the-undefined-behavior-sanitizer-runtime-kcqjgqfgz) ```json {"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]} {"@context":"https://schema.org","@type":"TechArticle","headline":"Introduction to µUBSan - a clean-room reimplementation of the Undefined Behavior Sanitizer runtime","url":"https://daily.dev/posts/introduction-to-ubsan---a-clean-room-reimplementation-of-the-undefined-behavior-sanitizer-runtime-kcqjgqfgz","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/introduction-to-ubsan---a-clean-room-reimplementation-of-the-undefined-behavior-sanitizer-runtime-kcqjgqfgz"},"datePublished":"2026-08-12T11:53:43.438Z","dateModified":"2026-08-12T11:54:23.983Z","description":"An in-depth engineering writeup describes µUBSan, a clean-room reimplementation of the Undefined Behavior Sanitizer runtime built from scratch for NetBSD,...","image":"https://media.daily.dev/image/upload/s--0_ODbtD2--/f_auto/v1722860399/public/Placeholder%2008","thumbnailUrl":"https://media.daily.dev/image/upload/s--0_ODbtD2--/f_auto/v1722860399/public/Placeholder%2008","isAccessibleForFree":true,"articleSection":"Lobsters","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"Lobsters","logo":"https://media.daily.dev/image/upload/s--tl8v_Fku--/f_auto,t_logo/v1698841318/logos/lobste.jpg","url":"https://daily.dev/sources/lobsters"},"commentCount":0,"discussionUrl":"https://daily.dev/posts/introduction-to-ubsan---a-clean-room-reimplementation-of-the-undefined-behavior-sanitizer-runtime-kcqjgqfgz","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":0},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":0}],"keywords":"c,kernel-development","timeRequired":"PT20M"} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"Lobsters","item":"https://daily.dev/sources/lobsters"},{"@type":"ListItem","position":3,"name":"Introduction to µUBSan - a clean-room reimplementation of the Undefined Behavior Sanitizer runtime"}]} {"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/introduction-to-ubsan---a-clean-room-reimplementation-of-the-undefined-behavior-sanitizer-runtime-kcqjgqfgz#faq","mainEntity":[{"@type":"Question","name":"Why did NetBSD write its own UBSan runtime instead of using the Clang/LLVM one directly?","acceptedAnswer":{"@type":"Answer","text":"The original Clang/LLVM UBSan runtime is written in C++ with features unavailable in libc and the NetBSD kernel, and the Linux kernel's native C runtime is GPL-licensed and behind upstream in supported checks. NetBSD's µUBSan is a clean-room, BSD-2-clause licensed, single self-contained C file usable in the kernel, libc, and standalone ATF tests without triggering undefined behavior itself. Teams weighing license and portability constraints for low-level tooling can track cases like this on daily.dev."}},{"@type":"Question","name":"Which UBSan check does NetBSD's µUBSan runtime not support?","acceptedAnswer":{"@type":"Answer","text":"µUBSan supports every UBSan report type except -fsanitize=vptr, because vptr requires low-level C++ routines to introspect vtables and dynamic type compatibility, which the C-only runtime deliberately avoids. All other checks are performed in inlined instrumented code, with the runtime mainly handling deserializing reports into messages. Developers evaluating sanitizer coverage gaps can follow deep dives like this on daily.dev."}},{"@type":"Question","name":"How can I enable the Undefined Behavior Sanitizer in the NetBSD kernel?","acceptedAnswer":{"@type":"Answer","text":"Enable the KUBSAN option in the kernel configuration file (for example sys/arch/amd64/conf/GENERIC), uncommenting 'options KUBSAN', then build with './build.sh kernel=GENERIC'. This activates kUBSan, which shares the same µUBSan runtime as the userland version but reports issues via printf(9) or panic(9) instead of stdout/stderr/syslog. Kernel developers configuring sanitizer builds can keep up with setup details like this on daily.dev."}}]} ```