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
| ||
|
Date: Fri, 10 Oct 2014 10:03:18 +0900 From: Masami Hiramatsu <masami.hiramatsu.pt@...achi.com> To: Steven Rostedt <rostedt@...dmis.org> Cc: Josh Poimboeuf <jpoimboe@...hat.com>, Ingo Molnar <mingo@...nel.org>, Namhyung Kim <namhyung@...nel.org>, Linux Kernel Mailing List <linux-kernel@...r.kernel.org>, Ananth N Mavinakayanahalli <ananth@...ibm.com> Subject: Re: Re: [PATCH ftrace/for-next v5 0/5] ftrace, kprobes: Introduce IPMODIFY flag for ftrace_ops to detect conflicts (2014/10/10 0:21), Steven Rostedt wrote: > On Thu, 09 Oct 2014 13:00:59 +0000 > Masami Hiramatsu <masami.hiramatsu.pt@...achi.com> wrote: > >> Hi, >> >> Here is the 5th version of the series of patches which introduces >> IPMODIFY flag for ftrace_ops to detect conflicts of ftrace users >> who can modify regs->ip in their handler. >> >> The previous version is here; >> https://lkml.org/lkml/2014/7/28/13 >> >> This version is basically an update of previous version to the >> latest ftrace tree, and adding a test code to selftest. >> >> Currently, only kprobes can change the regs->ip in the handler, >> but recently kpatch is also want to change it. Moreover, since >> the ftrace itself exported to modules, it might be considerable >> senario. >> >> Here we talked on github. >> https://github.com/dynup/kpatch/issues/47 >> >> To protect modified regs-ip from each other, this series >> introduces FTRACE_OPS_FL_IPMODIFY flag and ftrace now ensures >> the flag can be set on each function entry location. If there >> is someone who already reserve regs->ip on target function >> entry, ftrace_set_filter_ip or register_ftrace_function will >> return -EBUSY. Users must handle that. >> The ftrace_ops with IPMODIFY flag requires at least one >> entry for filter hash, and its notrace_hash must be empty, >> because the IPMODIFY action is very address sensitve and >> user must consider the ip address. >> >> The 3rd patch adds a special reservation of IPMODIFY on the >> jprobed address, since it is the only user who will change >> the regs->ip. Other kprobes do not change it anymore. >> >> Thank you, >> > > Masami, > > Thanks for sending this. I'm going to look at it after Dusseldorf. It's > too late to get it into 3.18, but it looks like a good fit for the work > I have for 3.19. Yeah, I think there is no problem until someone tries to use both ftrace and jprobe on the same target. > Just don't let me forget you sent this :-) Even though I tagged it as > important, I'm sure I'll be tagging a lot of other emails as important > in the next week. OK, I'll ping after the event. > Also, my main test box has finally died. I ordered a new motherboard > (thanks Linus for the suggestion!) and unfortunately it is due to > arrive tomorrow. That's the same day I leave and I don't trust my wife > to install it for me ;-) Oh, that is a bad timing... > This means I can not do my tests that I like to run before adding to > linux-next. OK, so see you in next week :) Thank you, -- Masami HIRAMATSU Software Platform Research Dept. Linux Technology Research Center Hitachi, Ltd., Yokohama Research Laboratory E-mail: masami.hiramatsu.pt@...achi.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists