I'm trying to figure out the magic that's going on in KSTK_EIP
and KSTK_ESP, which are defined as macros in
include/asm-i386/processor.h for a 2.4 kernel. Here are their
definitions below:
#define KSTK_EIP(tsk) (((unsigned long *)(4096 + (unsigned
long)(tsk)))[1019])
#define KSTK_ESP(tsk) (((unsigned long *)(4096 + (unsigned
long)(tsk)))[1022])
I know that the memory allocated to the process to hold its descriptor
and stack by the kernel is two pages. Both of the above macros appear to
go half-way up the allocated memory and then skip to the offsets of 1019
and 1022, respectively, down the allocated memory.
Can someone explain the structure of the memory that these two
macros are accessing? Specifically, where do the 1019 and 1022 offsets
come from? Also, what other things are stored at other offsets? Where is
this stack structure defined?
Thanks you for your help in advance.
On Fri, 2004-11-05 at 16:13 -0700, Hanson, Jonathan M wrote:
> Can someone explain the structure of the memory that these two
> macros are accessing? Specifically, where do the 1019 and 1022 offsets
remember the indexes are in multiples of 32 bit, eg the bottom of the
stack, since it's close to the end of the pagesize...
>> Can someone explain the structure of the memory that these two
>> macros are accessing? Specifically, where do the 1019 and 1022
offsets
>> come from? Also, what other things are stored at other offsets? Where
is
>> this stack structure defined?
> if you treat the second (upper) page of the kernel stack as an array
> of dwords and you realize that the initial kernel (ring-0) stack
pointer
> is set at element 1024 then the top elements look like this after a
ring
> transition:
>
> [1023] ring-3 SS
> [1022] ring-3 ESP
> [1021] ring-3 EFLAGS
> [1020] ring-3 CS
> [1019] ring-3 EIP
>
> the ring-0 ESP is stored in the TSS and the thread structure, and it's
> initialized in arch/i386/kernel/process.c:copy_thread().
Thank you for your reply.
If I dereference the address in 1022 (the ring 3 ESP address) it
does indeed return the value in EBX. I then thought that I could use
this address to feed to dump_thread() since EBX is the first thing in
the pt_regs structure, but that's not correct in this case because the
other registers are definitely incorrect. Shouldn't the ESP value
pointed to by KSTK_ESP() point to the beginning of the pt_regs structure
for the user space application?
> Shouldn't the ESP value pointed to by KSTK_ESP() point to the beginning of
> the pt_regs structure for the user space application?
first of all, anything can be on the userland stack at the time the
app issued a syscall. but you don't have to bother with the userland
stack at all, pt_regs is created on the kernel stack, check out the
SAVE_ALL macro (and its uses) in arch/i386/kernel/entry.S .