On Tue, May 23, 2017, at 10:30 AM, Djalal Harouni wrote: > > Maybe it depends on the cases, a general approach can be too difficult > to handle especially from the security point. Maybe it is better to > identify what operations need what context, and a userspace > service/proxy can act using kthreadd with the right context... at > least the shift to this model has been done for years now in the > mobile industry. Why not drop the upcall model in favor of having userspace monitor events via a (more efficient) protocol and react to them on its own? It's just generally more flexible and avoids all of those issues like replicating the seccomp configuration, etc. Something like inotify/signalfd could be a precedent around having a read()/poll()able fd. /proc/keys-requests ? Then if you create a new user namespace, and open /proc/keys-requests, the kernel will always write to that instead of calling /sbin/request-key.
