[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAADnVQJEqVmwAJ2V9NB+0Udwg5H9KJfCSjuSpARAGHLPuhnA=w@mail.gmail.com>
Date: Mon, 2 Dec 2019 08:19:45 -0800
From: Alexei Starovoitov <alexei.starovoitov@...il.com>
To: Daniel Borkmann <daniel@...earbox.net>
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 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.
Powered by blists - more mailing lists