[RFC PATCH 8/9] um: nommu: add userspace runner processes

[Johannes Berg]

On Wed, 2026-07-22 at 10:30 +0900, Hajime Tazaki wrote:
> I was wondering where kernel address is located in this mode.
> although it doesn't have to be, under nommu, kernel address is located
> in the same address space with all userspace processes in my
> understanding.

Why wouldn't it have to be? If you have a real nommu system, then
there's no MMU, and so it has to be, no? (but see below)

> the kernel address is accessible (danger but it's !MMU) from userspace
> thus __access_ok() always returns 1.  so just wondering what is the
> case with this runner process approach.

It's still the case, in the runner startup I mapped the whole thing into
the runner process(es):

+ map(&r->mm_id, uml_reserved, high_physmem - uml_reserved,
+ UM_PROT_READ | UM_PROT_WRITE | UM_PROT_EXEC, fd, offset);

> a program accessing kernel address may fail (or crash in some case),
> but with the runner it won't ?

It still will, I believe, since it is mapped into the same address
space.

I did consider some other things:

   1. Using clone(CLONE_VM) instead - however that means I cannot use
      the stub as-is, and to work without it requires doing a bunch of
      setup in the runner process(es) - which is mostly equivalent to
      the stub.
      
      I did get this working (at least in seccomp mode, not sure now if
      it worked in ptrace too), but it requires shuffling around and
      duplicating quite a bit more code (e.g. the seccomp setup etc.).
      
      This would've made it more obvious, but has a fairly high code
      cost and no real (other) benefit.
      
   2. Conversely, with this approach, it *is* possible to not map the
      whole kernel into the userspace runners. I didn't try this yet,
      but it shouldn't actually be hard - just adjust the above map()
      call a bit? OK, it's a bit trickier with the VDSO etc.
      
      This would possibly be a benefit for testing, although userspace
      processes still need to be able to reach (and crash) each other
      anyway, so it'd just crash them if they tried to erroneously
      access the kernel.
      
      I don't think this would be very hard to do, but I also didn't
      fully think through the consequences - is the VDSO really the only
      thing the kernel assumes can be accessed?
      
   3. Some real nommu devices have MPUs instead, e.g. CONFIG_ARM_MPU. I
      didn't look into what this actually ends up protecting, but I
      could imagine that e.g. we actually make read-only sections read-
      only, etc. I don't see any general infrastructure for this though,
      and the ARM code (arch/arm/mm/pmsa-v7.c, arch/arm/mm/pmsa-v8.c)
      just seems to set up some static, more or less hard-coded,
      protections. But I didn't really look into that in detail.
      
   4. We could perhaps support XIP? But that's a whole different can of
      worms. Maybe it's not even NOMMU related.


Anyway, I also decided that all of this (except 1, which I discarded as
a design decision to simplify, after prototyping it) could be done as
later additional patches.

I also just realized I didn't really respond fully to your question
about what I want to do with this ... so if you're happy with this set
and I can hopefully get some of the others to review it, then I think
I'll send it as real [PATCH] and we can merge it, and go from there. I
also had some docs (based on yours) that I didn't include here, but that
I should include then.

And then we can see - maybe we want to rename "skas" (after you pointed
out what that really means), maybe we want to more generally clean up or
separate out the code a bit?

johannes