WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

[Xen-devel] NPTL/TLS segment flipping code problem

To: <xen-devel@xxxxxxxxxxxxxxxxxxxxx>
Subject: [Xen-devel] NPTL/TLS segment flipping code problem
From: "Jan Beulich" <JBeulich@xxxxxxxxxx>
Date: Fri, 07 Jan 2005 11:16:30 +0100
Delivery-date: Sat, 08 Jan 2005 02:20:12 +0000
Envelope-to: xen+James.Bulpin@xxxxxxxxxxxx
List-archive: <http://sourceforge.net/mailarchive/forum.php?forum=xen-devel>
List-help: <mailto:xen-devel-request@lists.sourceforge.net?subject=help>
List-id: List for Xen developers <xen-devel.lists.sourceforge.net>
List-post: <mailto:xen-devel@lists.sourceforge.net>
List-subscribe: <https://lists.sourceforge.net/lists/listinfo/xen-devel>, <mailto:xen-devel-request@lists.sourceforge.net?subject=subscribe>
List-unsubscribe: <https://lists.sourceforge.net/lists/listinfo/xen-devel>, <mailto:xen-devel-request@lists.sourceforge.net?subject=unsubscribe>
Sender: xen-devel-admin@xxxxxxxxxxxxxxxxxxxxx
Looking at this code (2.0.2), it appears to have a couple of problems I
could not find mentioned on the mailing list archive:

(1) If base is zero in an expand-up segment, the conversion will yield
an expand-down segment covering the whole 4Gb, thus providing a
mechanism to obtain access to XEN space.

(2) If a malicious program accesses memory at a small negative offset
from gs:0 and the access extends into the positive range, the access
will gp-fault with either descriptor setting, thus leading to an endless
loop of flipping between the two states.

(3) Since escaped opcodes (those starting with 0F) aren't handled,
accessing mm/xmm data in __thread variables (along with other
specialized operations on such variable the compiler might generate) is
going to kill the program. Of course, it is similarly problematic that
SIB addressing still isn't implemented, but that's at least stated so in
the code.

(4) In the no-mod-r/m handling of the decoder, the byte case is handled
incorrectly: The address it deals with is still a 32-byte (or 16-byte,
but 16-bit addressing isn't handled anyway) one. There simply must not
be a 'case 1' there, and the insn_decode table should be changed
accordingly.

(5, minor) The change from 2.0.1 to 2.0.2 (making the code a lot more
correct) left an access to the no longer existing positive_access
parameter of fixup_seg in (at least) one of the DPRINTK-s.

Jan


-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/xen-devel