Hi,
We just had a close shave with bpf_jit_limit. Something on our edge
caused us to cross the default limit, which made seccomp and xt_bpf
filters fail to load. Looking at the source made me realise that we
narrowly avoided taking out our load balancer, which would've been
pretty bad. We still run the LB with CAP_SYS_ADMIN instead of narrower
CAP_BPF, CAP_NET_ADMIN. If we had migrated to the lesser capability
set we would've been prevented from loading new eBPF:
int bpf_jit_charge_modmem(u32 pages)
{
if (atomic_long_add_return(pages, &bpf_jit_current) >
(bpf_jit_limit >> PAGE_SHIFT)) {
if (!capable(CAP_SYS_ADMIN)) {
atomic_long_sub(pages, &bpf_jit_current);
return -EPERM;
}
}
return 0;
}
Does it make sense to include !capable(CAP_BPF) in the check?
This limit reminds me a bit of the memlock issue, where a global limit
causes coupling between independent systems / processes. Can we remove
the limit in favour of something more fine grained?
Best
Lorenz
--
Lorenz Bauer | Systems Engineer
6th Floor, County Hall/The Riverside Building, SE1 7PB, UK
www.cloudflare.com
