[tip:x86/urgent] x86-64, modify_ldt: Ban 16-bit segments on 64-bit kernels

classic Classic list List threaded Threaded
137 messages Options
1 ... 4567
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] x86-64: espfix for 64-bit mode *PROTOTYPE*

H. Peter Anvin
On 04/28/2014 07:38 PM, H. Peter Anvin wrote:

> On 04/28/2014 05:20 PM, Andrew Lutomirski wrote:
>>
>> ldttest segfaults on 3.13 and 3.14 for me.  It reboots (triple fault?)
>> on your branch.  It even said this:
>>
>> qemu-system-x86_64: 9pfs:virtfs_reset: One or more uncluncked fids
>> found during reset
>>
>> I have no idea what an uncluncked fd is :)
>>
>
> It means 9p wasn't properly shut down.
>

(A "fid" is like the 9p version of a file descriptor.  Sort of.)

        -hpa


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] x86-64: espfix for 64-bit mode *PROTOTYPE*

H. Peter Anvin
In reply to this post by H. Peter Anvin-2
On 04/28/2014 07:38 PM, H. Peter Anvin wrote:

> On 04/28/2014 05:20 PM, Andrew Lutomirski wrote:
>>
>> ldttest segfaults on 3.13 and 3.14 for me.  It reboots (triple fault?)
>> on your branch.  It even said this:
>>
>> qemu-system-x86_64: 9pfs:virtfs_reset: One or more uncluncked fids
>> found during reset
>>
>> I have no idea what an uncluncked fd is :)
>>
>
> It means 9p wasn't properly shut down.
>

OK, so I found a bug in ldttest.c -- it sets CS to an LDT segment, but
it never sets SS to an LDT segment.  This means that it should really
have zero footprint versus the espfix code, and implies that we instead
have another bug involved.  Why the espfix code should have any effect
whatsoever is a mystery, however... if it indeed does?

I have uploaded a fixed ldttest.c, but it seems we might be chasing more
than that...

        -hpa


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] x86-64: espfix for 64-bit mode *PROTOTYPE*

H. Peter Anvin-2
On 04/28/2014 08:45 PM, H. Peter Anvin wrote:

>
> OK, so I found a bug in ldttest.c -- it sets CS to an LDT segment, but
> it never sets SS to an LDT segment.  This means that it should really
> have zero footprint versus the espfix code, and implies that we instead
> have another bug involved.  Why the espfix code should have any effect
> whatsoever is a mystery, however... if it indeed does?
>
> I have uploaded a fixed ldttest.c, but it seems we might be chasing more
> than that...
>

In particular, I was already wondered how we avoid an "upside down
swapgs" with a #GP on IRET.  The answer might be that we don't...

        -hpa


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] x86-64: espfix for 64-bit mode *PROTOTYPE*

H. Peter Anvin
In reply to this post by H. Peter Anvin
On 04/28/2014 08:45 PM, H. Peter Anvin wrote:

>
> OK, so I found a bug in ldttest.c -- it sets CS to an LDT segment, but
> it never sets SS to an LDT segment.  This means that it should really
> have zero footprint versus the espfix code, and implies that we instead
> have another bug involved.  Why the espfix code should have any effect
> whatsoever is a mystery, however... if it indeed does?
>
> I have uploaded a fixed ldttest.c, but it seems we might be chasing more
> than that...
>

With the test fixed, the bug was easy to find: we can't compare against
__KERNEL_DS in the doublefault handler, because both SS and the image on
the stack have the stack segment set to zero (NULL).

With that both ldttest and run16 pass with the doublefault code, even
with randomization turned back on.

I have pushed out the fix.

There are still things that need fixing: we need to go through the
espfix path even when returning from NMI/MC (which fortunately can't
nest with taking an NMI/MC on the espfix path itself, since in that case
we will have been interrupted while running in the kernel with a kernel
stack.)

(Cc: Rostedt because of the NMI issue.)

        -hpa

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] x86-64: espfix for 64-bit mode *PROTOTYPE*

H. Peter Anvin
On 04/28/2014 09:36 PM, H. Peter Anvin wrote:
>
> There are still things that need fixing: we need to go through the
> espfix path even when returning from NMI/MC (which fortunately can't
> nest with taking an NMI/MC on the espfix path itself, since in that case
> we will have been interrupted while running in the kernel with a kernel
> stack.)
>
> (Cc: Rostedt because of the NMI issue.)
>

