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

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

To: "Jan Beulich" <JBeulich@xxxxxxxxxx>
Subject: Re: [Xen-devel] NPTL/TLS segment flipping code problem
From: Ian Pratt <Ian.Pratt@xxxxxxxxxxxx>
Date: Sat, 08 Jan 2005 02:44:16 +0000
Cc: xen-devel@xxxxxxxxxxxxxxxxxxxxx, Ian.Pratt@xxxxxxxxxxxx
Delivery-date: Sat, 08 Jan 2005 02:56:34 +0000
Envelope-to: xen+James.Bulpin@xxxxxxxxxxxx
In-reply-to: Your message of "Fri, 07 Jan 2005 11:16:30 +0100." <s1de6183.018@xxxxxxxxxxxxxxxxxxxxxxx>
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:

Thanks, we'll look into these.

The whole TLS workaround is a huge pain in the butt, and has
pretty horrible performance anyhow. The segment flipping approach
doesn't buy us much as +ve and -ve accesses seem to be
interleaved. It at least enables some simplifications to the
instruction decoder (though as you point out, we need to extend
it some).

We really need to look into producing a suitably patched glibc
rpm. Likewise, we need to prevent gcc from generating -ve offsets
for tls as the default.

Ian

> (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



-------------------------------------------------------
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