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] [day] [month] [year] [list]
Date:	Fri, 15 Sep 2006 11:27:45 -0700
From:	Jeremy Fitzhardinge <jeremy@...p.org>
To:	Mikael Pettersson <mikpe@...uu.se>
CC:	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

Mikael Pettersson wrote:
>  >  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.
>   

I'm missing why this is a substantial improvement over the current 
interface (or functionally different at all).  What does this proposal 
let you do that the current one doesn't?

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

Hm, well its a "fact" in that they use different segment descriptors, 
but you'd be hard pressed to say that was a breakage.  set_thread_area 
was added in 2.5.29 (Jul 2002), and x86-64 added support in 2.5.43 (Oct 
2002), so the current behaviour is pretty much as it has always been.  
If you have a program that expects something different, you either wrote 
it in Jul-Oct 2002, or you made an unsustainable assumption about how 
set_thread_area() works.

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

You seem to have a specific use-case in mind; do you have a program 
which would like to use a new interface?  Would you mind spelling it 
out, and describe why the current interface doesn't work for you?

    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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