lkml.org 
[lkml]   [2015]   [Jul]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v2 2/3] x86/ldt: Make modify_ldt optional
On Tue, Jul 21, 2015 at 11:23:02PM -0700, Andy Lutomirski wrote:
> >> >> +config MODIFY_LDT_SYSCALL
> >> >> + bool "Enable the LDT (local descriptor table)" if EXPERT
> >> >> + default y
> >> >> + ---help---
> >> >> + Linux can allow user programs to install a per-process x86
> >> >> + Local Descriptor Table (LDT) using the modify_ldt(2) system
> >> >> + call. This is required to run 16-bit or segmented code such as
> >> >> + DOSEMU or some Wine programs. It is also used by some very old
> >> >> + threading libraries.
> >> >> +
> >> >> + Enabling this feature adds a small amount of overhead to
> >> >> + context switches and increases the low-level kernel attack
> >> >> + surface. Disabling it removes the modify_ldt(2) system call.
> >> >> +
> >> >> + Saying 'N' here may make sense for embedded or server kernels.
> >> >> +
> >> >
> >> > I believe Wine still uses the LDT for thread-local data, even for 32
> >> > and 64-bit programs. This is separate from the Linux runtime TLS.
> >> >
> >>
> >> Really? I thought the whole reason we had three set_thread_area slots
> >> was for Wine.
> >
> > Too bad we have to guess, if only we had the Wine source code under a nicely
> > accessible Git archive or so to check?
> >
> > git clone git://source.winehq.org/git/wine.git
> >
> > ;-)
>
> You don't say?
>
> It appears that Wine uses set_thread_area with a fallback to
> modify_ldt for 32-bit binaries and arch_prctl for 64-bit.

Why wouldn't we have this (as well as X86_16BIT) as a sysctl for the long
term, just like we've finally got rid of NULL mapping ? We would encourage
distros to ship with those settings disabled by default and to only enable
them when breakage is *observed*. Currently I think that adding new config
options will just make distro ship with the option enabled "just in case".

It's also a nice way to discover users of these mechanisms and to suggest
their developers to contemplate other options or to whine loudly.

Willy



\
 
 \ /
  Last update: 2015-07-22 15:01    [W:0.068 / U:0.008 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site