On 2/5/19 5:11 PM, Edgecombe, Rick P wrote: > On Wed, 2019-02-06 at 00:35 +0000, Alexei Starovoitov wrote: >> On 2/5/19 2:50 PM, Rick Edgecombe wrote: >>> This introduces a new capability for BPF program JIT's to be located in >>> vmalloc >>> space on x86_64. This can serve as a backup area for >>> CONFIG_BPF_JIT_ALWAYS_ON in >>> case an unprivileged app uses all of the module space allowed by >>> bpf_jit_limit. >>> >>> In order to allow for calls from the increased distance of vmalloc from >>> kernel/module space, relative calls are emitted as full indirect calls if >>> the >>> maximum relative call distance is exceeded. So the resulting performance of >>> call >>> BPF instructions in this case is similar to the BPF interpreter. >> >> If I read this correctly the patches introduce retpoline overhead >> to direct function call because JITed progs are more than 32-bit apart >> and they're far away only because of dubious security concern ? >> Nack. >> > There really isn't any overhead, because they are only far away if the module > space is full, or the bpf_jit_limit is exceeded for non-admin. So cases today > when insertions would succeed it emits the same code, but cases where the > insertion would fail due to lack of space, it now at least works with the > described performance.
I disagree with the problem statement. x86 classic BPF jit has been around forever and no one complained that _unprivileged_ bpf progs exhaust module space. With bpf_jit_limit we got an extra knob to close this remote possibility of an attack. It's more than enough.
