4:58 p.m.
I've been puzzling over why the regs formatted with a backtrace on an IA32
dump are invalid. Here's what I mean:
PID: 2692 TASK: f4656630 CPU: 0 COMMAND: "rmmod"
#0 [f463ce54] crash_kexec at c044a1f7
#1 [f463ce9c] die at c040651a
#2 [f463ced4] do_page_fault at c0603107
#3 [f463cf14] error_code (via page_fault) at c060190a
EAX: 00000018 EBX: f8b43400 ECX: f8b4304f EDX: 00200000
DS: 007b ESI: 00000000 ES: 007b EDI: 00000000
SS: 304f ESP: f8b4302b EBP: f463c000
CS: 0060 EIP: f8b43004 ERR: ffffffff EFLAGS: 00210286
They are supposed to represent a valid set of regs that are presented to
do_page_fault, which I presume are meant to be valid at the time the
exception occurred.
Of they can never be a set of valid regs for the simple reason that the
CPL is 0 (CS=60) and the RPL of SS is 3, which is an automatic GPF.
Since I manufactured the exception that caused this dump, by causing an
unrecoverable page fault in ring 0, I known the CS is correct but SS is
bogus.
Furthermore the the error code (ERR), which is stored by the processor as
part of the exception stack frame uses only bits 0-2 for page faults and
at most bits 0-15 for other exceptions, the unused bit positions are zero.
So ERR is also bogus.
On looking at the code in entry.S at page_fault and the other exception
entry points I see no attempt to save regs to create a pt_regs struct. The
fact that do_page_fault takes pt_regs as the first arg is a hack to get at
CS:EIP and SS:ESP at the time of exception. Furthermore error_code loads
the exception error code into edx then wipes it out from the stack by
storing -1 into this location. I can't actually see a good reason for
wiping out the error code. By convention exceptions and interrupts have a
-ve integer stored at the error-code location to distinguish them from
system calls, but I don't think this is used. signal.c seems to be the
only place to look for an error code >=0 but I don't see an exception
affects signal.c
Can anyone confirm whether setting the error code to -1 is essential. If
it isn't then I think we should consider leaving it in place.
The long and short of it is: the only thing that has any meaning is CS,
EIP and EFLAGS. All of which are saved by the processor. SS and ESP are
only saved when the exception occurred at a privilege level >0 but these
can never generate a panic.
I'd recommend that we change the bt output to format only the three valid
regs (possibly SS and ESP, if CPL at time of exception >0). Is there any
reason why this shouldn't be changed?
Richard
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
9:34 a.m.
Richard, the SS is "bogus" because it is NOT saved by the processor unless there
is a privilege level change with the exception, and in this case there was no privilege
change. I think you'll find SS is valid when a fault occurs in user land, resulting in
a priv change as we enter the kernel.
And NO.. I don't want to see a different format for priv-level-change vs
non-priv-level change exceptions and this makes it harder to post process with perl,
etc..
As for error-code, I don't know why it would be replace with -1
- jim
On Tue, 25 Sep 2007 22:58:44 +0100
Richard J Moore <richardj_moore(a)uk.ibm.com> wrote:
I've been puzzling over why the regs formatted with a backtrace
on an IA32
dump are invalid. Here's what I mean:
PID: 2692 TASK: f4656630 CPU: 0 COMMAND: "rmmod"
#0 [f463ce54] crash_kexec at c044a1f7
#1 [f463ce9c] die at c040651a
#2 [f463ced4] do_page_fault at c0603107
#3 [f463cf14] error_code (via page_fault) at c060190a
EAX: 00000018 EBX: f8b43400 ECX: f8b4304f EDX: 00200000
DS: 007b ESI: 00000000 ES: 007b EDI: 00000000
SS: 304f ESP: f8b4302b EBP: f463c000
CS: 0060 EIP: f8b43004 ERR: ffffffff EFLAGS: 00210286
They are supposed to represent a valid set of regs that are presented to
do_page_fault, which I presume are meant to be valid at the time the
exception occurred.
Of they can never be a set of valid regs for the simple reason that the
CPL is 0 (CS=60) and the RPL of SS is 3, which is an automatic GPF.
Since I manufactured the exception that caused this dump, by causing an
unrecoverable page fault in ring 0, I known the CS is correct but SS is
bogus.
Furthermore the the error code (ERR), which is stored by the processor as
part of the exception stack frame uses only bits 0-2 for page faults and
at most bits 0-15 for other exceptions, the unused bit positions are zero.
So ERR is also bogus.
On looking at the code in entry.S at page_fault and the other exception
entry points I see no attempt to save regs to create a pt_regs struct. The
fact that do_page_fault takes pt_regs as the first arg is a hack to get at
CS:EIP and SS:ESP at the time of exception. Furthermore error_code loads
the exception error code into edx then wipes it out from the stack by
storing -1 into this location. I can't actually see a good reason for
wiping out the error code. By convention exceptions and interrupts have a
-ve integer stored at the error-code location to distinguish them from
system calls, but I don't think this is used. signal.c seems to be the
only place to look for an error code >=0 but I don't see an exception
affects signal.c
Can anyone confirm whether setting the error code to -1 is essential. If
it isn't then I think we should consider leaving it in place.
The long and short of it is: the only thing that has any meaning is CS,
EIP and EFLAGS. All of which are saved by the processor. SS and ESP are
only saved when the exception occurred at a privilege level >0 but these
can never generate a panic.
I'd recommend that we change the bt output to format only the three valid
regs (possibly SS and ESP, if CPL at time of exception >0). Is there any
reason why this shouldn't be changed?
Richard
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
10:34 a.m.
crash-utility-bounces(a)redhat.com wrote on 27/09/2007 15:34:47:
Richard, the SS is "bogus" because it is NOT saved by the
processor
unless there is a privilege level change with the exception, and in
this case there was no privilege change. I think you'll find SS is
valid when a fault occurs in user land, resulting in a priv change
as we enter the kernel.
Yes, I know - that's what I said in my original post. But, you will never
see a ring 3 exception stack frame because a ring 3 exception will not
cause a panic and will not trigger a kdump.
It would be rather more useful if meaningful information were formatted
and even better if we saved the error code. And even more useful if during
panic we saved a few of the system regs such as CR2, which would be highly
relevant to page-fault page-fault analysis.
If you want regs, why not go to the beginning of the ring 0 stack where
you'll find a complete and valid set of regs. In this case: further down
the stack we see:
f463ce54: f8b43400 f8b4304f 00200000 00000000 .4..O0.... .....
f463ce64: 00000000 f463c000 00000018 f463007b ......c.....{.c.
f463ce74: 0000007b f46300d8 ffffffff f8b43004 {.....c......0..
f463ce84: 00000060 00210286 f463cf50 00000068 `.....!.P.c.h...
f463ce94: f463cf50 c0690068 c040651f c068854e P.c.h.i..e@.N.h.
f463cea4: 00000068 f463cf50 00000001 f463cf18 h...P.c.......c.
f463ceb4: c0691227 00000000 0000000e 0000000b '.i.............
f463cec4: 00000000 0000f0ff f4656630 00000000 ........0fe.....
f463ced4: c060310c c0691216 00000000 f463cf18 .1`...i.......c.
f463cee4: f7f713f8 f7f713c0 00200246 f463cf18 ........F. ...c.
f463cef4: c0691175 00000000 0000000e 0000000b u.i.............
f463cf04: f8b43400 00000000 c0602d0e f463c000 .4.......-`...c.
f463cf14: c060190c f8b43400 f8b4304f 00200000 ..`..4..O0.... .
f463cf24: 00000000 00000000 f463c000 00000018 ..........c.....
f463cf34: f463007b 0000007b f46300d8 ffffffff {.c.{.....c.....
f463cf44: f8b43004 00000060 00210286 f8b4302b .0..`.....!.+0..
f463cf54: f8b4304f <== base of bogus pt-regs
c0443ab6 00657061 00000002 O0...:D.ape.....
f463cf64: f531f56c 00000002 f447d800 f463cfb8 l.1.......G...c.
f463cf74: c0450dab bf910ab0 00000081 40000003 ..E............@
f463cf84: f4656630 bf9132f8 00000880 f463cfb8 0fe..2........c.
f463cf94: 0063c000 f8b43400 00000880 f463cfa4 ..c..4........c.
f463cfa4: 00000000 bf910ab0 00000003 bf910ab0 ................
f463cfb4: c0404f70 bf910ab0 00000880 bf9132f8 pO@..........2..
f463cfc4: 00000003 bf910ab0 bf913348 ffffffda ........H3......
f463cfd4: 0000007b 0000007b c0600000 00000081 {...{.....`.....
f463cfe4: 00db5402 00000073 00200246 bf910a84 .T..s...F. .....
f463cff4: 0000007b <== base of valis pt-regs
Now this would be useful to format in bt
Here we see that r3 regs prior to entry to the kernel were:
ss:esp 7b:bf910a84 cs:eip 73:00db5402 eflags 00200246
orig_eax: 81 (which tells me that we entered with a call to
sys_delete_module)
fs 0000 es 007b ds 007b eax ffffffda ebp bf913348 edi bf910ab0 esi
00000003
edx bf9132f8 ecx 00000880 ebx bf9100ab0
Had a few of the system regs been logged at panic could have found the
base of the r0 stack
directly from the current TSS via the TR and the GDTR or the MSRs for
SYSENTER. But even so, it's easy to find by searching.
Having got back to the r3 ss:esp we can now unwind the r3 stack:
bf910a84: 00a90f09 00000000 08048d36 bf910ab0 ........6.......
bf910a94: 00000880 bf9132f8 bf910af4 bf910af0 .....2..........
bf910aa4: 00000000 00000000 08048c63 00657061 ........c...ape.
bf910ab4: 00000000 00000000 00000000 00000000 ................
and using vm deduce the string of events from r3 to r0 panic:
VMA START END FLAGS FILE
f51bf470 9a1000 9bc000 875 /lib/ld-2.6.so
f0b3e128 9bc000 9bd000 100871 /lib/ld-2.6.so
f522ef44 9bd000 9be000 100873 /lib/ld-2.6.so
f531f56c 9c0000 b0e000 75 /lib/libc-2.6.so
f51bf3c8 b0e000 b10000 100071 /lib/libc-2.6.so
f531b0d4 b10000 b11000 100073 /lib/libc-2.6.so
f0b3e224 b11000 b14000 100073
f0b3e17c db5000 db6000 4000075
f4e2ab00 8048000 804a000 1875 /sbin/rmmod
f51bf128 804a000 804b000 101873 /sbin/rmmod
f51bf320 88b8000 88d9000 100073
f531f668 b7f8a000 b7f8c000 100073
f51bf374 bf8ff000 bf914000 100173
which was that the user ran the command rmmod ape, etc etc.
I don't think you can deduce any thing useful from the regs are they are
currently formatted. Wouldn't you prefer your perl scripts have access to
a valid set of regs from the true pt_regs struct at the base of the r0
stack?
Richard
And NO.. I don't want to see a different format for priv-level-
change vs non-priv-level change exceptions and this makes it harder
to post process with perl, etc..
As for error-code, I don't know why it would be replace with -1
- jim
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
9:45 a.m.
Richard J Moore wrote:
On looking at the code in entry.S at page_fault and the other
exception
entry points I see no attempt to save regs to create a pt_regs struct.
The fact that do_page_fault takes pt_regs as the first arg is a hack to
get at CS:EIP and SS:ESP at the time of exception.
KPROBE_ENTRY(page_fault)
RING0_EC_FRAME
pushl $do_page_fault
CFI_ADJUST_CFA_OFFSET 4
ALIGN
error_code:
/* the function address is in %fs's slot on the stack */
pushl %es
CFI_ADJUST_CFA_OFFSET 4
/*CFI_REL_OFFSET es, 0*/
pushl %ds
CFI_ADJUST_CFA_OFFSET 4
/*CFI_REL_OFFSET ds, 0*/
pushl %eax
CFI_ADJUST_CFA_OFFSET 4
CFI_REL_OFFSET eax, 0
pushl %ebp
CFI_ADJUST_CFA_OFFSET 4
CFI_REL_OFFSET ebp, 0
pushl %edi
CFI_ADJUST_CFA_OFFSET 4
CFI_REL_OFFSET edi, 0
pushl %esi
CFI_ADJUST_CFA_OFFSET 4
CFI_REL_OFFSET esi, 0
pushl %edx
CFI_ADJUST_CFA_OFFSET 4
CFI_REL_OFFSET edx, 0
pushl %ecx
CFI_ADJUST_CFA_OFFSET 4
CFI_REL_OFFSET ecx, 0
pushl %ebx
CFI_ADJUST_CFA_OFFSET 4
CFI_REL_OFFSET ebx, 0
cld
pushl %fs
CFI_ADJUST_CFA_OFFSET 4
/*CFI_REL_OFFSET fs, 0*/
movl $(__KERNEL_PERCPU), %ecx
movl %ecx, %fs
UNWIND_ESPFIX_STACK
popl %ecx
CFI_ADJUST_CFA_OFFSET -4
/*CFI_REGISTER es, ecx*/
movl PT_FS(%esp), %edi # get the function address
movl PT_ORIG_EAX(%esp), %edx # get the error code
movl $-1, PT_ORIG_EAX(%esp) # no syscall to restart
mov %ecx, PT_FS(%esp)
/*CFI_REL_OFFSET fs, ES*/
movl $(__USER_DS), %ecx
movl %ecx, %ds
movl %ecx, %es
movl %esp,%eax # pt_regs pointer
call *%edi
jmp ret_from_exception
CFI_ENDPROC
KPROBE_END(page_fault)
10:58 a.m.
crash-utility-bounces(a)redhat.com wrote on 27/09/2007 15:45:21:
Richard J Moore wrote:
> On looking at the code in entry.S at page_fault and the other
exception
> entry points I see no attempt to save regs to create a pt_regs
struct.
> The fact that do_page_fault takes pt_regs as the first arg is a
hack
to
> get at CS:EIP and SS:ESP at the time of exception.
KPROBE_ENTRY(page_fault)
RING0_EC_FRAME
pushl $do_page_fault
CFI_ADJUST_CFA_OFFSET 4
ALIGN
error_code:
/* the function address is in %fs's slot on the stack */
pushl %es
CFI_ADJUST_CFA_OFFSET 4
/*CFI_REL_OFFSET es, 0*/
pushl %ds
CFI_ADJUST_CFA_OFFSET 4
/*CFI_REL_OFFSET ds, 0*/
pushl %eax
CFI_ADJUST_CFA_OFFSET 4
CFI_REL_OFFSET eax, 0
pushl %ebp
CFI_ADJUST_CFA_OFFSET 4
CFI_REL_OFFSET ebp, 0
pushl %edi
CFI_ADJUST_CFA_OFFSET 4
CFI_REL_OFFSET edi, 0
pushl %esi
CFI_ADJUST_CFA_OFFSET 4
CFI_REL_OFFSET esi, 0
pushl %edx
CFI_ADJUST_CFA_OFFSET 4
CFI_REL_OFFSET edx, 0
pushl %ecx
CFI_ADJUST_CFA_OFFSET 4
CFI_REL_OFFSET ecx, 0
pushl %ebx
CFI_ADJUST_CFA_OFFSET 4
CFI_REL_OFFSET ebx, 0
cld
pushl %fs
CFI_ADJUST_CFA_OFFSET 4
/*CFI_REL_OFFSET fs, 0*/
movl $(__KERNEL_PERCPU), %ecx
movl %ecx, %fs
UNWIND_ESPFIX_STACK
popl %ecx
CFI_ADJUST_CFA_OFFSET -4
/*CFI_REGISTER es, ecx*/
movl PT_FS(%esp), %edi # get the function address
movl PT_ORIG_EAX(%esp), %edx # get the error code
movl $-1, PT_ORIG_EAX(%esp) # no syscall to restart
mov %ecx, PT_FS(%esp)
/*CFI_REL_OFFSET fs, ES*/
movl $(__USER_DS), %ecx
movl %ecx, %ds
movl %ecx, %es
movl %esp,%eax # pt_regs pointer
call *%edi
jmp ret_from_exception
CFI_ENDPROC
KPROBE_END(page_fault)
Dave, it looks like error_code: has been change relatively recently. My
source starts:
error_code:
pushl %ds
pushl %eax
xorl %eax,%eax
pushl %ebp
and so on. Clearly not a valid pt_regs struct.
The source I'm working with is from FC5. On your version of the kernel
only the ERR, SS and ESP would be invalid.
What tree is yours taken from?
Richard
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
11:13 a.m.
Richard J Moore wrote:
crash-utility-bounces(a)redhat.com wrote on 27/09/2007 15:45:21:
> Richard J Moore wrote:
>
> > On looking at the code in entry.S at page_fault and the other
exception
> > entry points I see no attempt to save regs to create a pt_regs struct.
> > The fact that do_page_fault takes pt_regs as the first arg is a
hack to
> > get at CS:EIP and SS:ESP at the time of exception.
>
> KPROBE_ENTRY(page_fault)
> RING0_EC_FRAME
> pushl $do_page_fault
> CFI_ADJUST_CFA_OFFSET 4
> ALIGN
> error_code:
> /* the function address is in %fs's slot on the stack */
> pushl %es
> CFI_ADJUST_CFA_OFFSET 4
> /*CFI_REL_OFFSET es, 0*/
> pushl %ds
> CFI_ADJUST_CFA_OFFSET 4
> /*CFI_REL_OFFSET ds, 0*/
> pushl %eax
> CFI_ADJUST_CFA_OFFSET 4
> CFI_REL_OFFSET eax, 0
> pushl %ebp
> CFI_ADJUST_CFA_OFFSET 4
> CFI_REL_OFFSET ebp, 0
> pushl %edi
> CFI_ADJUST_CFA_OFFSET 4
> CFI_REL_OFFSET edi, 0
> pushl %esi
> CFI_ADJUST_CFA_OFFSET 4
> CFI_REL_OFFSET esi, 0
> pushl %edx
> CFI_ADJUST_CFA_OFFSET 4
> CFI_REL_OFFSET edx, 0
> pushl %ecx
> CFI_ADJUST_CFA_OFFSET 4
> CFI_REL_OFFSET ecx, 0
> pushl %ebx
> CFI_ADJUST_CFA_OFFSET 4
> CFI_REL_OFFSET ebx, 0
> cld
> pushl %fs
> CFI_ADJUST_CFA_OFFSET 4
> /*CFI_REL_OFFSET fs, 0*/
> movl $(__KERNEL_PERCPU), %ecx
> movl %ecx, %fs
> UNWIND_ESPFIX_STACK
> popl %ecx
> CFI_ADJUST_CFA_OFFSET -4
> /*CFI_REGISTER es, ecx*/
> movl PT_FS(%esp), %edi # get the function address
> movl PT_ORIG_EAX(%esp), %edx # get the error code
> movl $-1, PT_ORIG_EAX(%esp) # no syscall to restart
> mov %ecx, PT_FS(%esp)
> /*CFI_REL_OFFSET fs, ES*/
> movl $(__USER_DS), %ecx
> movl %ecx, %ds
> movl %ecx, %es
> movl %esp,%eax # pt_regs pointer
> call *%edi
> jmp ret_from_exception
> CFI_ENDPROC
> KPROBE_END(page_fault)
>
Dave, it looks like error_code: has been change relatively recently. My
source starts:
error_code:
pushl %ds
pushl %eax
xorl %eax,%eax
pushl %ebp
and so on. Clearly not a valid pt_regs struct.
The source I'm working with is from FC5. On your version of the kernel
only the ERR, SS and ESP would be invalid.
What tree is yours taken from?
My example was from upstream 2.6.22-5. RHEL5 (2.6.18-based)
is slightly different, as the "error_code:" chunk is located
in the "divide_error" entry point, but like 2.6.22-5, all of
the other exceptions jmp to it.
But even your code is creating the remainder of the pt_regs
after the essential registers laid down by the hardware
exception mechanism, by pushing the remaining registers,
"upwards" towards the beginning of the structure:
struct pt_regs {
long ebx;
long ecx;
long edx;
long esi;
long edi;
long ebp;
long eax;
int xds;
int xes;
long orig_eax;
long eip;
int xcs;
long eflags;
long esp;
int xss;
};
Right?
Dave
1:44 p.m.
crash-utility-bounces(a)redhat.com wrote on 27/09/2007 17:13:45:
Richard J Moore wrote:
>
> crash-utility-bounces(a)redhat.com wrote on 27/09/2007 15:45:21:
>
> > Richard J Moore wrote:
> >
> > > On looking at the code in entry.S at page_fault and the other
> exception
> > > entry points I see no attempt to save regs to create a pt_regs
struct.
> > > The fact that do_page_fault takes pt_regs as the
first arg is a
> hack to
> > > get at CS:EIP and SS:ESP at the time of exception.
> >
> > KPROBE_ENTRY(page_fault)
> > RING0_EC_FRAME
> > pushl $do_page_fault
> > CFI_ADJUST_CFA_OFFSET 4
> > ALIGN
> > error_code:
> > /* the function address is in %fs's slot on the stack */
> > pushl %es
> > CFI_ADJUST_CFA_OFFSET 4
> > /*CFI_REL_OFFSET es, 0*/
> > pushl %ds
> > CFI_ADJUST_CFA_OFFSET 4
> > /*CFI_REL_OFFSET ds, 0*/
> > pushl %eax
> > CFI_ADJUST_CFA_OFFSET 4
> > CFI_REL_OFFSET eax, 0
> > pushl %ebp
> > CFI_ADJUST_CFA_OFFSET 4
> > CFI_REL_OFFSET ebp, 0
> > pushl %edi
> > CFI_ADJUST_CFA_OFFSET 4
> > CFI_REL_OFFSET edi, 0
> > pushl %esi
> > CFI_ADJUST_CFA_OFFSET 4
> > CFI_REL_OFFSET esi, 0
> > pushl %edx
> > CFI_ADJUST_CFA_OFFSET 4
> > CFI_REL_OFFSET edx, 0
> > pushl %ecx
> > CFI_ADJUST_CFA_OFFSET 4
> > CFI_REL_OFFSET ecx, 0
> > pushl %ebx
> > CFI_ADJUST_CFA_OFFSET 4
> > CFI_REL_OFFSET ebx, 0
> > cld
> > pushl %fs
> > CFI_ADJUST_CFA_OFFSET 4
> > /*CFI_REL_OFFSET fs, 0*/
> > movl $(__KERNEL_PERCPU), %ecx
> > movl %ecx, %fs
> > UNWIND_ESPFIX_STACK
> > popl %ecx
> > CFI_ADJUST_CFA_OFFSET -4
> > /*CFI_REGISTER es, ecx*/
> > movl PT_FS(%esp), %edi # get the function address
> > movl PT_ORIG_EAX(%esp), %edx # get the error code
> > movl $-1, PT_ORIG_EAX(%esp) # no syscall to restart
> > mov %ecx, PT_FS(%esp)
> > /*CFI_REL_OFFSET fs, ES*/
> > movl $(__USER_DS), %ecx
> > movl %ecx, %ds
> > movl %ecx, %es
> > movl %esp,%eax # pt_regs pointer
> > call *%edi
> > jmp ret_from_exception
> > CFI_ENDPROC
> > KPROBE_END(page_fault)
> >
>
> Dave, it looks like error_code: has been change relatively recently.
My
> source starts:
> error_code:
> pushl %ds
> pushl %eax
> xorl %eax,%eax
> pushl %ebp
>
> and so on. Clearly not a valid pt_regs struct.
> The source I'm working with is from FC5. On your version of the kernel
> only the ERR, SS and ESP would be invalid.
> What tree is yours taken from?
>
My example was from upstream 2.6.22-5. RHEL5 (2.6.18-based)
is slightly different, as the "error_code:" chunk is located
in the "divide_error" entry point, but like 2.6.22-5, all of
the other exceptions jmp to it.
But even your code is creating the remainder of the pt_regs
after the essential registers laid down by the hardware
exception mechanism, by pushing the remaining registers,
"upwards" towards the beginning of the structure:
struct pt_regs {
long ebx;
long ecx;
long edx;
long esi;
long edi;
long ebp;
long eax;
int xds;
int xes;
long orig_eax;
long eip;
int xcs;
long eflags;
long esp;
int xss;
};
Right?
Dave
I don't think so. Am I misreading this:
we take a page fault at ring 0. The cpu pushes eflags, cs, eip, error-code
we enter the kernel at:
ENTRY(page_fault)
pushl $do_page_fault
jmp error_code
we have errror code in orig_eax
error_code:
pushl %ds
pushl %eax
xorl %eax, %eax
pushl %ebp
pushl %edi
pushl %esi
pushl %edx
decl %eax # eax = -1
pushl %ecx
pushl %ebx
cld
pushl %es
UNWIND_ESPFIX_STACK
popl %ecx
movl ES(%esp), %edi # get the function address
movl ORIG_EAX(%esp), %edx # get the error code
movl %eax, ORIG_EAX(%esp)
movl %ecx, ES(%esp)
movl $(__USER_DS), %ecx
movl %ecx, %ds
movl %ecx, %es
movl %esp,%eax # pt_regs pointer
call *%edi
jmp ret_from_exception
Aren't we sorting ds in the pt_regs.ES ? and therefore one register out?
Maybe I'm missing something?
Richard
--
Crash-utility mailing list
Crash-utility(a)redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
2:03 p.m.
Richard J Moore wrote:
crash-utility-bounces(a)redhat.com wrote on 27/09/2007 17:13:45:
> Richard J Moore wrote:
> >
> > crash-utility-bounces(a)redhat.com wrote on 27/09/2007 15:45:21:
> >
> > > Richard J Moore wrote:
> > >
> > > > On looking at the code in entry.S at page_fault and the other
> > exception
> > > > entry points I see no attempt to save regs to create a pt_regs
struct.
> > > > The fact that do_page_fault takes pt_regs as the first arg is a
> > hack to
> > > > get at CS:EIP and SS:ESP at the time of exception.
> > >
> > > KPROBE_ENTRY(page_fault)
> > > RING0_EC_FRAME
> > > pushl $do_page_fault
> > > CFI_ADJUST_CFA_OFFSET 4
> > > ALIGN
> > > error_code:
> > > /* the function address is in %fs's slot on the stack */
> > > pushl %es
> > > CFI_ADJUST_CFA_OFFSET 4
> > > /*CFI_REL_OFFSET es, 0*/
> > > pushl %ds
> > > CFI_ADJUST_CFA_OFFSET 4
> > > /*CFI_REL_OFFSET ds, 0*/
> > > pushl %eax
> > > CFI_ADJUST_CFA_OFFSET 4
> > > CFI_REL_OFFSET eax, 0
> > > pushl %ebp
> > > CFI_ADJUST_CFA_OFFSET 4
> > > CFI_REL_OFFSET ebp, 0
> > > pushl %edi
> > > CFI_ADJUST_CFA_OFFSET 4
> > > CFI_REL_OFFSET edi, 0
> > > pushl %esi
> > > CFI_ADJUST_CFA_OFFSET 4
> > > CFI_REL_OFFSET esi, 0
> > > pushl %edx
> > > CFI_ADJUST_CFA_OFFSET 4
> > > CFI_REL_OFFSET edx, 0
> > > pushl %ecx
> > > CFI_ADJUST_CFA_OFFSET 4
> > > CFI_REL_OFFSET ecx, 0
> > > pushl %ebx
> > > CFI_ADJUST_CFA_OFFSET 4
> > > CFI_REL_OFFSET ebx, 0
> > > cld
> > > pushl %fs
> > > CFI_ADJUST_CFA_OFFSET 4
> > > /*CFI_REL_OFFSET fs, 0*/
> > > movl $(__KERNEL_PERCPU), %ecx
> > > movl %ecx, %fs
> > > UNWIND_ESPFIX_STACK
> > > popl %ecx
> > > CFI_ADJUST_CFA_OFFSET -4
> > > /*CFI_REGISTER es, ecx*/
> > > movl PT_FS(%esp), %edi # get the function address
> > > movl PT_ORIG_EAX(%esp), %edx # get the error code
> > > movl $-1, PT_ORIG_EAX(%esp) # no syscall to restart
> > > mov %ecx, PT_FS(%esp)
> > > /*CFI_REL_OFFSET fs, ES*/
> > > movl $(__USER_DS), %ecx
> > > movl %ecx, %ds
> > > movl %ecx, %es
> > > movl %esp,%eax # pt_regs pointer
> > > call *%edi
> > > jmp ret_from_exception
> > > CFI_ENDPROC
> > > KPROBE_END(page_fault)
> > >
> >
> > Dave, it looks like error_code: has been change relatively
recently. My
> > source starts:
> > error_code:
> > pushl %ds
> > pushl %eax
> > xorl %eax,%eax
> > pushl %ebp
> >
> > and so on. Clearly not a valid pt_regs struct.
> > The source I'm working with is from FC5. On your version of the kernel
> > only the ERR, SS and ESP would be invalid.
> > What tree is yours taken from?
> >
>
> My example was from upstream 2.6.22-5. RHEL5 (2.6.18-based)
> is slightly different, as the "error_code:" chunk is located
> in the "divide_error" entry point, but like 2.6.22-5, all of
> the other exceptions jmp to it.
>
> But even your code is creating the remainder of the pt_regs
> after the essential registers laid down by the hardware
> exception mechanism, by pushing the remaining registers,
> "upwards" towards the beginning of the structure:
>
> struct pt_regs {
> long ebx;
> long ecx;
> long edx;
> long esi;
> long edi;
> long ebp;
> long eax;
> int xds;
> int xes;
> long orig_eax;
> long eip;
> int xcs;
> long eflags;
> long esp;
> int xss;
> };
>
> Right?
>
> Dave
>
I don't think so. Am I misreading this:
we take a page fault at ring 0. The cpu pushes eflags, cs, eip, error-code
we enter the kernel at:
ENTRY(page_fault)
pushl $do_page_fault
jmp error_code
we have errror code in orig_eax
error_code:
pushl %ds
pushl %eax
xorl %eax, %eax
pushl %ebp
pushl %edi
pushl %esi
pushl %edx
decl %eax # eax = -1
pushl %ecx
pushl %ebx
cld
pushl %es
UNWIND_ESPFIX_STACK
popl %ecx
movl ES(%esp), %edi # get the function address
movl ORIG_EAX(%esp), %edx # get the error code
movl %eax, ORIG_EAX(%esp)
movl %ecx, ES(%esp)
movl $(__USER_DS), %ecx
movl %ecx, %ds
movl %ecx, %es
movl %esp,%eax # pt_regs pointer
call *%edi
jmp ret_from_exception
Aren't we sorting ds in the pt_regs.ES ? and therefore one register out?
Maybe I'm missing something?
This code piece does seem to change from version to version,
but I think it gets the ES register into the proper pt_regs
location by pushing it here:
pushl %es
and then popping it into %ecx here:
popl %ecx
and then later storing it in the pt_regs here:
movl %ecx, ES(%esp)
I think...
Dave
2:13 p.m.
Dave Anderson wrote:
Richard J Moore wrote:
>
>
> crash-utility-bounces(a)redhat.com wrote on 27/09/2007 17:13:45:
>
> > Richard J Moore wrote:
> > >
> > > crash-utility-bounces(a)redhat.com wrote on 27/09/2007 15:45:21:
> > >
> > > > Richard J Moore wrote:
> > > >
> > > > > On looking at the code in entry.S at page_fault and the other
> > > exception
> > > > > entry points I see no attempt to save regs to create a
> pt_regs struct.
> > > > > The fact that do_page_fault takes pt_regs as the first arg is
a
> > > hack to
> > > > > get at CS:EIP and SS:ESP at the time of exception.
> > > >
> > > > KPROBE_ENTRY(page_fault)
> > > > RING0_EC_FRAME
> > > > pushl $do_page_fault
> > > > CFI_ADJUST_CFA_OFFSET 4
> > > > ALIGN
> > > > error_code:
> > > > /* the function address is in %fs's slot on the stack */
> > > > pushl %es
> > > > CFI_ADJUST_CFA_OFFSET 4
> > > > /*CFI_REL_OFFSET es, 0*/
> > > > pushl %ds
> > > > CFI_ADJUST_CFA_OFFSET 4
> > > > /*CFI_REL_OFFSET ds, 0*/
> > > > pushl %eax
> > > > CFI_ADJUST_CFA_OFFSET 4
> > > > CFI_REL_OFFSET eax, 0
> > > > pushl %ebp
> > > > CFI_ADJUST_CFA_OFFSET 4
> > > > CFI_REL_OFFSET ebp, 0
> > > > pushl %edi
> > > > CFI_ADJUST_CFA_OFFSET 4
> > > > CFI_REL_OFFSET edi, 0
> > > > pushl %esi
> > > > CFI_ADJUST_CFA_OFFSET 4
> > > > CFI_REL_OFFSET esi, 0
> > > > pushl %edx
> > > > CFI_ADJUST_CFA_OFFSET 4
> > > > CFI_REL_OFFSET edx, 0
> > > > pushl %ecx
> > > > CFI_ADJUST_CFA_OFFSET 4
> > > > CFI_REL_OFFSET ecx, 0
> > > > pushl %ebx
> > > > CFI_ADJUST_CFA_OFFSET 4
> > > > CFI_REL_OFFSET ebx, 0
> > > > cld
> > > > pushl %fs
> > > > CFI_ADJUST_CFA_OFFSET 4
> > > > /*CFI_REL_OFFSET fs, 0*/
> > > > movl $(__KERNEL_PERCPU), %ecx
> > > > movl %ecx, %fs
> > > > UNWIND_ESPFIX_STACK
> > > > popl %ecx
> > > > CFI_ADJUST_CFA_OFFSET -4
> > > > /*CFI_REGISTER es, ecx*/
> > > > movl PT_FS(%esp), %edi # get the function address
> > > > movl PT_ORIG_EAX(%esp), %edx # get the error code
> > > > movl $-1, PT_ORIG_EAX(%esp) # no syscall to restart
> > > > mov %ecx, PT_FS(%esp)
> > > > /*CFI_REL_OFFSET fs, ES*/
> > > > movl $(__USER_DS), %ecx
> > > > movl %ecx, %ds
> > > > movl %ecx, %es
> > > > movl %esp,%eax # pt_regs pointer
> > > > call *%edi
> > > > jmp ret_from_exception
> > > > CFI_ENDPROC
> > > > KPROBE_END(page_fault)
> > > >
> > >
> > > Dave, it looks like error_code: has been change relatively
> recently. My
> > > source starts:
> > > error_code:
> > > pushl %ds
> > > pushl %eax
> > > xorl %eax,%eax
> > > pushl %ebp
> > > > > and so on. Clearly not a valid pt_regs struct.
> > > The source I'm working with is from FC5. On your version of the
> kernel
> > > only the ERR, SS and ESP would be invalid.
> > > What tree is yours taken from?
> > >
> >
> > My example was from upstream 2.6.22-5. RHEL5 (2.6.18-based)
> > is slightly different, as the "error_code:" chunk is located
> > in the "divide_error" entry point, but like 2.6.22-5, all of
> > the other exceptions jmp to it.
> >
> > But even your code is creating the remainder of the pt_regs
> > after the essential registers laid down by the hardware
> > exception mechanism, by pushing the remaining registers,
> > "upwards" towards the beginning of the structure:
> >
> > struct pt_regs {
> > long ebx;
> > long ecx;
> > long edx;
> > long esi;
> > long edi;
> > long ebp;
> > long eax;
> > int xds;
> > int xes;
> > long orig_eax;
> > long eip;
> > int xcs;
> > long eflags;
> > long esp;
> > int xss;
> > };
> >
> > Right?
> >
> > Dave
> >
>
> I don't think so. Am I misreading this:
>
> we take a page fault at ring 0. The cpu pushes eflags, cs, eip,
> error-code
> we enter the kernel at:
> ENTRY(page_fault)
> pushl $do_page_fault
> jmp error_code
>
> we have errror code in orig_eax
>
>
> error_code:
> pushl %ds
> pushl %eax
> xorl %eax, %eax
> pushl %ebp
> pushl %edi
> pushl %esi
> pushl %edx
> decl %eax # eax = -1
> pushl %ecx
> pushl %ebx
> cld
> pushl %es
> UNWIND_ESPFIX_STACK
> popl %ecx
> movl ES(%esp), %edi # get the function address
> movl ORIG_EAX(%esp), %edx # get the error code
> movl %eax, ORIG_EAX(%esp)
> movl %ecx, ES(%esp)
> movl $(__USER_DS), %ecx
> movl %ecx, %ds
> movl %ecx, %es
> movl %esp,%eax # pt_regs pointer
> call *%edi
> jmp ret_from_exception
>
>
> Aren't we sorting ds in the pt_regs.ES ? and therefore one register out?
>
> Maybe I'm missing something?
This code piece does seem to change from version to version,
but I think it gets the ES register into the proper pt_regs
location by pushing it here:
> pushl %es
and then popping it into %ecx here:
> popl %ecx
and then later storing it in the pt_regs here:
> movl %ecx, ES(%esp)
I think...
Yeah -- that's exactly it, before jumping to error_code,
it pushes the address of the fault handler onto the stack,
essentially into the "pt_regs.xes" location:
> ENTRY(page_fault)
> pushl $do_page_fault
> jmp error_code
Then it pushes the remaining pt_regs register values,
but with the pt_regs.xes still needing to be set up.
So then later after the popl of the ES value into %ecx,
it grabs the exception handler address from the pt_regs.xes
location, and puts it into %edi:
> popl %ecx
> movl ES(%esp), %edi # get the function address
and then puts the ES value from %ecx into the pt_regs location:
> movl %ecx, ES(%esp)
and later calls the handler:
> call *%edi
Dave
4:51 p.m.
crash-utility-bounces(a)redhat.com wrote on 27/09/2007 20:03:24:
Richard J Moore wrote:
>
>
> crash-utility-bounces(a)redhat.com wrote on 27/09/2007 17:13:45:
>
> > Richard J Moore wrote:
> > >
> > > crash-utility-bounces(a)redhat.com wrote on 27/09/2007 15:45:21:
> > >
> > > > Richard J Moore wrote:
> > > >
> > > > > On looking at the code in entry.S at page_fault and the
other
> > > exception
> > > > > entry points I see no attempt to save regs to create a
pt_regs
> struct.
> > > > > The fact that do_page_fault takes pt_regs as the first arg
is a
> > > hack to
> > > > > get at CS:EIP and SS:ESP at the time of exception.
> > > >
> > > > KPROBE_ENTRY(page_fault)
> > > > RING0_EC_FRAME
> > > > pushl $do_page_fault
> > > > CFI_ADJUST_CFA_OFFSET 4
> > > > ALIGN
> > > > error_code:
> > > > /* the function address is in %fs's slot on the stack */
> > > > pushl %es
> > > > CFI_ADJUST_CFA_OFFSET 4
> > > > /*CFI_REL_OFFSET es, 0*/
> > > > pushl %ds
> > > > CFI_ADJUST_CFA_OFFSET 4
> > > > /*CFI_REL_OFFSET ds, 0*/
> > > > pushl %eax
> > > > CFI_ADJUST_CFA_OFFSET 4
> > > > CFI_REL_OFFSET eax, 0
> > > > pushl %ebp
> > > > CFI_ADJUST_CFA_OFFSET 4
> > > > CFI_REL_OFFSET ebp, 0
> > > > pushl %edi
> > > > CFI_ADJUST_CFA_OFFSET 4
> > > > CFI_REL_OFFSET edi, 0
> > > > pushl %esi
> > > > CFI_ADJUST_CFA_OFFSET 4
> > > > CFI_REL_OFFSET esi, 0
> > > > pushl %edx
> > > > CFI_ADJUST_CFA_OFFSET 4
> > > > CFI_REL_OFFSET edx, 0
> > > > pushl %ecx
> > > > CFI_ADJUST_CFA_OFFSET 4
> > > > CFI_REL_OFFSET ecx, 0
> > > > pushl %ebx
> > > > CFI_ADJUST_CFA_OFFSET 4
> > > > CFI_REL_OFFSET ebx, 0
> > > > cld
> > > > pushl %fs
> > > > CFI_ADJUST_CFA_OFFSET 4
> > > > /*CFI_REL_OFFSET fs, 0*/
> > > > movl $(__KERNEL_PERCPU), %ecx
> > > > movl %ecx, %fs
> > > > UNWIND_ESPFIX_STACK
> > > > popl %ecx
> > > > CFI_ADJUST_CFA_OFFSET -4
> > > > /*CFI_REGISTER es, ecx*/
> > > > movl PT_FS(%esp), %edi # get the function address
> > > > movl PT_ORIG_EAX(%esp), %edx # get the error code
> > > > movl $-1, PT_ORIG_EAX(%esp) # no syscall to restart
> > > > mov %ecx, PT_FS(%esp)
> > > > /*CFI_REL_OFFSET fs, ES*/
> > > > movl $(__USER_DS), %ecx
> > > > movl %ecx, %ds
> > > > movl %ecx, %es
> > > > movl %esp,%eax # pt_regs pointer
> > > > call *%edi
> > > > jmp ret_from_exception
> > > > CFI_ENDPROC
> > > > KPROBE_END(page_fault)
> > > >
> > >
> > > Dave, it looks like error_code: has been change relatively
> recently. My
> > > source starts:
> > > error_code:
> > > pushl %ds
> > > pushl %eax
> > > xorl %eax,%eax
> > > pushl %ebp
> > >
> > > and so on. Clearly not a valid pt_regs struct.
> > > The source I'm working with is from FC5. On your version of the
kernel
> > > only the ERR, SS and ESP would be invalid.
> > > What tree is yours taken from?
> > >
> >
> > My example was from upstream 2.6.22-5. RHEL5 (2.6.18-based)
> > is slightly different, as the "error_code:" chunk is located
> > in the "divide_error" entry point, but like 2.6.22-5, all of
> > the other exceptions jmp to it.
> >
> > But even your code is creating the remainder of the pt_regs
> > after the essential registers laid down by the hardware
> > exception mechanism, by pushing the remaining registers,
> > "upwards" towards the beginning of the structure:
> >
> > struct pt_regs {
> > long ebx;
> > long ecx;
> > long edx;
> > long esi;
> > long edi;
> > long ebp;
> > long eax;
> > int xds;
> > int xes;
> > long orig_eax;
> > long eip;
> > int xcs;
> > long eflags;
> > long esp;
> > int xss;
> > };
> >
> > Right?
> >
> > Dave
> >
>
> I don't think so. Am I misreading this:
>
> we take a page fault at ring 0. The cpu pushes eflags, cs, eip,
error-code
> we enter the kernel at:
> ENTRY(page_fault)
> pushl $do_page_fault
> jmp error_code
>
> we have errror code in orig_eax
>
>
> error_code:
> pushl %ds
> pushl %eax
> xorl %eax, %eax
> pushl %ebp
> pushl %edi
> pushl %esi
> pushl %edx
> decl %eax # eax = -1
> pushl %ecx
> pushl %ebx
> cld
> pushl %es
> UNWIND_ESPFIX_STACK
> popl %ecx
> movl ES(%esp), %edi # get the function address
> movl ORIG_EAX(%esp), %edx # get the error code
> movl %eax, ORIG_EAX(%esp)
> movl %ecx, ES(%esp)
> movl $(__USER_DS), %ecx
> movl %ecx, %ds
> movl %ecx, %es
> movl %esp,%eax # pt_regs pointer
> call *%edi
> jmp ret_from_exception
>
>
> Aren't we sorting ds in the pt_regs.ES ? and therefore one register
out?
>
> Maybe I'm missing something?
This code piece does seem to change from version to version,
but I think it gets the ES register into the proper pt_regs
location by pushing it here:
> pushl %es
and then popping it into %ecx here:
> popl %ecx
and then later storing it in the pt_regs here:
> movl %ecx, ES(%esp)
I think...
Dave
Everything is still one word out apart from ES. All this does (I think -
and it is confusing code) is replace DS with ES instead of inserting ES by
moving all the other regs, previously stored, down the stack 4 bytes then
storing ES. I think we are shifted by one register wrt pt_regs from ebx to
xds in the earlier versions of error_code. Certainly the later version of
error_code from 2.6.22 is correct in terms of pt_regs.
But even in that case, ERR is not correct ever and SS:ESP are not correct
for kernel exceptions as formatted in bt. I guess this comes down to a
wrong assumption on my part: that regs formatted by bt were meant to be
the regs at time of exception rather than a verbatim formatting of
pt_regs. The problem is we don't yet have a comprehensive register logout
capability for fatal exceptions. I think there is a case for adding some
additional capability to panic. Especially the saving of the control regs,
the system selector regs, the debug regs and possibly a few MSRs
(sysenter/exit, machine check, debugging )
Richard
--
Crash-utility mailing list
Crash-utility(a)redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
6120
days inactive
6122
days old
devel@lists.crash-utility.osci.io
9 comments
3 participants
participants (3)
-
Dave Anderson -
James Washer -
Richard J Moore