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

[Greg KH <gregkh@linuxfoundation.org>]

On Mon, Jun 08, 2020 at 09:20:27AM -0700, Alexei Starovoitov wrote:
> On Sat, Jun 06, 2020 at 07:19:56PM -0700, Linus Torvalds wrote:
> > On Sat, Jun 6, 2020 at 6:49 PM Alexei Starovoitov
> > <alexei.starovoitov@gmail.com> wrote:
> > >>
> > > I'm not aware of execve issues. I don't remember being cc-ed on them.
> > > To me this 'lets remove everything' patch comes out of nowhere with
> > > a link to three month old patch as a justification.
> > 
> > Well, it's out of nowhere as far as bpf is concerned, but we've had a
> > fair amount of discussions about execve cleanups (and a fair amount of
> > work too, not just discussion) lately
> > 
> > So it comes out of "execve is rather grotty", and trying to make it
> > simpler have fewer special cases.
> > 
> > > So far we had two attempts at converting netfilter rules to bpf. Both ended up
> > > with user space implementation and short cuts.
> > 
> > So I have a question: are we convinced that doing this "netfilter
> > conversion" in user space is required at all?
> > 
> > I realize that yes, running clang is not something we'd want to do in
> > kernel space, that's not what I'm asking.
> > 
> > But how much might be doable at kernel compile time (run clang to
> > generate bpf statically when building the kernel) together with some
> > simplistic run-time parameterized JITting for the table details that
> > the kernel could do on its own without a real compiler?
> 
> Right. There is no room for large user space application like clang
> in vmlinux. The idea for umh was to stay small and self contained.
> Its advantage vs kernel module is to execute with user privs
> and use normal syscalls to drive kernel instead of export_symbol apis.
> 
> There are two things in this discussion. bpfilter that intercepting
> netfilter sockopt and elf file embedded into vmlinux that executes
> as user process.
> The pro/con of bpfilter approach is hard to argue now because
> bpfilter itself didn't materialize yet. I'm fine with removal of that part
> from the kernel, but I'm still arguing that 'embed elf into vmlinux'
> is necessary, useful and there is no alternative.
> There are builtin kernel modules. 'elf in vmlinux' is similar to that.
> The primary use case is bpf driven features like bpf_lsm.
> bpf_lsm needs to load many different bpf programs, create bpf maps, populate
> them, attach to lsm hooks to make the whole thing ready. That initialization of
> bpf_lsm is currently done after everything booted, but folks want it to be
> active much early. Like other LSMs.
> Take android for example. It can certify vmlinux, but not boot fs image.

Huh?  dm-verity does this for the whole "boot fs partition" already,
right?  Or one of the "dm-" modules...

> vmlinux needs to apply security policy via bpf_lsm during the boot.
> In such case 'embedded elf in vmlinux' would start early, do its thing
> via bpf syscall and exit. Unlike bpfilter approach it won't stay running.
> Its job is to setup all bpf things and quit.
> Theoretically we can do it as proper kernel module, but then it would mean huge
> refactoring of all bpf syscall commands to be accessible from the kernel module.
> It's simpler to embed elf into vmlinux and run it as user process doing normal
> syscalls. I can imagine that in other cases this elf executable would keep
> running after setup.
> It doesn't have to be bpf related. Folks thought they can do usb drivers
> running in user space and ready at boot. 'elf in vmlinux' would work as well.

I still want to work on the "usb drivers in userspace" like this, it's
on my TODO for this year.  But don't let that "sometime in the future
wish" keep this code around if no one is currently using it.

thanks,

greg k-h