Re: ESP corruption bug - what CPUs are affected?

[Stas Sergeev <stsp@aknet.ru>]

Hi,

Denis Vlasenko wrote:
> Maybe. This would be a complicated thing.
I bet it was! :)

> Well. Not okay. Maybe this?
> 1. We build IRET frame on ring1 stack for step 4 (see below),
>    modify IRET frame on ring0 stack so that intrs are disabled
>    and CS:EIP and SS:ESP point to values of ring1 code/stack.
Much simpler: IRET frame to return to user is
already there. Just push another one to return
to ring1 first.

> 2. IRET returns to ring1 code with dedicated *16-bit* ring1 stack
>    Upper word of ESP is wrong now, but we can safely fiddle with it.
> 3. trampoline code fixes upper word of ESP (how?)
popl %esp (as per Petr Vandrovec's suggestion)
The value on stack is carefully prepared on ring0.

> 4. trampoline IRETs to user code.
> May work.
Works!

> ring1 stacks must be per-CPU.
I allocate it on a ring0 stack. Noone seem to
suggest that. Is this flawed for some reasons?
 
>> ESP<=0xffff check - I don't think this one is
>> necessary).
> Any program which runs with 16bit stack and yet with
> ESP > 0xffff is doing something *terminally* weird.
> I think it is acceptable to leave this case unfixed.
For what? We can have that fixed so why not?

> You cannot check 16bitness of SS descriptor in two
> insns.
I do actually:
larl OLDSS(%esp), %eax
testl $0x00400000, %eax
which is exactly two insns.

Since I've forgot to CC the patch to you, I uploaded
it here:
http://www.dosemu.org/stas/linux-2.6.8-stacks2.diff
so that you (or anyone interested) can make a review.