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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Alexei Starovoitov <alexei.starovoitov@xxxxxxxxx> writes:

> 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@xxxxxxxxx> 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.
> 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.

To be 100% clear.  This is not a rejection of the concept of behind
fork_usermode_blob.

I see nothing fundamentally wrong with the concept and I have no problem
sorting out the details and remerging that code when it is ready.

If there is a user of fork_usermode_blob that it should be ready for the
next merge window let's keep the code, and let's come up with some clean
fixes to waiting for a process and for passing a struct file to exec.

If it is simply coming one of these days like moving usb drivers into
userspace let's come back to the concept when we have a user ready to
use it.  What exists today will still be in the git history for people
to find.

Eric




[Index of Archives]     [Linux Samsung SoC]     [Linux Rockchip SoC]     [Linux Actions SoC]     [Linux for Synopsys ARC Processors]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]


  Powered by Linux