On Wed, Jun 10, 2020 at 08:30:31AM +0900, Tetsuo Handa wrote: > On 2020/06/10 7:32, Alexei Starovoitov wrote: > >> You can't start a usermode helper which requires access to filesystems (e.g. ELF loaders, > >> shared libraries) before call_usermodehelper() can start a usermode helper which requires > >> access to filesystems. Under such a restricted condition, what is nice with starting a > >> usermode helper? Programs which can be started under such condition will be quite limited. > >> My question is: why you can't use existing call_usermodehelper() (if you need to call > >> a usermode helper) ? > > > > I think the confusion comes from assumption that usermode blob is a dynamic file that > > needs ld.so, shared libs and rootfs. > > Yes, I assume that usermode blob needs to be able to access the rootfs. > > > This mode is supported by the blob loading > > logic, but it's not a primary use case. It's nice to be able to compile > > that blob with -g and be able to 'gdb -p' into it. > > Where can the gdb come from when the rootfs is not accessible? > > > That works and very > > convenient when it comes to debugging. Compare that to debugging a kernel module! > > Userspace is convenient for debugging, at the cost of robustness (e.g. being killed > by SIGKILL). > > > > > The main mode of bpfilter operation was envisioned as rootfs-less. > > It must work with any init= including busybox. For production the bpfilter > > user mode blob was compiled as static binary with no dependencies. > > I still can't imagine. Compiling a user mode blob as a static binary is possible. > But what does 'It must work with any init=' mean? The use of init= depends on > the rootfs being ready. > > > So there is no path to point to. It should be ready before pid 1 > > will do its first iptables sys_setsockopt. > > There has to be at least the root directory in order to use init= parameter. I think you're still missing that usermode_blob is completely fs-less. It doesn't need any fs to work. > > What does the "pid 1" mean? Why you can't specify your "user mode blob" using init= > parameter and then transfer the control of "pid 1" from your "user mode blob" to > "some program which will do its first iptables sys_setsockopt()" ? because init= is user cmdline and usermode_blob() is used by the kernel feature. they are independent. > > If user reboots the kernel > > with different init= cmdline the bpfilter should still be doing its job. > > Like builtin kernel module. > > Even when rebooting the kernel with different init= cmdline, you have a space for > running your "user mode blob" (e.g. > > init=/path/to/your/user/mode/blob init_after_blob=/path/to/some/program/which/will/do/something/else > > ), don't you? > > There is no need to use call_usermodehelper(), let alone fork_usermode_blob()... Using the same argument there is no need for kernel modules and certainly no need for builtin kernel modules. That back and forth is not going anywhere. Let's table it.
