netdev - Re: [RFC PATCH 0/4] Initial support for allocating BPF JITs in vmalloc for x86

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 linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <730f7250-0b01-e2d5-6253-e15541ad4298@fb.com>
Date:   Wed, 6 Feb 2019 01:40:08 +0000
From:   Alexei Starovoitov <ast@...com>
To:     "Edgecombe, Rick P" <rick.p.edgecombe@...el.com>,
        "daniel@...earbox.net" <daniel@...earbox.net>
CC:     "kristen@...ux.intel.com" <kristen@...ux.intel.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "ard.biesheuvel@...aro.org" <ard.biesheuvel@...aro.org>,
        "Hansen, Dave" <dave.hansen@...el.com>
Subject: Re: [RFC PATCH 0/4] Initial support for allocating BPF JITs in
 vmalloc for x86

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.