lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Tue, 27 Oct 2020 08:14:40 +0100 From: Jesper Dangaard Brouer <brouer@...hat.com> To: Toke Høiland-Jørgensen <toke@...hat.com> Cc: daniel@...earbox.net, ast@...com, bpf@...r.kernel.org, netdev@...r.kernel.org, brouer@...hat.com, Roman Gushchin <guro@...com>, kernel-team@...com Subject: Re: [PATCH bpf] samples/bpf: Set rlimit for memlock to infinity in all samples On Tue, 27 Oct 2020 00:36:23 +0100 Toke Høiland-Jørgensen <toke@...hat.com> wrote: > The memlock rlimit is a notorious source of failure for BPF programs. Most > of the samples just set it to infinity, but a few used a lower limit. The > problem with unconditionally setting a lower limit is that this will also > override the limit if the system-wide setting is *higher* than the limit > being set, which can lead to failures on systems that lock a lot of memory, > but set 'ulimit -l' to unlimited before running a sample. > > One fix for this is to only conditionally set the limit if the current > limit is lower, but it is simpler to just unify all the samples and have > them all set the limit to infinity. > > Signed-off-by: Toke Høiland-Jørgensen <toke@...hat.com> This change basically disable the memlock rlimit system. And this disable method is becoming standard in more and more BPF programs. IMHO using the system-wide memlock rlimit doesn't make sense for BPF. I'm still ACKing the patch, as this seems the only way forward, to ignore and in-practice not use the memlock rlimit. Acked-by: Jesper Dangaard Brouer <brouer@...hat.com> I saw some patches on the list (from Facebook) with a new system for policy limiting memory usage per BPF program or was it mem-cgroup, but I don't think that was ever merged... I would really like to see something replace (and remove) this memlock rlimit dependency. Anyone knows what happened to that effort? -- Best regards, Jesper Dangaard Brouer MSc.CS, Principal Kernel Engineer at Red Hat LinkedIn: http://www.linkedin.com/in/brouer
Powered by blists - more mailing lists