Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> writes: > 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? > > Because the problem with this code isn't the "use bpf for netfilter > rules", it's the "run a user mode helper". The execve thing is > actually only incidental, it also ends up being a somewhat interesting > issue wrt namespacing and security (and bootstrapping - I'm not > convinced people want to have a clang bpf compiler in initrd etc). > > So particularly if we accept the fact that we won't necessarily need > all of netfilter converted in general - some will be just translated > entirely independently in user space and not use netfilter at all > (just bpf loaded normally) > > IOW there would potentially only be a (fairly small?) core set that > the kernel would need to be able to handle "natively". > > Am I just blathering? I wish I could answer you. All the code does at this time is connect some ipv4 bpfilter specific setsockopt commands to a usermode helper with a read pipe and a write pipe. The userspace portion does absolutely nothing with those commands. I don't have the foggiest idea what that code hopes to be doing when that code is fully fleshed out. If the goal is to become a backwards compatible compiler from historic netfilter commands to bpf it isn't the craziest design in the world. But that isn't what is implemented today. With no users it just isn't clear what the code needs to be doing so I can't tell what needs to be done to bugs in the code. I can't answer which behaviors do the users care about. Eric
