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
| ||
|
Message-Id: <1674629944.vwzovyd4lk.naveen@linux.ibm.com> Date: Wed, 25 Jan 2023 12:39:36 +0530 From: "Naveen N. Rao" <naveen.n.rao@...ux.vnet.ibm.com> To: Masami Hiramatsu <mhiramat@...nel.org> Cc: Akanksha J N <akanksha@...ux.ibm.com>, linux-kernel@...r.kernel.org, linux-kselftest@...r.kernel.org, linux-trace-kernel@...r.kernel.org, rostedt@...dmis.org, shuah@...nel.org Subject: Re: [PATCH] selftests/ftrace: Extend multiple_kprobes.tc to add multiple consecutive probes in a function Hi Masami, Masami Hiramatsu wrote: >> > >> > Yes, please make it separate, this test case is for checking whether >> > the ftrace can define/enable/disable multiple kprobe events. Not for >> > checking kprobe with different types, nor checking interactions among >> > different types of kprobes. >> > >> > (BTW, if you want to test optprobe on x86, you can not put the probes >> > within the jump instruction (+5 bytes). It will unoptimize existing >> > optimized kprobe in that case) >> >> Ok, I can see why we won't be able to optimize any of the probes on x86 >> with this approach. But, we should be able to do so on powerpc and arm, >> the only other architectures supporting OPTPROBES at this time. For x86, >> we may have to extend the test to check kprobes/list. > > Are there any instruction type specific limitation on those arch for > using optprobe? I guess the 'call' (branch with link register) will not > able to be optimized because it leaves the trampoline address on the > stack. Yes, at least on powerpc, we only optimize ALU instructions and do not optimize load/store instructions, among many others. This is the reason we try to put a probe uptil 256 offset into a function in the proposed test, which will almost certainly catch an instruction that can be optimized. > >> >> Crucially, I think trying to place a probe at each byte can still >> exercize interactions across KPROBES_ON_FTRACE and normal kprobes, so >> this test is still a good start. In addition, we get to ensure that >> kprobes infrastructure is rejecting placing probes at non-instruction >> boundaries. > > The interfere between probes can be happen between kprobes and optprobe > (*only on x86*), but not with KPORBES_ON_FTRACE. The ftrace replaced NOP > will be handled as one instruction. Yes. > >> > And do you really need to run "multiple" kprobes at once? >> > I think what you need is 'kprobe_opt_types.tc'. >> >> Yes, enabling those probes is a good stress test to ensure we are only >> accepting valid probe locations. >> >> multiple_kprobe_types.tc ? :) > > Please don't mixed it with the concept of 'multiple' probe test. > It is different that > - kprobes can put probes on each instruction boundary. > - kprobes can allocate and enable multiple probes at the same time. > > What the multiple_kprobes.tc tests is the latter one. > (This is the reason why it chooses different functions so as not to > interfere with each other.) Ok, I was coming from the point of view that both tests end up installing "multiple" kprobes, but I do see your point. How about adding two new tests: 1. The same test as has been proposed in this thread: trying to add a kprobe at every byte within $FUNCTION_FORK upto an offset of 256 bytes. We can probably call it kprobe_insn_boundary.tc 2. A new test to ensure we can add different kprobe types (kprobe_opt_types.tc). This test will need to enable and check if each probe has been optimized or not and needs arch-specific knowledge so that we can take care of x86. Would that be ok? Thanks, Naveen
Powered by blists - more mailing lists