On Wed, Sep 22, 2021 at 2:51 PM Daniel Borkmann [off-list ref] wrote:

On 9/22/21 1:07 PM, Lorenz Bauer wrote:

quoted

On Wed, 22 Sept 2021 at 09:20, Frank Hofmann [off-list ref] wrote:

quoted

quoted

That jit limit is not there on older kernels and doesn't apply to root.
How would you notice such a kernel bug in such conditions?

I'm talking about bpf_jit_current - it's an "overall gauge" for
allocation, priv and unpriv. I understood Lorenz' note as "change it
so it only tracks unpriv BPF mem usage - since we'll never act on
privileged usage anyway"

Yes, that was my suggestion indeed. What Frank is saying: it looks
like our leak of JIT memory is due to a privileged process. By
exempting privileged processes it would be even harder to notice /
debug. That's true, and brings me back to my question: what is
different about JIT memory that we can't do a better limit?

There is nothing special about JIT and kernel module memory.

The knob with the limit was basically added back then as a band-aid to avoid
unprivileged BPF JIT (cBPF or eBPF) eating up all the module memory to the
point where we cannot even load kernel modules anymore. Given that memory
resource is global, we added the bpf_jit_limit / bpf_jit_current acounting
as a fix/heuristic via ede95a63b5e8 ("bpf: add bpf_jit_limit knob to restrict
unpriv allocations"). If we wouldn't account for root, how would such detection
proposal work otherwise to block unprivileged? I don't think it's feasible to
only account the latter given privileged progs might have occupied most of the
budget already.

Right.
At the end it boils down to module_alloc() is not using GFP_ACCOUNT.
It's indeed very similar to rlimit issue we had in the past.
I don't have a preference whether normal kernel mods should be memcg-ed,
but JITed memory certainly can be.
bpf progs memory is already covered.
I think we can do that and then can remove this limit. Just like rlimit.