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