NMI is fine: we go through irq_return except for nested NMI.  There are
only three IRETs in the kernel (irq_return, nested_nmi_out, and the
early trap handler) and all of them are good.

I think we just need to clean up the PV aspects of this and then we
should be in good shape.  I have done a bunch of cleanups to the
development git tree.

I'm considering making 16-bit segment support a EXPERT config option for
both 32- and 64-bit kernels, as it seems like a bit of a waste for
embedded systems which don't need this kind of backward compatibility.
Maybe that is something that can be left for someone else to implement
if they feel like it.

        -hpa

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
Reply | Threaded
Open this post in threaded view
|

Re: [tip:x86/urgent] x86-64, modify_ldt: Ban 16-bit segments on 64-bit kernels

Sven Joachim
In reply to this post by Alexandre Julliard
On 2014-04-14 09:48 +0200, Alexandre Julliard wrote:

> Linus Torvalds <[hidden email]> writes:
>
>> On Fri, Apr 11, 2014 at 11:45 AM, Brian Gerst <[hidden email]> wrote:
>>>
>>> I haven't tested it recently but I do know it has worked on 64-bit
>>> kernels.  There is no reason for it not to, the only thing not
>>> supported in long mode is vm86.  16-bit protected mode is unchanged.
>>
>> Afaik 64-bit windows doesn't support 16-bit binaries, so I just
>> assumed Wine wouldn't do it either on x86-64. Not for any real
>> technical reasons, though.
>>
>> HOWEVER. I'd like to hear something more definitive than "I haven't
>> tested recently". The "we don't break user space" is about having
>> actual real *users*, not about test programs.
>>
>> Are there people actually using 16-bit old windows programs under
>> wine? That's what matters.

It seems that at least some 32-bit programs are also broken, since after
upgrading the kernel to 3.14.3 I can no longer start my old chess
database program:

