[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.20.1705261154550.1902@nanos>
Date: Fri, 26 May 2017 11:56:37 +0200 (CEST)
From: Thomas Gleixner <tglx@...utronix.de>
To: Heiko Carstens <heiko.carstens@...ibm.com>
cc: Kees Cook <keescook@...omium.org>,
"Luis R. Rodriguez" <mcgrof@...nel.org>,
Steven Rostedt <rostedt@...dmis.org>,
LKML <linux-kernel@...r.kernel.org>,
"x86@...nel.org" <x86@...nel.org>,
Masami Hiramatsu <mhiramat@...nel.org>,
Peter Zijlstra <peterz@...radead.org>,
Michael Ellerman <mpe@...erman.id.au>
Subject: Re: [PATCH V2] x86/ftrace: Make sure that ftrace trampolines are
not RWX
On Fri, 26 May 2017, Heiko Carstens wrote:
> On Fri, May 26, 2017 at 09:03:13AM +0200, Thomas Gleixner wrote:
> > > It seems like it really should. That would put it in a single place
> > > and avoid this mistake again in the future. Does module_memfree() have
> > > access to the allocation size, or does that need to get plumbed?
> >
> > No, it doesn't. But the number of instances is pretty limited.
> >
> > Btw, looking at BPF. It allocates memory via module_alloc() which means
> > it's RWX. There is nothing in that BPF code which changes the permissions
> > afterwards ....
>
> For BPF you're probably referring to bpf_jit_binary_alloc()? Permissions
> are changed with bpf_jit_binary_lock_ro() within each architecure backend.
>
> Well, except for powerpc (cc'ed Michael).
The problem starts elsewhere. module_alloc() should not allocate RWX memory
in the first place. It should allocated RW and then the usage sites should
set it to RX when the code is ready to go.
Thanks,
tglx
Powered by blists - more mailing lists