From: Brian Gerst <bgerst@didntduck.org>
To: Andi Kleen <ak@suse.de>
Cc: linux-kernel@vger.kernel.org, set@pobox.com,
alan@lxorguk.ukuu.org.uk, Wilfried.Weissmann@gmx.at
Subject: Re: [OOPS] repeatable 2.4.8-ac7, 2.4.7-ac6 just run xdos
Date: Wed, 22 Aug 2001 08:11:40 -0400 [thread overview]
Message-ID: <3B83A17C.CB8ABC53@didntduck.org> (raw)
In-Reply-To: <20010819004703.A226@squish.home.loc.suse.lists.linux.kernel> <3B831CDF.4CC930A7@didntduck.org.suse.lists.linux.kernel> <oupn14sny4f.fsf@pigdrop.muc.suse.de> <3B839E47.874F8F64@didntduck.org> <20010822141058.A18043@gruyere.muc.suse.de>
Andi Kleen wrote:
>
> On Wed, Aug 22, 2001 at 07:57:59AM -0400, Brian Gerst wrote:
> > Yes. What happened here is that %ds and %es were not being updated
> > atomically. Under normal operation, this would just leave %es with
> > USER_DS, which is sufficiently equivalent to KERNEL_DS to not cause a
> > fault. Coming out of vm86 mode however forces the data segment
> > registers to null after saving the real mode values on the stack. If an
> > interrupt happened between setting %ds and %es (what are the odds?) then
> > that assumption would fail and leave %es null, causing the next string
> > instruction to go boom. The same fix should be applied to entry.S as
> > well.
>
> No that's not the problem. interrupt gates come in with interrupts off,
> so there are no other interrupts that could race here. The syscall entry
> always updates %ds/%es unconditionally and %ds first, so there is no
> race.
>
> It was much simpler. It assumed that __KERNEL_DS could not be loaded
> from user space because of the segment register priviledge checking; and
> that was obviously not true from vm86 mode.
>
> -Andi
The kernel was initially entered throught the general protection fault
trap gate, with interupts on. The syscall entry was left on the stack
because of the way sys_vm86 works.
--
Brian Gerst
next prev parent reply other threads:[~2001-08-22 12:15 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20010819004703.A226@squish.home.loc.suse.lists.linux.kernel>
[not found] ` <3B831CDF.4CC930A7@didntduck.org.suse.lists.linux.kernel>
2001-08-22 11:16 ` [OOPS] repeatable 2.4.8-ac7, 2.4.7-ac6 just run xdos Andi Kleen
2001-08-22 11:57 ` Brian Gerst
2001-08-22 12:10 ` Andi Kleen
2001-08-22 12:11 ` Brian Gerst [this message]
2001-08-22 13:22 ` Andi Kleen
2001-08-22 19:52 ` Paul
2001-08-23 13:34 ` Andi Kleen
2001-08-23 18:05 ` Paul
2001-08-23 18:20 ` Wayne Whitney
2001-08-19 4:47 Paul
2001-08-19 5:09 ` Jeff Chua
2001-08-19 5:40 ` Paul
2001-08-19 8:04 ` Jeff Chua
2001-08-19 20:30 ` Eric W. Biederman
2001-08-19 5:10 ` Jeff Chua
2001-08-22 2:45 ` Brian Gerst
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=3B83A17C.CB8ABC53@didntduck.org \
--to=bgerst@didntduck.org \
--cc=Wilfried.Weissmann@gmx.at \
--cc=ak@suse.de \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=linux-kernel@vger.kernel.org \
--cc=set@pobox.com \
/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.