Re: + espfix-code-cleanup.patch added to -mm tree

[Stas Sergeev <stsp@aknet.ru>]

Hi.

Zachary Amsden wrote:
> Yes.  The iret faults, the fault pushes a new kernel frame - and the 
> fault handler's iret returns, removing the kernel frame.  So the kernel 
> frame is gone by the time the fixup runs.
OK, thanks! I wasn't completely realizing that the fixup runs
after an exception handler is already returned. Now it all looks
pretty obvious. :)

> It's really hard to catch bugs that could otherwise happen when a 
> non-zero based stack gets used (for example, C code which uses %ebp with 
> -fomit-frame-pointer).  Setting the limit to THREAD_SIZE should 
> guarantee that the non-zero based stack never is used to access anything 
> but the stack and current thread.
Yes, be there a possibility the set the *constant* limit (THREAD_SIZE),
I'd certainly do that, no questions. But as long as we are talking
about the nasty non-constant limit like regs->esp+THREAD_SIZE*2, is it
really worth an efforts? This limit is very unpredictable. I'll have
to add the code to deal with granularity. And its still very, very
permissive. Not even nearly something like just THREAD_SIZE.
Do you really, really think it is worth all the headache?

-
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/