On 02/06/2019 02:40 AM, Alexei Starovoitov wrote: > 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.
Agree here, also for cap_sys_admin programs there is kind of unpredictability when we cross the condition that module space is full and thus fall back having to emit retpolines for every call, which *is* overhead and hard to debug behavior wrt performance regression from user pov. So I'd rather have it fail and enlarge the module space instead, for example. Thanks, Daniel
