#
269557 |
|
05-Aug-2014 |
markj |
MFC r267759, r267761
r267759: Fix a couple of bugs on amd64 when fetching probe arguments beyond the first five for probes entered through a UD fault (i.e. FBT probes).
Specifically, handle the fact that dtrace_invop_callsite must be 16 byte-aligned and thus may not immediately follow the call to dtrace_invop() in dtrace_invop_start(). Also fetch register arguments and the stack pointer through a struct trapframe instead of a struct reg.
r267761: Fix some bugs when fetching probe arguments in i386. Firstly ensure that the 4 byte-aligned dtrace_invop_callsite can be found and that it immediately follows the call to dtrace_invop(). Secondly, fix some pointer arithmetic to account for differences between struct i386_frame and illumos' struct frame. Finally, ensure that dtrace_getarg() isn't inlined. It works by following a fixed number of frame pointers to the probe site, so inlining breaks it.
PR: 191260
|
#
227430 |
|
10-Nov-2011 |
rstone |
On i386, fbt probes are implemented by writing an invalid opcode over certain instructions in a function prologue or epilogue. DTrace has a hook into the invalid opcode fault handler that checks whether the fault was due to an probe and if so, runs the DTrace magic.
Upon returning from an invalid opcode fault caused by a probe, DTrace must emulate the instruction that was replaced with the invalid opcode and then return control to the instruction following the invalid opcode.
There were a pair of related bugs in the emulation for the leave instruction. The leave instruction is used to pop off a stack frame prior to returning from a function. The emulation for this instruction must move the trap frame for the invalid opcode fault down the stack to the bottom of the stack frame that is being removed, and then execute an iret.
At two points in this process, the emulation code was storing values above the current value of the stack pointer. This opened up a window in which if we were two take an interrupt, the trap frame for the interrupt would overwrite the values stored on the stack, causing the system to panic later.
The first bug was that at one point the emulation code saves the new value for $esp above the current stack pointer value. The fix is to save this value instead inside of the original trap frame. At this point we do not need the original trap frame so this is safe.
The second bug is that when the emulate code loads $esp from the stack, it points part-way through the new trap frame instead of at its beginning. The emulation code adjusts the stack pointer to the correct value immediately afterwards, but this still leaves a one instruction window in which an interrupt would corrupt this trap frame. Fix this by adjusting the stack frame value before loading it into $esp.
This fixes panics in invop_leave on i386 when using fbt return probes.
Reviewed by: rpaulo, attilio MFC after: 1 week
|