,----
| % file CB70.exe
| CB70.exe: PE32 executable (GUI) Intel 80386, for MS Windows
| % LANG=C wine CB70.exe
| modify_ldt: Invalid argument
| modify_ldt: Invalid argument
| modify_ldt: Invalid argument
| modify_ldt: Invalid argument
| modify_ldt: Invalid argument
`----

And here it just hangs, with wineboot.exe taking 100% CPU.  I had to
kill first wineboot.exe and then CB70.exe. :-(

> Yes, there is still a significant number of users, and we still
> regularly get bug reports about specific 16-bit apps. It would be really
> nice if we could continue to support them on x86-64, particularly since
> Microsoft doesn't ;-)

I would rather not set up a virtual machine just for wine (I don't have
Windows anymore).

Cheers,
       Sven
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
Reply | Threaded
Open this post in threaded view
|

Re: [tip:x86/urgent] x86-64, modify_ldt: Ban 16-bit segments on 64-bit kernels

Borislav Petkov-3
On Wed, May 07, 2014 at 11:18:49AM +0200, Sven Joachim wrote:
> I would rather not set up a virtual machine just for wine (I don't
> have Windows anymore).

What about reactos? (I'm not saying this shouldn't be addressed,
regardless...)

--
Regards/Gruss,
    Boris.

Sent from a fat crate under my desk. Formatting is fine.
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
Reply | Threaded
Open this post in threaded view
|

Re: [tip:x86/urgent] x86-64, modify_ldt: Ban 16-bit segments on 64-bit kernels

Linus Torvalds-2
In reply to this post by Sven Joachim
On Wed, May 7, 2014 at 2:18 AM, Sven Joachim <[hidden email]> wrote:
>
> It seems that at least some 32-bit programs are also broken, since after
> upgrading the kernel to 3.14.3 I can no longer start my old chess
> database program:

So for backporting (and for 3.15) maybe this (TOTALLY UNTESTED) patch
would be acceptable.

It adds a "/proc/sys/abi/ldt16" sysctl that defaults to zero (off). If
you hit this issue and care about your old Windows program more than
you care about a kernel stack address information leak, you can do

   echo 1 > /proc/sys/abi/ldt16

as root (add it to your startup scripts), and you should be ok.

Afaik, 16-bit programs under wine already need

  echo 0 > /proc/sys/vm/mmap_min_addr

because they want to map things at address 0, so this isn't a new concept.

I would like to repeat that this is totally untested. And the sysct
table is only added if you have COMPAT support enabled on x86-64, but
I assume anybody who runs old windows binaries very much does that ;)

                        Linus

patch.diff (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [tip:x86/urgent] x86-64, modify_ldt: Ban 16-bit segments on 64-bit kernels

H. Peter Anvin
On 05/07/2014 09:57 AM, Linus Torvalds wrote:
>
> Afaik, 16-bit programs under wine already need
>
>   echo 0 > /proc/sys/vm/mmap_min_addr
>
> because they want to map things at address 0, so this isn't a new concept.
>

I think that applies to DOSEMU, but not to Wine.

Sven: if you have the ability to build your own kernel, could you also
try the "x86/espfix" branch of the git tree:

https://git.kernel.org/cgit/linux/kernel/git/tip/tip.git/

(clone URLs:)
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git

... to make sure the proper solution works for you?

I'm somewhat curious if this program you have is actually a 32-bit
program or if it is really a 16-bit program wrapped in a 32-bit
installer of some kind.  Hard to know without seeing the program in
question.

        -hpa

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
Reply | Threaded
Open this post in threaded view
|

Re: [tip:x86/urgent] x86-64, modify_ldt: Ban 16-bit segments on 64-bit kernels

Alexandre Julliard
"H. Peter Anvin" <[hidden email]> writes:

> On 05/07/2014 09:57 AM, Linus Torvalds wrote:
>>
>> Afaik, 16-bit programs under wine already need
>>
>>   echo 0 > /proc/sys/vm/mmap_min_addr
>>
>> because they want to map things at address 0, so this isn't a new concept.
>>
>
> I think that applies to DOSEMU, but not to Wine.

Yes, there are a few exceptions, but most Win16 apps run fine without
mapping address 0.

> I'm somewhat curious if this program you have is actually a 32-bit
> program or if it is really a 16-bit program wrapped in a 32-bit
> installer of some kind.  Hard to know without seeing the program in
> question.

It could be a mix of both, there are various thunking mechanisms that
allow 32-bit binaries to use 16-bit components. This was pretty common
in the Win95 days.

--
Alexandre Julliard
[hidden email]
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
Reply | Threaded
Open this post in threaded view
|

Re: [tip:x86/urgent] x86-64, modify_ldt: Ban 16-bit segments on 64-bit kernels

Sven Joachim
In reply to this post by H. Peter Anvin
On 2014-05-07 19:09 +0200, H. Peter Anvin wrote:

> On 05/07/2014 09:57 AM, Linus Torvalds wrote:
>>
>> Afaik, 16-bit programs under wine already need
>>
>>   echo 0 > /proc/sys/vm/mmap_min_addr
>>
>> because they want to map things at address 0, so this isn't a new concept.
>>
>
> I think that applies to DOSEMU, but not to Wine.

DOSEMU does no longer need it either.  If vm.mmap_min_addr is > 0, it
turns on CPU emulation, which it has to use anyway due to lack of vm86
mode.

> Sven: if you have the ability to build your own kernel, could you also
> try the "x86/espfix" branch of the git tree:
>
> https://git.kernel.org/cgit/linux/kernel/git/tip/tip.git/
>
> (clone URLs:)
> git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
> https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
>
> ... to make sure the proper solution works for you?

Works fine here, thanks.

> I'm somewhat curious if this program you have is actually a 32-bit
> program or if it is really a 16-bit program wrapped in a 32-bit
> installer of some kind.  Hard to know without seeing the program in
> question.

The main application (a chess database program) is 32-bit, but it comes
with several 16-bit analysis engines that are loaded on startup (I see
them in lsof output), so that's the situation described by Alexandre.

Cheers,
       Sven
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
Reply | Threaded
Open this post in threaded view
|

Re: [tip:x86/urgent] x86-64, modify_ldt: Ban 16-bit segments on 64-bit kernels

H. Peter Anvin
Actually it could use KVM instead of CPU emulation on nearly all modern processors...

On May 7, 2014 11:43:59 PM PDT, Sven Joachim <[hidden email]> wrote:

>On 2014-05-07 19:09 +0200, H. Peter Anvin wrote:
>
>> On 05/07/2014 09:57 AM, Linus Torvalds wrote:
>>>
>>> Afaik, 16-bit programs under wine already need
>>>
>>>   echo 0 > /proc/sys/vm/mmap_min_addr
>>>
>>> because they want to map things at address 0, so this isn't a new
>concept.
>>>
>>
>> I think that applies to DOSEMU, but not to Wine.
>
>DOSEMU does no longer need it either.  If vm.mmap_min_addr is > 0, it
>turns on CPU emulation, which it has to use anyway due to lack of vm86
>mode.
>
>> Sven: if you have the ability to build your own kernel, could you
>also
>> try the "x86/espfix" branch of the git tree:
>>
>> https://git.kernel.org/cgit/linux/kernel/git/tip/tip.git/
>>
>> (clone URLs:)
>> git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
>> https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
>>
>> ... to make sure the proper solution works for you?
>
>Works fine here, thanks.
>
>> I'm somewhat curious if this program you have is actually a 32-bit
>> program or if it is really a 16-bit program wrapped in a 32-bit
>> installer of some kind.  Hard to know without seeing the program in
>> question.
>
>The main application (a chess database program) is 32-bit, but it comes
>with several 16-bit analysis engines that are loaded on startup (I see
>them in lsof output), so that's the situation described by Alexandre.
>
>Cheers,
>       Sven

--
Sent from my mobile phone.  Please pardon brevity and lack of formatting.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
Reply | Threaded
Open this post in threaded view
|

Re: [tip:x86/urgent] x86-64, modify_ldt: Ban 16-bit segments on 64-bit kernels

H. Peter Anvin-2
On 05/08/2014 06:50 AM, H. Peter Anvin wrote:
> Actually it could use KVM instead of CPU emulation on nearly all modern processors...

Of course, at that point you might just run qemu-kvm instead of DOSEMU,
since I seem to recall that DOSEMU is still a real version of DOS.  I
have to admit to mostly using DOSBOX for games and KVM for anything else
that needs DOS these days... just what happens to work best for me.

        -hpa


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
Reply | Threaded
Open this post in threaded view
|

Re: [tip:x86/urgent] x86-64, modify_ldt: Ban 16-bit segments on 64-bit kernels

H. Peter Anvin
In reply to this post by H. Peter Anvin
On 05/08/2014 06:50 AM, H. Peter Anvin wrote:
> Actually it could use KVM instead of CPU emulation on nearly all modern processors...

That being said, it would be cool if someone would either port the
lredir backend (MFS) into Qemu, or finish the 9P front end I started
writing at one point, but probably will never have time to finish.
       
        -hpa


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
Reply | Threaded
Open this post in threaded view
|

Re: [tip:x86/urgent] x86-64, modify_ldt: Ban 16-bit segments on 64-bit kernels

Josh Boyer-5
In reply to this post by Linus Torvalds-2
On Wed, May 7, 2014 at 12:57 PM, Linus Torvalds
<[hidden email]> wrote:
> On Wed, May 7, 2014 at 2:18 AM, Sven Joachim <[hidden email]> wrote:
>>
>> It seems that at least some 32-bit programs are also broken, since after
>> upgrading the kernel to 3.14.3 I can no longer start my old chess
>> database program:

Now that this has hit 3.14.y stable, we have another report of this
commit breaking something in Wine, this time MS Access 2000:

https://bugzilla.redhat.com/show_bug.cgi?id=1096725 (reporter now CC'd)

> So for backporting (and for 3.15) maybe this (TOTALLY UNTESTED) patch
> would be acceptable.

I don't think your patch went anywhere.  I have no idea if you want to
push that or revert or just tell people to run old apps in 32-bit
guests at this point.  Just forwarding on the information.

josh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
Reply | Threaded
Open this post in threaded view
|

Re: [tip:x86/urgent] x86-64, modify_ldt: Ban 16-bit segments on 64-bit kernels

H. Peter Anvin-2
On 05/12/2014 06:16 AM, Josh Boyer wrote:

> On Wed, May 7, 2014 at 12:57 PM, Linus Torvalds
> <[hidden email]> wrote:
>> On Wed, May 7, 2014 at 2:18 AM, Sven Joachim <[hidden email]> wrote:
>>>
>>> It seems that at least some 32-bit programs are also broken, since after
>>> upgrading the kernel to 3.14.3 I can no longer start my old chess
>>> database program:
>
> Now that this has hit 3.14.y stable, we have another report of this
> commit breaking something in Wine, this time MS Access 2000:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1096725 (reporter now CC'd)
>
>> So for backporting (and for 3.15) maybe this (TOTALLY UNTESTED) patch
>> would be acceptable.
>
> I don't think your patch went anywhere.  I have no idea if you want to
> push that or revert or just tell people to run old apps in 32-bit
> guests at this point.  Just forwarding on the information.
>

Linus is off the net at the moment.  Someone needs to take his patch and
test it/clean it up.

        -hpa


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
Reply | Threaded
Open this post in threaded view
|

[tip:x86/urgent] x86-64, modify_ldt: Make support for 16-bit segments a runtime option

tip-bot for Peter Zijlstra
In reply to this post by Linus Torvalds-2
Commit-ID:  fa81511bb0bbb2b1aace3695ce869da9762624ff
Gitweb:     http://git.kernel.org/tip/fa81511bb0bbb2b1aace3695ce869da9762624ff
Author:     Linus Torvalds <[hidden email]>
AuthorDate: Wed, 14 May 2014 16:33:54 -0700
Committer:  H. Peter Anvin <[hidden email]>
CommitDate: Wed, 14 May 2014 16:33:54 -0700

x86-64, modify_ldt: Make support for 16-bit segments a runtime option

Checkin:

b3b42ac2cbae x86-64, modify_ldt: Ban 16-bit segments on 64-bit kernels

disabled 16-bit segments on 64-bit kernels due to an information
leak.  However, it does seem that people are genuinely using Wine to
run old 16-bit Windows programs on Linux.

A proper fix for this ("espfix64") is coming in the upcoming merge
window, but as a temporary fix, create a sysctl to allow the
administrator to re-enable support for 16-bit segments.

It adds a "/proc/sys/abi/ldt16" sysctl that defaults to zero (off). If
you hit this issue and care about your old Windows program more than
you care about a kernel stack address information leak, you can do

   echo 1 > /proc/sys/abi/ldt16

as root (add it to your startup scripts), and you should be ok.

The sysctl table is only added if you have COMPAT support enabled on
x86-64, but I assume anybody who runs old windows binaries very much
does that ;)

Signed-off-by: H. Peter Anvin <[hidden email]>
Link: http://lkml.kernel.org/r/CA%2B55aFw9BPoD10U1LfHbOMpHWZkvJTkMcfCs9s3urPr1YyWBxw@...
Cc: <[hidden email]>
---
 arch/x86/kernel/ldt.c        | 4 +++-
 arch/x86/vdso/vdso32-setup.c | 8 ++++++++
 2 files changed, 11 insertions(+), 1 deletion(-)

diff --git a/arch/x86/kernel/ldt.c b/arch/x86/kernel/ldt.c
index af1d14a..dcbbaa1 100644
--- a/arch/x86/kernel/ldt.c
+++ b/arch/x86/kernel/ldt.c
@@ -20,6 +20,8 @@
 #include <asm/mmu_context.h>
 #include <asm/syscalls.h>
 
+int sysctl_ldt16 = 0;
+
 #ifdef CONFIG_SMP
 static void flush_ldt(void *current_mm)
 {
@@ -234,7 +236,7 @@ static int write_ldt(void __user *ptr, unsigned long bytecount, int oldmode)
  * IRET leaking the high bits of the kernel stack address.
  */
 #ifdef CONFIG_X86_64
- if (!ldt_info.seg_32bit) {
+ if (!ldt_info.seg_32bit && !sysctl_ldt16) {
  error = -EINVAL;
  goto out_unlock;
  }
diff --git a/arch/x86/vdso/vdso32-setup.c b/arch/x86/vdso/vdso32-setup.c
index 0034898..e1f220e 100644
--- a/arch/x86/vdso/vdso32-setup.c
+++ b/arch/x86/vdso/vdso32-setup.c
@@ -39,6 +39,7 @@
 #ifdef CONFIG_X86_64
 #define vdso_enabled sysctl_vsyscall32
 #define arch_setup_additional_pages syscall32_setup_pages
+extern int sysctl_ldt16;
 #endif
 
 /*
@@ -249,6 +250,13 @@ static struct ctl_table abi_table2[] = {
  .mode = 0644,
  .proc_handler = proc_dointvec
  },
+ {
+ .procname = "ldt16",
+ .data = &sysctl_ldt16,
+ .maxlen = sizeof(int),
+ .mode = 0644,
+ .proc_handler = proc_dointvec
+ },
  {}
 };
 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
1 ... 4567