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]

Date:	Fri, 15 Sep 2006 10:58:00 +0200
From:	Mikael Pettersson <mikpe@...uu.se>
To:	Jeremy Fitzhardinge <jeremy@...p.org>
Cc:	Mikael Pettersson <mikpe@...uu.se>, acahalan@...il.com, ak@...e.de,
	arjan@...radead.org, ebiederm@...ssion.com,
	linux-kernel@...r.kernel.org, mingo@...e.hu, torvalds@...l.org,
	zach@...are.com
Subject: Re: Assignment of GDT entries

Jeremy Fitzhardinge writes:
 > Mikael Pettersson wrote:
 > > The i386 TLS API has three components:
 > >
 > > (1) set_thread_area(entry_number == -1):
 > >     allocates and sets up the first available TLS entry and
 > >     copies the chosen GDT index back to user-space
 > > (2) set_thread_area(6 <= entry_number && entry_number <= 8):
 > >     allocates and sets up the indicated GDT entry
 > > (3) get_thread_area(6 <= entry_number && entry_number <= 8):
 > >     retrieves the contents of the indicated GDT entry
 > >
 > > Only (1) works in x86-64's ia32 emulation, the other two fail
 > > with EINVAL because x86-64 only accepts GDT indices 12 to 14
 > > for TLS entries. glibc only uses (1).
 > >
 > > If you move the i386 TLS GDT entries to other indices then you
 > > break (2) and (3) also on i386.
 > >   
 > 
 > (2) and (3) are always OK if you pass it the result of (1) - ie to 
 > update or readback a previously allocated descriptor.  Neither is useful 
 > without having done (1) first.

In the real world a process' state is influenced by code I have little
control over, usually glibc and other libraries, and fork(). Using (3)
I can inspect parts of my process' state that I did not initialize myself.

 >  The fact that 32-on-32 and 32-on-64 
 > differ here means that nothing can (an apparently nothing does) depend 
 > on hardcoded knowledge of the TLS descriptor indicies anyway.

No, it means that x86-64's ia32 emulation was implemented by someone
who either didn't realize the difference, or didn't care (because
"only glibc matters").

 > > It's not difficult to design a better i386 TLS API that avoids
 > > requiring user-space to know the actual GDT indices (just use
 > > logical TLS indices and always copy the GDT index to user-space).
 > > but unfortunately that doesn't help us
 > >   
 > 
 > You still need the real indicies to construct a selector to put into a 
 > segment register - ie, actually do something useful.

Sure.

 >  Changing the API 
 > to use abstract "TLS indicies" would also require a call to return the 
 > "TLS base", which hardly seems like an improvement.

The TLS base can obviously be zero.

User-space asks to access TLS #n (for allocs #n can be -1).
The kernel maps that to GDT index #m.
The kernel stores #m in the user-space buffer.
User-space maps #m to a selector.

 > Also, there's no inherent reason why the TLS indicies should be 
 > contigious; it happens to be true, but there's nothing useful userspace 
 > can do with that knowledge.  Allowing them to be discontigious may be 
 > helpful, for example, in packing the most used TLS entries (ie #1) into 
 > a hot cache line, while putting the lesser-used ones elsewhere.  The 
 > current API could deal with this without needing to change.

I have said nothing that would prevent the use of sparse TLS GDT indices.

Look, I'm not saying the current API is perfect, far from it. But it does
have valid usage modes which are broken in x86-64's ia32 emulation, and
will break on i386 of you reallocate the TLS GDT indices. This is a fact.

This is why I'm asking that if you change things (thus breaking binary
compatibility even more), that a corrected API be placed in new syscalls.

That is, instead of forcing user-space to do

   uname
   if (version >= 2.6.N)
      call {set,get}_thread_area with new-style parameters
   else
      call {set,get}_thread_area with old-style parameters

it should do

   call new_{set,get}_thread_area with new-style parameters
   if (ENOSYS)
     call old_{set,get}_thread_area with old-style parameters

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