linux-kernel - Re: Assignment of GDT entries

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4508F6B9.1040709@goop.org>
Date:	Wed, 13 Sep 2006 23:29:13 -0700
From:	Jeremy Fitzhardinge <jeremy@...p.org>
To:	Albert Cahalan <acahalan@...il.com>
CC:	"Eric W. Biederman" <ebiederm@...ssion.com>, torvalds@...l.org,
	mingo@...e.hu, ak@...e.de, arjan@...radead.org, zach@...are.com,
	linux-kernel@...r.kernel.org
Subject: Re: Assignment of GDT entries

Albert Cahalan wrote:
> So if I grabbed the first two slots before glibc got to
> mess with them, glibc wouldn't break horribly?

glibc would be happy with anything it got; if you grabbed all 3 TLS 
slots it would probably be upset.

> If I grabbed one slot and glibc grabbed another, Wine
> would be OK with the third instead of the second?

Presumably.

> So basically it's not allowed to just grab the 3rd slot?
Eh?  You mean there's no "allocate and return TLS slot #N" operation?  
No, but all the TLS slots should be interchangeable.  Once you've got 
your entry numbers and worked out your selector values, you can just use 
them.

> What if I want to find out what is already in use?
> Am I supposed to iterate over all 8191 possible
> GDT entries? How do I even tell how many slots
> are available without using them all up?
The kernel reserves 3 slots in the GDT for usermode use, which are 
per-thread.  If you want more segment descriptors, you can always 
allocate an LDT.

> Eeeeeeew. Well this was documented exactly nowhere.
> The man page is even vague about entry_number,

man set_thread_area has this as paragraph 2:

       When  set_thread_area() is passed an entry_number of -1, it uses a free
       TLS entry. If set_thread_area() finds a free TLS entry,  the  value  of
       u_info->entry_number  is  set  upon  return  to  show  which  entry was
       changed.

which seems pretty clear to me.  A quick run with strace on any binary 
shows this in action:

    set_thread_area({entry_number:-1 -> 6, base_addr:0xb7fb06c0,
    limit:1048575, seg_32bit:1, contents:0, read_exec_only:0,
    limit_in_pages:1, seg_not_present:0, useable:1}) = 0

    J
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/