Re: ESP corruption bug - what CPUs are affected?

[Stas Sergeev]

Hi Denis.

Denis Vlasenko wrote:
> Aha. The only way to sanely handle it is to
> hack on entry.S I'm afraid. Something like rewriting
> CS:EIP so that it returns to a small ring-3 trampoline
> which clears upper 16 bits of ESP and jumps to original CS:EIP.
Well, I don't really want to clear the higher word
of ESP (even if I want to do that in most cases),
but I'd really like to just restore it properly.
Of course (I think) ring-3 trampoline will not
work for many reasons. The most obvious one is
that it itself can be interrupted in any place.
Another problem with it is that the return frame
will have to be pushed to the stack of a DOS prog.
This is not the good thing to do. dosemu avoids
ever touching the stack of a DOS prog by setting
up the sigaltstack.
What *will* work, however, is a ring-1 trampoline,
as Petr Vandrovec suggested. It can be executed
with interrupts disabled (I think) so will not
be interrupted, and it can (isn't it?) use the
kernel stack, if I understand that correctly.

> Now, how to detect when to use this? Hmm.... the simplest thing
> is to check that
> (old_ESP <= 0xffff) && !(old_EFLAGS & VM_MASK) && (descr_old_SS is 16bit one)
Yes, that's an excellent idea (except for the
ESP<=0xffff check - I don't think this one is
necessary).

> This will cost us only one comparison in the normal
> path,
Yes, so I think I should just try to implement
that. Not as a ring-3 trampoline, but as a ring-1
one.

> because typically ESP of Linus executables
> is greater than 0xffff.
I'd rather say, because the stack segment is 32bit
for them always.
And this all should work, as it seems to me.
Thanks for the hint about the checking.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/