From: Jamie Lokier <jamie@shareable.org>
To: Paul Brook <paul@codesourcery.com>
Cc: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [RFC][PATCH] x86: Optional segment type and limit checks - v2
Date: Mon, 14 Jul 2008 15:02:38 +0100 [thread overview]
Message-ID: <20080714140238.GA5496@shareable.org> (raw)
In-Reply-To: <200807141211.49825.paul@codesourcery.com>
Paul Brook wrote:
> > For guests like older Linux, with zero base and non-maximum limit in
> > user mode, could limit checking be done by the MMU TLB instead?
>
> Not really. The only resonable way to do this would be to use a very
> large virtual address space, with the high bits being the segment
> descriptor. This might work for 32-bit targets on 64-bit hosts, but
> even then it's liable to be more pain than it's worth.
I was thinking more like this, on any host:
- All segment bases are zero, and all limits are LIMIT
(3GiB for old Linux in user mode).
- When filling the MMU TLB, if it's for an address >= LIMIT,
treat as MMU exception.
- Flush MMU TLB on any interesting segment change (limit gets
smaller, etc.).
- Count rate of interesting segment changes. When it's high,
switch to including segment checks in translated code (same as
non-zero bases) and not flushing TLB. When it's low, don't put
segment checks into translated code, and use TLB flushes on
segment changes.
- Keep separate count for ring 0 and ring 3, or for
"code which uses segment prefixes" vs "code which doesn't".
This would suit old Linux, as kernel code uses segment to limit
copy-from/to-user range, but user code has no segment changes
normally, and the user limit check is equivalent to forcing all
MMU pages above that virtual address to be supervisor-only.
-- Jamie
next prev parent reply other threads:[~2008-07-14 14:02 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-07-09 12:12 [Qemu-devel] [RFC][PATCH] x86: Optional segment type and limit checks Jan Kiszka
2008-07-14 10:34 ` [Qemu-devel] [RFC][PATCH] x86: Optional segment type and limit checks - v2 Jan Kiszka
2008-07-14 10:55 ` Jamie Lokier
2008-07-14 11:11 ` Paul Brook
2008-07-14 14:02 ` Jamie Lokier [this message]
2008-07-14 17:50 ` Kevin O'Connor
2008-07-14 18:51 ` Jamie Lokier
2008-07-15 15:48 ` [Qemu-devel] " Jan Kiszka
2008-07-15 16:12 ` Jamie Lokier
2008-07-16 1:20 ` Kevin O'Connor
2008-07-16 2:43 ` Kevin O'Connor
2008-07-14 11:05 ` [Qemu-devel] " Daniel P. Berrange
2008-07-15 15:43 ` [Qemu-devel] " Jan Kiszka
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=20080714140238.GA5496@shareable.org \
--to=jamie@shareable.org \
--cc=paul@codesourcery.com \
--cc=qemu-devel@nongnu.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 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.