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/