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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <e3697ab2717d9440da72775a25b83d6193a42ea2.camel@intel.com>
Date:   Wed, 6 Feb 2019 01:11:44 +0000
From:   "Edgecombe, Rick P" <rick.p.edgecombe@...el.com>
To:     "daniel@...earbox.net" <daniel@...earbox.net>,
        "ast@...com" <ast@...com>
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 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.