lkml.org 
[lkml]   [2006]   [May]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Segfault on the i386 enter instruction
In-Reply-To: <44676F42.7080907@aknet.ru>

On Sun, 14 May 2006 21:56:18 +0400, Stas Sergeev wrote:

> Andi Kleen wrote:
> > Handling it like you expect would require to disassemble
> > the function in the page fault handler and it's probably not
> > worth doing that for this weird case.
> Just wondering, is this case really that weird?
> In fact, the check against %esp that the kernel
> does, looks strange. I realize that it can catch a
> (very rare) user-space bug of accessing below %esp, but
> other than that it looks redundant (IMHO) and as soon as
> it triggers the false-positives, what is it really good for?

I can't get a SIGSEGV on any native i386 kernel, not even when
running on AMD64. It only happens on native x86_64 kernels.

Looking at the AMD instruction manual, the pseudo-code for 'enter'
ends with:

RSP.s = RSP - temp_ALLOC_SPACE // Leave "temp_ALLOC_SPACE" free bytes on
// the stack
WRITE_MEM.v [SS:RSP.s] = temp_unused // ENTER finishes with a memory write
// check on the final stack pointer,
// but no write actually occurs.
RBP.v = temp_RBP
EXIT


And the Intel manual says:

IF 64-Bit Mode (StackSize = 64)
THEN
RBP = FrameTemp;
RSP = RSP - Size;
ELSE IF StackSize = 32
THEN
EBP = FrameTemp;
ESP = ESP - Size;
ELSE (* StackSize = 16 *)
BP = FrameTemp;
SP = SP - Size;
FI;
END;


Intel says nothing about a write check. Is that a mistake in the manual
or is that something only AMD64 does, and then only in long mode?


--
Chuck

"The x86 isn't all that complex -- it just doesn't make a lot of sense."
-- Mike Johnson
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2006-05-16 04:40    [W:0.052 / U:2.292 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site