From: Jamie Lokier <jamie@shareable.org>
To: Andi Kleen <ak@muc.de>
Cc: 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: Mon, 29 Sep 2003 18:03:23 +0100 [thread overview]
Message-ID: <20030929170323.GC21798@mail.jlokier.co.uk> (raw)
In-Reply-To: <20030929125629.GA1746@averell>
Andi Kleen wrote:
> +/*
> + * Find an segment base in the LDT/GDT.
> + * Don't need to do any boundary checking because the CPU did that already
> + * when the instruction was executed
> + */
I'm not 100% sure, but I see some possible dangerous race conditions.
1. Userspace thread A has a page fault at CS:EIP == 0x000f:0xbffff000.
Simultaneously, userspace thread B calls modify_ldt() to change
the LDT descriptor base to 0x40000000.
The LDT descriptor is changed after A enters the page fault
handler, but before it takes mmap_sem. This can happen on SMP or
on a pre-empt kernel.
__is_prefetch() calls __get_user(0xfffff000), or whatever
address userspace wants to trick it into reading.
Result: unpriveleged userspace causes an MMIO read and crashes
the system, or worse.
2. segment_base sets "desc = (u32 *)&cpu_gdt_table[smp_processor_id()]".
Pre-empt switches CPU.
desc now points to the _old_ CPU, where the GDT for this task is
no longer valid, and that is read in the next few lines.
I think for completeness you should check the segment type and limit
too (because they can be changed, see 1.). These are easier to check
than they look (w.r.t. 16 bit segments etc.): you don't have to decode
the descriptor; just use the "lar" and "lsl" instructions.
If you can't decode the instruction because of transient access
problems, just return as if it was a prefetch, so that the faulting
instruction will be retried, or access permissions will cause the
program to trap in the normal ways.
-- Jamie
next prev parent reply other threads:[~2003-09-29 17:06 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 [this message]
2003-09-29 17:49 ` Andi Kleen
2003-09-29 20:08 ` Jamie Lokier
2003-09-30 5:50 ` Andi Kleen
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=20030929170323.GC21798@mail.jlokier.co.uk \
--to=jamie@shareable.org \
--cc=ak@muc.de \
--cc=akpm@osdl.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®