On Sun, Jan 05, 2020 at 10:33:54AM +0900, Andy Lutomirski wrote:
quoted
quoted
On Jan 4, 2020, at 8:03 PM, Justin Capella [off-list ref] wrote:
I'm rather ignorant about this topic but it would make sense to check prior to making executable from a security standpoint wouldn't it? (In support of the (set_memory_ro + set_memory_x)
Maybe, depends if it’s structured in a way that’s actually helpful from a security perspective.
It doesn’t help that set_memory_x and friends are not optimized at all. These functions are very, very, very slow and adversely affect all CPUs.
That was one of the reason it wasn't done in the first.
Also ftrace trampoline break w^x as well.
Not sure what is the plan for ftrace, but for bpf trampoline I'm going to switch
to text_poke (without _bp) once tip bits get merged during next merge window.
Then bpf trampoline will be allocated as ro+x and text_poke will be used instead of memcpy.
On Mon, Jan 06, 2020 at 02:13:18PM -0800, Alexei Starovoitov wrote:
On Sun, Jan 05, 2020 at 10:33:54AM +0900, Andy Lutomirski wrote:
quoted
quoted
quoted
On Jan 4, 2020, at 8:03 PM, Justin Capella [off-list ref] wrote:
I'm rather ignorant about this topic but it would make sense to check prior to making executable from a security standpoint wouldn't it? (In support of the (set_memory_ro + set_memory_x)
Maybe, depends if it’s structured in a way that’s actually helpful from a security perspective.
It doesn’t help that set_memory_x and friends are not optimized at all. These functions are very, very, very slow and adversely affect all CPUs.
That was one of the reason it wasn't done in the first.
Also ftrace trampoline break w^x as well.
Didn't I fix that?
On Tue, Jan 07, 2020 at 10:11:32AM +0100, Peter Zijlstra wrote:
On Mon, Jan 06, 2020 at 02:13:18PM -0800, Alexei Starovoitov wrote:
quoted
On Sun, Jan 05, 2020 at 10:33:54AM +0900, Andy Lutomirski wrote:
quoted
quoted
quoted
On Jan 4, 2020, at 8:03 PM, Justin Capella [off-list ref] wrote:
I'm rather ignorant about this topic but it would make sense to check prior to making executable from a security standpoint wouldn't it? (In support of the (set_memory_ro + set_memory_x)
Maybe, depends if it’s structured in a way that’s actually helpful from a security perspective.
It doesn’t help that set_memory_x and friends are not optimized at all. These functions are very, very, very slow and adversely affect all CPUs.
That was one of the reason it wasn't done in the first.
Also ftrace trampoline break w^x as well.
Didn't I fix that?
yes. in the tip. many months ago. that's why up-thread I was saying that I'm
waiting for all text_poke[_bp] patches to land upstream and do the same thing
for bpf trampoline and bpf dispatcher (which has the same issue).