Messages in this thread | | | Date | Wed, 22 Sep 2004 23:05:51 +0400 | From | Stas Sergeev <> | Subject | Re: ESP corruption bug - what CPUs are affected? |
| |
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.
- 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/
| |