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

[Johannes Berg]

On Thu, 2026-07-23 at 13:47 +0900, Hajime Tazaki wrote:
> As you see, nommu doesn't mean it cannot have protection (or
> isolation) features (e.g., with some CPU extension etc). that's why I
> said it doesn't have to be (if it is documented).

Yeah, fair, I admit I'm conflating a bit. But even for the real hardware
MPU case, it's not really protecting all of the kernel from userspace,
the MPU protections apply equally to anything the CPU runs.

I'm not aware of any general MMU-less cores that have sort of "privilege
levels", and I couldn't find anything like that in the Linux code
either.

So of course we could build it, it's just software, and it might (though
perhaps not highly likely) even be useful to someone for debugging. I
certainly didn't want to include such highly speculative features in the
code now though.

> > 
> > 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 thought the kernel address is invisible/inaccessible, or isolated
> (somehow) from the userspace code.
> 
> let me check more and get you back here if I have any questions.

Sure.

Actually though what I said before isn't quite right - uml_reserved is
at the end of the UML image binary, so that the actual binary itself
already is not accessible to userspace. All other kernel structures etc.
are though.

Speculating - maybe with some tricks we could get the image binary into
the physmem file, but it doesn't really matter.

It does mean, however, that my concern about the kernel intentionally
sharing some kernel address with userspace in NOMMU was unfounded at
least as far as the testing I did is concerned.

> > 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.
> 
> thanks, it works for me as well.
> Please Cc Lorenzo and Liam as well to the patch (as I have requested
> from them).

Ack. I'll try to send it out later today.

> > 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?
> 
> for the rename, well, Im not sure.

Right, you mentioned elsewhere.

> for the clean up, I agree and wish to help this.

I think I'd really like to pull this code out of the last millennium,
but it's going to be tricky to clean up with other things going on, so I
guess small steps eventually ... we'll see. First things (like this
series) first :)

johannes