HI, On Thu, 2023-06-22 at 22:23 +0200, Richard Weinberger wrote: > [SNIP] > > > At least a lot of the register handling, but that will always be > > somewhat architecture specific. > > > > > ... , so perhaps it'd be easier to start with the seccomp-based model: > > > > > > https://patchwork.ozlabs.org/project/linux-um/list/?series=329466 > > > > > > But that's not really done yet either. > > > > Yes, though I have quite some updates locally that solve the security > > issues (i.e. prevent host syscalls from userspace). So, it does need > > rebasing and I am sure bugfixes, but I think it is getting into a > > pretty good shape overall. > > > > 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. > > I think reviving the seccomp patch set is a good idea in any case. > Maybe it is even a way to allow SMP support.
OK, I'll see about resubmitting the SECCOMP patchset. About SMP support, it is tricky if one wants to do it safely. Doing it in an unsafe way is probably reasonably straight forward as you can simply map multiple stub-data areas into the same process. However, the other threads can read/write memory at the same time, which breaks the entire memory security model that I had in mind for SECCOMP mode. My approach there heavily relies on killing the process *after* it mapped memory without permission, but before this can be exploited. So, I fear no simple and secure SMP support. Having to do host syscalls from the userspace process means that you just cannot have another thread running. And then, you are stuck with multiple processes and the headache and overhead of keeping their memory in sync. I think secure SMP we would need some other new and exciting approach for handling process memory. An example could be a special (memory) file system on the host that explicitly allows setting up page ranges to be transparently shared between files. Benjamin _______________________________________________ linux-um mailing list linux-um@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-um
