On an AMD64 based system executing int 1 exceptions across a rex64
sysret, if the debugger sets the trap flag, r11 which holds the eflags
values for the
sysret return from syscall, the flags do not appear to get set
resutling in the int exception nesting by calling sysret over and over
again until the kernel stack
runs off the end. Looks like the resume did not get set on this instruction.
sysret on AMD requires the flags be saved into r11 and what I am
seeing is the flags not matching what has been set in the pt_regs
struct.
Jeff
On Fri, Jul 2, 2010 at 4:18 PM, Jeffrey Merkey <[email protected]> wrote:
> On an AMD64 based system executing int 1 exceptions across a rex64
> sysret, if the debugger sets the trap flag, r11 which holds the eflags
> values for the
> sysret return from syscall, the flags do not appear to get set
> resutling in the int exception nesting by calling sysret over and over
> again until the kernel stack
> runs off the end. ?Looks like the resume did not get set on this instruction.
>
> sysret on AMD requires the flags be saved into r11 and what I am
> seeing is the flags not matching what has been set in the pt_regs
> struct.
>
> Jeff
>
The specific function to look at is in entry_64.S sysret_check. The
sequence goes;
swapgs
rex64 sysret
After swapgs the eflags in r11 do not match the actual flags passed.
The resume flag gets cleared when the sysret instruction completes,
and int 1 keeps firing on that processor until the stack runs out of
space.
Jeff
On Fri, Jul 2, 2010 at 4:18 PM, Jeffrey Merkey <[email protected]> wrote:
> On an AMD64 based system executing int 1 exceptions across a rex64
> sysret, if the debugger sets the trap flag, r11 which holds the eflags
> values for the
> sysret return from syscall, the flags do not appear to get set
> resutling in the int exception nesting by calling sysret over and over
> again until the kernel stack
> runs off the end. ?Looks like the resume did not get set on this instruction.
>
> sysret on AMD requires the flags be saved into r11 and what I am
> seeing is the flags not matching what has been set in the pt_regs
> struct.
>
> Jeff
>
For some reason, zeroing the DR6 register before calling notify_die
makes this problem go away.
Jeff