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?
Linus
