This version includes some bugfixes, enhancements, and applicable for 2. That is 'officially' supported on Intel's processors. Thus, kprobes jump-optimization can use it. I'd like to push it after this series of patches are merged. Anyway, thanks Mathieu and Peter, for helping me to implement it and organizing discussion points about int3-bypass XMC! These patches can be applied on the latest -tip.
Changes in v9: - Fix a bug to optimize probe when enabling. This will help kprobe-tracer because most of probes on it are usually disabled. So, in some cases, it might not be optimized. Inserts a break-point on a specified address. Inserts a break-point in the specified address. The address needs to be the address of the first instruction of the probed function. When the break-point is hit, the specified handler is run.
The handler should have the same argument list and return type as the probed. Inserts a return probe for the specified function. When the probed function returns, a specified handler is run. This function returns 0 on success, or a negative error number on failure. Removes the specified probe. You can use it any time after the probe has been registered. In recent Linux kernels, the Kprobes instrumentation uses the kernel's debugfs interface.
It can list all registered probes and globally switch all probes on or off. The first column lists the address in the kernel where the probe is inserted. The second column prints the type of the probe: k for kprobe, j for jprobe, and r for return probe. The third column specifies the symbol, offset and optional module name of the probe.
The following optional columns include the status information of the probe. If the probe is inserted on a virtual address which is not valid anymore, it is marked with [GONE]. To turn them off, simply enter. Note that this way you do not change the status of the probes. Kprobes can probe most of the kernel except itself.
This means that there are some functions where kprobes cannot probe. Probing trapping such functions can cause a recursive trap e. Kprobes manages such functions as a blacklist. Kprobes checks the given probe address against the blacklist and rejects registering it, if the given address is in the blacklist.
Any or all handlers can be NULL. The following will now work:. This field is used to calculate the probepoint. Called with p pointing to the kprobe associated with the breakpoint, and regs pointing to the struct containing the registers saved when the breakpoint was hit. Removes the specified probe. The unregister function can be called at any time after the probe has been registered.
If the functions find an incorrect probe ex. Registers each of the num probes in the specified array. You have to allocate or define an array of pointers and set all of the array entries before using these functions. If the functions find some incorrect probes ex. However, other probes in the array are unregistered correctly.
You must specify the probe which has been registered. Kprobes allows multiple probes at the same address. In general, you can install a probe anywhere in the kernel. In particular, you can probe interrupt handlers. Known exceptions are discussed in this section. If you install a probe in an inline-able function, Kprobes makes no attempt to chase down all inline instances of the function and install probes there. A probe handler can modify the environment of the probed function — e.
So Kprobes can be used, for example, to install a bug fix or to inject faults for testing. Kprobes, of course, has no way to distinguish the deliberately injected faults from the accidental ones. Kprobes makes no attempt to prevent probe handlers from stepping on each other — e. As of Linux v2. Probe handlers are run with preemption disabled or interrupt disabled, which depends on the architecture and optimization state.
In any case, your handler should not yield the CPU e. If the number of times a function is called does not match the number of times it returns, registering a return probe on that function may produce undesirable results. In such a case, a line: kretprobe BUG! With this information, one will be able to correlate the exact instance of the kretprobe that caused the problem. If, upon entry to or exit from a function, the CPU is running on a stack other than that of the current task, registering a return probe on that function may produce undesirable results.
To explain it, we introduce some terminology. Imagine a 3-instruction sequence consisting of a two 2-byte instructions and one 3-byte instruction.
0コメント