From: Andi Kleen <ak@colin2.muc.de>
To: Jamie Lokier <jamie@shareable.org>
Cc: Andi Kleen <ak@muc.de>,
torvalds@osdl.org, akpm@osdl.org, linux-kernel@vger.kernel.org,
richard.brunner@amd.com
Subject: Re: [PATCH] Athlon Prefetch workaround for 2.6.0test6
Date: 30 Sep 2003 07:50:11 +0200 [thread overview]
Date: Tue, 30 Sep 2003 07:50:11 +0200 [thread overview]
Message-ID: <20030930055011.GB75928@colin2.muc.de> (raw)
In-Reply-To: <20030929200820.GA23444@mail.jlokier.co.uk>
On Mon, Sep 29, 2003 at 09:08:20PM +0100, Jamie Lokier wrote:
> My thinking: Segments can be used by x86 virtualising programs which
> use a segment to move a "window" of address range accessible to the
> virtualised code. It should _never_ be possible for the virtualised
> code, which may be malicious, to trigger reads outside the protected
> address range by various combinations of threads and triggering LDT
> modifications in the virtualiser.
Agreed. But access_ok() takes care of that. It does not guarantee
that the right instruction is checked, but whoever uses non zero
code segment bases can add their own checker or more likely
not use prefetch at all (it is likely ancient legacy code
code anyways).
> Btw, you assume that regs->xcs is a valid segment value. I think that
> the upper 16 bits are not guaranteed to be zero in general on the
> IA32, although they clearly are zero for the majority of IA-32 chips.
> Are they guaranteed to be zero on AMD's processors?
That would be new to me. Can you quote a line that says that from
the architecture manual?
Also remember the code only runs on AMD.
> > If it gets any more complicated I would be inclined to just
> > handle the in kernel prefetches using __ex_table entries and give up
> > on user space.
>
> __ex_table entries would have been a less controversial fix all along :)
>
> Perhaps it is better to just not decode at all when CS != __KERNEL_CS
> && CS != __USER_CS? Just fault.
Yep, I considered that too.
I think I will do that for x86-64 and 32bit can handle it all in
user space as I suspect the patch is unmergeable anyways.
> > The x86-64 version just ignores all bases, that should be fine
> > too. Anybody who uses non zero code segments likely doesn't care about
> > performance and won't use prefetch ;-)
>
> Does the x86-64 version ignore bases in 32 bit programs?
The CPU doesn't, the prefetch fix does.
I will add a check for __USER32_CS/__USER_CS and __KERNEL_CS to make
sure it will never wrap.
I'm dropping the original segment checking/code checking proposal for 32bit.
It obviously was misguided and Linus was right from the beginning
to reject it.
-Andi
next prev parent reply other threads:[~2003-09-30 5:50 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-09-29 12:56 Andi Kleen
2003-09-29 17:03 ` Jamie Lokier
2003-09-29 17:49 ` Andi Kleen
2003-09-29 20:08 ` Jamie Lokier
2003-09-30 5:50 ` Andi Kleen [this message]
2003-09-30 9:35 ` Gabriel Paubert
2003-09-29 22:13 ` Jamie Lokier
2003-09-30 5:38 ` Andi Kleen
2003-09-30 0:19 ` Jamie Lokier
2003-09-29 21:02 ` bill davidsen
2003-09-30 0:50 ` Nick Piggin
2003-09-30 13:27 ` Dave Jones
2003-09-30 15:36 ` Bill Davidsen
[not found] <20030929125629.GA1746@averell.suse.lists.linux.kernel>
[not found] ` <20030929170323.GC21798@mail.jlokier.co.uk.suse.lists.linux.kernel>
[not found] ` <20030929174910.GA90905@colin2.muc.de.suse.lists.linux.kernel>
[not found] ` <20030929200820.GA23444@mail.jlokier.co.uk.suse.lists.linux.kernel>
[not found] ` <20030930093556.GB12970@iram.es.suse.lists.linux.kernel>
2003-09-30 9:50 ` Andi Kleen
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=20030930055011.GB75928@colin2.muc.de \
--to=ak@colin2.muc.de \
--cc=ak@muc.de \
--cc=akpm@osdl.org \
--cc=jamie@shareable.org \
--cc=linux-kernel@vger.kernel.org \
--cc=richard.brunner@amd.com \
--cc=torvalds@osdl.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®