From: Petr Vandrovec <vandrove@vc.cvut.cz>
To: Stas Sergeev <stsp@aknet.ru>
Cc: linux-kernel@vger.kernel.org
Subject: Re: ESP corruption bug - what CPUs are affected?
Date: Fri, 24 Sep 2004 23:43:30 +0200 [thread overview]
Message-ID: <20040924214330.GD8151@vana.vc.cvut.cz> (raw)
In-Reply-To: <4154853F.6070105@aknet.ru>
On Sat, Sep 25, 2004 at 12:36:15AM +0400, Stas Sergeev wrote:
> Hi,
>
> Petr Vandrovec wrote:
> >In that new patch I set the const to 0xe00, which
> >is 3,5K. Is it still the limitation? I can probably
> >For 4KB stacks 2KB looks better
> OK, done that. Wondering though, for what?
> I don't need 2K myself, I need 24 bytes only.
> So what prevents me to raise the gap to 3.5K
> or somesuch? Why 2K looks better?
You run with ESP decreased by 2KB for some time during
CPL1 stack setup. As you run in this part at CPL0
with same setup as on CPL1, I think that you should
offer same stack for setup code, and for CPL1 code,
and so each should get 2KB.
> >>+8: subl $(NMI_STACK_RESERVE-4), %esp; \
> >>+ .rept 5; \
> >Any reason why you left this part of RESTORE_ALL macro?
> The reason is that the previous part of the macro
> can jump to that part. So how can I divide those?
Use real labels instead of numeric local labels. That way
macro does jne cpl1exit, and you create cpl1exit: label outside
of macro, somewhere in entry.S...
> >be moved out, IMHO. RESTORE_ALL is used twice in entry.S, so you
> >could save one copy.
> Do you mean the NMI return path doesn't need
> the ESP fix at all? Why?
No. I was attempting to say that RESTORE_ALL is on two
places to save jumps (I cannot think about any other reason),
and so cpl1exit could be shared:
#define RESTORE_ALL \
movl EFLAGS(%esp),%eax \
.... \
jne 3f \
lar OLDSS(%esp),%eax \
testl $0x00400000,%eax \
jz cpl1exit \
3: RESTORE_REGS \
add $4,%esp \
1: iret \
.section __ex_table,"a";\
.align 4; \
long 1b,badss; \
.previous
badss: sti;
movl $(__USER_DS), %edx;
movl %edx, %ds;
movl %edx, %es;
pushl $11;
call do_exit;
cpl1exit:
RESTORE_REGS
subl $...,%esp
...
But your solution with killing RESTORE_ALL completely is also
fine - you just could reorder jumps a bit, so return to kernel
or VM86 is one (not taken) jump shorter than it is with current
version of patch.
> >Though I'm not sure why NMI handler simple
> >does not jump to RESTORE_ALL we already have.
> I can only change that and then un-macro the
> RESTORE_ALL completely. So I did that.
> Additionally I introduced the "short path"
> for the case where we know for sure that we
> are returning to the kernel. And I am not
> setting the exception handler there because
> returning to the kernel if fails, should die()
> anyway. Is this correct?
If you'll first test result of lar, and then
you'll do two independent RESTORE_REGS (second
one actually does not have to restore %ebp
and %eax and you can restore them directly by
move from stack after you are done with trampoline
setup, instead of doing push + pop), you can reuse
RESOTRE_REGS+add $4,%esp+iret return path, including
its exception handling.
> +ENTRY(espfix_trampoline)
> + popl %esp
> +espfix_past_esp:
> +1: iret
> +.section .fixup,"ax"
> +2: sti
> + movl $(__USER_DS), %edx
> + movl %edx, %ds
> + movl %edx, %es
> + pushl $11
> + call do_exit
> +.previous
You can reuse fixup code from other iret instance,
just give it real label and reference it from __ex_table
instead of '2b'.
Patch looks fine, though you could speedup it a bit as outlined above.
Now you have to persuade others that this patch should include patch
into the kernel.
Petr
next prev parent reply other threads:[~2004-09-24 21:44 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-09-16 18:39 ESP corruption bug - what CPUs are affected? Petr Vandrovec
2004-09-17 18:12 ` Stas Sergeev
2004-09-18 16:45 ` Stas Sergeev
2004-09-18 16:59 ` Petr Vandrovec
2004-09-18 19:14 ` Stas Sergeev
2004-09-18 20:35 ` Petr Vandrovec
2004-09-22 18:49 ` Stas Sergeev
2004-09-22 19:19 ` Richard B. Johnson
2004-09-22 20:03 ` Stas Sergeev
2004-09-22 20:13 ` Richard B. Johnson
2004-09-28 15:43 ` Denis Vlasenko
2004-09-22 20:02 ` Petr Vandrovec
2004-09-23 4:09 ` Stas Sergeev
2004-09-23 17:08 ` Stas Sergeev
2004-09-23 18:06 ` Petr Vandrovec
2004-09-24 20:36 ` Stas Sergeev
2004-09-24 21:43 ` Petr Vandrovec [this message]
2004-09-25 8:04 ` Gabriel Paubert
2004-09-25 12:25 ` Stas Sergeev
2004-09-25 19:18 ` Gabriel Paubert
2004-09-25 20:40 ` Stas Sergeev
2004-09-25 23:42 ` Gabriel Paubert
2004-09-26 18:04 ` Stas Sergeev
2004-09-27 9:07 ` Gabriel Paubert
2004-09-30 15:11 ` Bill Davidsen
2004-10-06 16:18 ` ESP corruption bug - what CPUs are affected? (patch attempts) Stas Sergeev
-- strict thread matches above, loose matches on Subject: below --
2004-10-06 17:18 ESP corruption bug - what CPUs are affected? (patch att Petr Vandrovec
2004-10-11 18:32 ` ESP corruption bug - what CPUs are affected? Stas Sergeev
2004-09-16 17:49 Stas Sergeev
2004-09-16 19:03 ` Denis Vlasenko
2004-09-17 18:13 ` Stas Sergeev
2004-09-17 22:04 ` Denis Vlasenko
2004-09-18 10:58 ` Stas Sergeev
2004-09-18 13:08 ` Denis Vlasenko
2004-09-18 17:05 ` Stas Sergeev
[not found] ` <200409190108.45641.vda@port.imtp.ilyichevsk.odessa.ua>
2004-09-22 19:05 ` Stas Sergeev
2004-09-21 11:19 ` Pavel Machek
2004-09-21 11:43 ` Denis Vlasenko
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20040924214330.GD8151@vana.vc.cvut.cz \
--to=vandrove@vc.cvut.cz \
--cc=linux-kernel@vger.kernel.org \
--cc=stsp@aknet.ru \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.