On Tue, 2023-03-21 at 19:23 -0700, Alexei Starovoitov wrote: > On Fri, Mar 17, 2023 at 7:53 AM Roberto Sassu > <roberto.sassu@xxxxxxxxxxxxxxx> wrote: > > From: Roberto Sassu <roberto.sassu@xxxxxxxxxx> > > > > A User Mode Driver (UMD) is a specialization of a User Mode Helper (UMH), > > which runs a user space process from a binary blob, and creates a > > bidirectional pipe, so that the kernel can make a request to that process, > > and the latter provides its response. It is currently used by bpfilter, > > although it does not seem to do any useful work. > > FYI the new home for bpfilter is here: > https://github.com/facebook/bpfilter Thanks. I just ensured that it worked, by doing: getsockopt(fd, SOL_IP, IPT_SO_GET_INFO, &info, &optlen); and accepting IPT_SO_GET_INFO in main.c. > > The problem is, if other users would like to implement a UMD similar to > > bpfilter, they would have to duplicate the code. Instead, make an UMD > > management library and API from the existing bpfilter and sockopt code, > > and move it to common kernel code. > > > > Also, define the software architecture and the main components of the > > library: the UMD Manager, running in the kernel, acting as the frontend > > interface to any user or kernel-originated request; the UMD Loader, also > > running in the kernel, responsible to load the UMD Handler; the UMD > > Handler, running in user space, responsible to handle requests from the UMD > > Manager and to send to it the response. > > That doesn't look like a generic interface for UMD. What would make it more generic? I made the API message format- independent. It has the capability of starting the user space process as required, when there is a communication. > It was a quick hack to get bpfilter off the ground, but certainly > not a generic one. True, it is not generic in the sense that it can accomodate any possible use case. The main goal is to move something that was running in the kernel to user space, with the same isolation guarantees as if the code was executed in the kernel. > > I have two use cases, but for sake of brevity I will propose one. > > > > I would like to add support for PGP keys and signatures in the kernel, so > > that I can extend secure boot to applications, and allow/deny code > > execution based on the signed file digests included in RPM headers. > > > > While I proposed a patch set a while ago (based on a previous work of David > > Howells), the main objection was that the PGP packet parser should not run > > in the kernel. > > > > That makes a perfect example for using a UMD. If the PGP parser is moved to > > user space (UMD Handler), and the kernel (UMD Manager) just instantiates > > the key and verifies the signature on already parsed data, this would > > address the concern. > > I don't think PGP parser belongs to UMD either. > Please do it as a normal user space process and define a proper > protocol for communication between kernel and user space. UMD is better in the sense that it establishes a bidirectional pipe between the kernel and the user space process. With that, there is no need to further restrict the access to a sysfs file, for example. The UMD mechanism is much more effective: the pipe is already established with the right process, whose code was integrity-checked because embedded in the kernel module. In addition to that, I'm using seccomp to further restrict what the user space process can do (read, write, exit, ...). That process cannot open new communication channels, even if corrupted. It is expected to send to the kernel simple data structures, that the kernel can effectively sanitize. The last step to achieve full isolation would be to deny ptrace/kill on the user space process created by the UMD management library so that, in lockdown mode, not even root can interfer with that process. Roberto
