UML for arm64

[Johannes Berg]

On Sat, 2023-06-24 at 22:05 +0200, Benjamin Berg wrote:
> On Sat, 2023-06-24 at 15:15 +0200, Johannes Berg wrote:
> > On Fri, 2023-06-23 at 16:34 -0600, Rob Herring wrote:
> > > 
> > > > 
> > > > Either way, the old patchset will give you a good idea about how it all
> > > > works, the changes are mostly in the details. I am happy to push out a
> > > > new version sooner rather than later if it might help with any efforts
> > > > on your side.
> > > 
> > > From a quick scan, it looks like there's some cleanups in the series
> > > which would be helpful without seccomp parts. One of the initial
> > > issues I've found is UML using older ptrace interfaces which arm64
> > > doesn't implement. PTRACE_GETREGS for example.
> > > 
> > 
> > I don't think that completely gets rid of PTRACE_GETREGS though, and if
> > I remember correctly, we really kind of need that there?
> 
> The SECCOMP code should not need any ptrace at all.
> 

Indeed. For the record, I was referring to "some cleanups in the series"
not getting rid of PTRACE_GETREGS entirely :-)

There are indeed some instances of PTRACE_GETREGS removed in your
patches, however, I believe that they're still needed (in ptrace mode)
after that. If that's true, then it seems like the ptrace mode can't
really be ported to arm64.

Then again, a bunch of the stuff you removed there is for detecting
sysemu support, which is documented to only exist on x86, which I'm not
sure is true because arm64 defines PTRACE_SYSEMU[_SINGLESTEP] and
TIF_SYSCALL_EMU and then the generic ptrace code should actually
implement it?

However, PTRACE_GETREGS is still invoked unconditionally in the
userspace() loop afaict, and thus it can't actually work?


So seems that the best bet for other architectures anyway would be
seccomp mode anyway, since that's pretty well supported across
architectures.

You have some endianness bugs in the BPF code for 64-bit code though, it
only works on little endian ;-)

But there are good reasons to use it anyway, vs. ptrace.

> All it does is
> read/write the mcontext that is generated by the host. I think there
> was just some mangling there to map the basic registers into the format
> that UML expects internally (floating point, SSE, etc. are just copied
> directly though).

Yeah that sounds about right.

> > Though then again it's all been a while, and I only faulted the seccomp
> > mode back in in discussions with Benjamin. Looks like we've found a
> > potentially nicer way to make it secure than his secret-based approach,
> > and in fact in a way that should even make it SMP-safe, at least in
> > theory, obviously a lot of infrastructure is missing to make it SMP in
> > the first place.
> 
> Yeah, the idea with FD passing and CLONE_VM without CLONE_FILES does
> indeed seem very promising both for a secure SECCOMP model and SMP
> support specifically.

I don't believe we'll get SMP support easily one way or the other, but
it's nice to know that seccomp mode won't actively break it :-)

johannes