Re: [RFC][PATCH] net/bpfilter: Remove this broken and apparently unmantained

[Alexei Starovoitov <alexei.starovoitov@gmail.com>]

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.