Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Sat, 25 Feb 2012 08:32:13 -0500
From: Rich Felker <>
Subject: Re: tough choice on thread pointer initialization issue

On Sat, Feb 25, 2012 at 01:56:13AM -0500, Rich Felker wrote:
> I've looked into the "solution 4" that Solar proposed, which simply
> put is making __pthread_self() check for a clobbered thread register
> and restore it. While this sounds simple, there are a few issues I've
> run into whereby it starts to get ugly...

Some revisions... it's not quite as bad as I said, but still not good

> with, but from reading the kernel sources, it looks like %fs is 0 and
> a hidden 64-bit offset is stored in a privileged register accessible
> only by the kernel (one which hopefully would not be clobbered by
> sigreturn, but I'm not sure...) when the thread pointer does not fit
> in 32 bits, and the old i386 method (LDT entry and non-zero %fs
> selector value) is used when the thread pointer fits in 32 bits. This

Got the cases reversed I think, but the issue still stands.

> pointer is valid, we can't restore it (and the value of %fs might
> actually need to differ per-thread if some threads are below the 4gb
> boundary and others are located above).

Per-thread difference is irrelevant since only the main thread can
ever experience this problem; all new threads start with a valid
thread pointer.


Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.