Fosstodon
NETDEV VIDEOS
Session
improving debuggability of nommu code with UML
Speakers
Hajime Tazaki
Label
Nuts and Bolts
Session Type
Talk
Description
Userspace network stack can be implemented as a port of kernel network stack to userspace (e.g., Linux kernel library). At the cost of less generality, and lack of memory protection/isolation within a single network stack, the performance is a primary benefit of the mechanism. This performance benefit is mainly derived from the single-address space nature of its internal because the send/receive code path can reduce the cost of program/memory context transitions, resulting the improvement of system calls overhead.
In Linux kernel, the single-address space of memory management subsystem can be configured by disabling memory management unit (MMU), CONFIG_MMU=n (or nommu). Historically the configuration is mainly used for embedded devices which does not have an MMU in their processors, but recently it is revisited to support specialized case of virtualization, which a guest only requires a single address space, like the case of userspace network stack.
Although nommu has a unique and an important bit of kernel, several maintainers recently raised a concern that it is hard to maintain the feature because it is hard to test. Linux test project (LTP) dropped NOMMU (uclinux) test cases, which had been broken and not fixed due to lack of maintainers (1). mm subsystem had several regressions with CONFIG_MMU=n which might also be caused due to lack of tests during feature introduction (2*3). Testing platform is available via buildroot image of nommu platforms, even you do not have a real hardware, but it is also hard to maintain toolchains to build code and test images.
We are trying to fix this situation by adding nommu mode to user-mode linux (UML). nommu UML is currently under v14 patchset (*4) and runs with Alpine Linux with additional busybox/musl packages, which we also plan to upstream once kernel inclusion.
Supporting nommu to UML has an several meanings:
- 1) we can utilize it over KUnit testing framework
- 2) it is natively runnable over x86_64 platform, which we can skip toolchain maintenance for the testing
Here are the summary of what we have done.
- nommu option for UML: to execute nommu code of Linux kernel in (x86) userspace
- support KASAN for nommu target
- support executing UML with valgrind (to detect memory errors)
- initial attempt to revert nommu drop patches to LTP
We will briefly highlight above in this talk, and showcases what we can do to more debug-friendly nommu kernel. We will also share several facts gained from local benchmark, bug reproduciblity with KASAN. In addition to that, we will discuss the possible extensions that we plan to do in the future.
*1 https://lore.kernel.org/ltp/20240103015240.1065284-1-pvorel@suse.cz/ *2 https://lore.kernel.org/linux-mm/20241108222834.3625217-1-thehajime@gmail.com/ *3 https://lore.kernel.org/linux-mm/20251218083200.2435789-1-joshua.hahnjy@gmail.com/ *4 https://lore.kernel.org/all/cover.1770170302.git.thehajime@gmail.com/
Recent News
Bronze Sponsor, Common Net
[Tue, 16, Jun. 2026]
Bronze Sponsor, secunet
[Fri, 12, Jun. 2026]
Bronze Sponsor, Red Hat
[Fri, 12, Jun. 2026]
Bronze Sponsor, Mpiric
[Tue, 09, Jun. 2026]
Bronze Sponsor, Viasat
[Mon, 08, Jun. 2026]
Important Dates
| Closing of CFS | June 1st |
| Notification by | June 10th |
| Conference dates | July 13th-16th |