Re: ESP corruption bug - what CPUs are affected?

[Petr Vandrovec <vandrove@vc.cvut.cz>]

On Sat, Sep 18, 2004 at 08:45:33PM +0400, Stas Sergeev wrote:
> Hi Petr.
> 
> Petr Vandrovec wrote:
> >natural solution seems to be to create complete 16bit CPL1 
> >environment, return to it, load ESP as you want, and then do IRET 
> >to return to CPL2 or CPL3.  Fortunately V8086 mode is not affected, 
> >so there should be no problem with using CPL1 for this middle step.  
> >But of course it is not something you want to do on each return 
> >from interrupt handler...  Well, or maybe you want...
> Actually, this may indeed be what I want!
> I think this can be implemented with the checks
> that Denis Vlasenko suggests. Something like this
> can be added to entry.S, right before the "iret":
> ---
> if (!(old_EFLAGS & VM_MASK) && (descr_old_SS is 16bit one))
>  push_a_stack_frame_to_return_to_the_ring1_trampoline();
> ---
> This way the overhead for the normal case would be
> something about 4 asm insns (the check), and for the
> dosemu case - who cares? (and probably also the wine
> people will value that)
> 
> Does this look reasonable? If it does, I think I
> should just start implementing that.

Do not forget that you have to implement also return to CPL1, as
NMI may arrive while you are running on CPL1.  So it may not be
as trivial as it seemed.  Maybe all these programs survive that
their CPL3 stack changes, and then you could just push cs,eip and
esp on CPL3 stack, and return to user code (vsyscall page seems 
natural place for that code) which would do pop %esp; retf?

Only problem is how to find that old SS points to 16bit segment.
You need LAR and/or you have to peek GDT/LDT to find stack size, 
and AFAIK LAR is microcoded on P4.
						Petr Vandrovec