netdev - Re: [PATCH bpf] bpf: avoid setting bpf insns pages read-only when prog is jited

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] [day] [month] [year] [list]

Date:   Mon, 2 Dec 2019 21:09:47 +0100
From:   Daniel Borkmann <daniel@...earbox.net>
To:     Alexei Starovoitov <alexei.starovoitov@...il.com>
Cc:     Peter Zijlstra <peterz@...radead.org>,
        Eric Dumazet <eric.dumazet@...il.com>,
        Network Development <netdev@...r.kernel.org>,
        bpf <bpf@...r.kernel.org>, "H. Peter Anvin" <hpa@...or.com>
Subject: Re: [PATCH bpf] bpf: avoid setting bpf insns pages read-only when
 prog is jited

On Mon, Dec 02, 2019 at 08:19:45AM -0800, Alexei Starovoitov wrote:
> On Mon, Dec 2, 2019 at 1:17 AM Daniel Borkmann <daniel@...earbox.net> wrote:
> > On Mon, Dec 02, 2019 at 09:30:06AM +0100, Peter Zijlstra wrote:
> > > On Sun, Dec 01, 2019 at 06:49:32PM -0800, Eric Dumazet wrote:
> > >
> > > > Thanks for the link !
> > > >
> > > > Having RO protection as a debug feature would be useful.
> > > >
> > > > I believe we have CONFIG_STRICT_MODULE_RWX (and CONFIG_STRICT_KERNEL_RWX) for that already.
> > > >
> > > > Or are we saying we also want to get rid of them ?
> > >
> > > No, in fact I'm working on making that stronger. We currently still have
> > > a few cases that violate the W^X rule.
> > >
> > > The thing is, when the BPF stuff is JIT'ed, the actual BPF instruction
> > > page is not actually executed at all, so making it RO serves no purpose,
> > > other than to fragment the direct map.
> >
> > Yes exactly, in that case it is only used for dumping the BPF insns back
> > to user space and therefore no need at all to set it RO. (The JITed image
> > however *is* set as RO. - Perhaps there was some confusion given your
> > earlier question.)
> 
> May be we should also flip the default to net.core.bpf_jit_enable=1
> for x86-64 ? and may be arm64 ? These two JITs are well tested
> and maintained.

Seems reasonable given their status and exposure they've had over the years. I
can follow-up on that.

Thanks,
Daniel