linux-next: x86: Unalbe to run x32 processes on the x86_64 kernel

linux-next: x86: Unalbe to run x32 processes on the x86_64 kernel

[Andrei Vagin]

Hello,

We run CRIU tests on linux-next. And today we found that when we start
x32 processes, a kernel bug is triggered:

[root@fc24 ~]# uname -a
Linux fc24 4.11.0-rc2-next-20170320 #159 SMP Mon Mar 20 16:53:58 PDT
2017 x86_64 x86_64 x86_64 GNU/Linux
[root@fc24 ~]# cat t.c
int main()
{
return 0;
}
[root@fc24 ~]# gcc -m32 t.c
[root@fc24 ~]# ./a.out
Killed
[root@fc24 ~]# dmesg
[   90.033310] BUG: unable to handle kernel paging request at ffffffffff576060
[   90.034008] IP: 0xf76fa9f4
[   90.034008] PGD 13de1e067
[   90.034008] P4D 13de1e067
[   90.034008] PUD 13de20067
[   90.034008] PMD 13de21067
[   90.034008] PTE 800000013fd09161

[   90.034008] Oops: 0003 [#1] SMP
[   90.034008] Modules linked in:
[   90.034008] CPU: 1 PID: 475 Comm: a.out Not tainted
4.11.0-rc2-next-20170320 #159
[   90.034008] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
BIOS 1.9.3-1.fc25 04/01/2014
[   90.034008] task: ffff9d11efdca700 task.stack: ffffb0ccc0d4c000
[   90.034008] RIP: 0023:0xf76fa9f4
[   90.034008] RSP: 002b:00000000ffafc860 EFLAGS: 00010246
[   90.034008] RAX: 0000000000000063 RBX: 00000000ffafc860 RCX: 0000000008aea440
[   90.034008] RDX: 00000000f7515700 RSI: 00000000f771dfcc RDI: 0000000000000040
[   90.034008] RBP: 00000000ffafc928 R08: 0000000000000000 R09: 0000000000000000
[   90.034008] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000
[   90.034008] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
[   90.034008] FS:  0000000000000000(0000) GS:ffff9d11ffd00000(0000)
knlGS:0000000000000000
[   90.034008] CS:  0010 DS: 002b ES: 002b CR0: 0000000080050033
[   90.034008] CR2: ffffffffff576060 CR3: 000000012fd8d000 CR4: 00000000003406e0
[   90.034008] RIP: 0xf76fa9f4 RSP: 00000000ffafc860
[   90.034008] CR2: ffffffffff576060
[   90.034008] ---[ end trace 3c9a8bbd0d11f377 ]---
[   90.034008] BUG: sleeping function called from invalid context at
./include/linux/percpu-rwsem.h:33
[   90.034008] in_atomic(): 0, irqs_disabled(): 1, pid: 475, name: a.out
[   90.034008] INFO: lockdep is turned off.
[   90.034008] irq event stamp: 2014
[   90.034008] hardirqs last  enabled at (2013): [<ffffffffb98dc39d>]
entry_INT80_compat+0x3d/0x50
[   90.034008] hardirqs last disabled at (2014): [<ffffffffb98dc03c>]
error_entry+0x6c/0xd0
[   90.034008] softirqs last  enabled at (1666): [<ffffffffb98df7cd>]
__do_softirq+0x38d/0x4c3
[   90.034008] softirqs last disabled at (1657): [<ffffffffb90947b7>]
irq_exit+0xf7/0x100
[   90.034008] CPU: 1 PID: 475 Comm: a.out Tainted: G      D
4.11.0-rc2-next-20170320 #159
[   90.034008] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
BIOS 1.9.3-1.fc25 04/01/2014
[   90.034008] Call Trace:
[   90.034008]  dump_stack+0x86/0xc1
[   90.034008]  ___might_sleep+0x17d/0x250
[   90.034008]  __might_sleep+0x4a/0x80
[   90.034008]  exit_signals+0x33/0x250
[   90.034008]  ? blocking_notifier_call_chain+0x16/0x20
[   90.034008]  do_exit+0xbb/0xc60
[   90.034008]  ? trace_do_page_fault+0x58/0x2a0
[   90.034008]  rewind_stack_do_exit+0x17/0x20
[   90.034008] RIP: 0023:0xf76fa9f4
[   90.034008] RSP: 002b:00000000ffafc860 EFLAGS: 00010246
[   90.034008] RAX: 0000000000000063 RBX: 00000000ffafc860 RCX: 0000000008aea440
[   90.034008] RDX: 00000000f7515700 RSI: 00000000f771dfcc RDI: 0000000000000040
[   90.034008] RBP: 00000000ffafc928 R08: 0000000000000000 R09: 0000000000000000
[   90.034008] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000
[   90.034008] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000

Thanks,
Andrei

Re: linux-next: x86: Unalbe to run x32 processes on the x86_64 kernel

[Adam Borowski]

On Mon, Mar 20, 2017 at 04:57:39PM -0700, Andrei Vagin wrote:
> We run CRIU tests on linux-next. And today we found that when we start
> x32 processes, a kernel bug is triggered:
> 
> [root@fc24 ~]# uname -a
> Linux fc24 4.11.0-rc2-next-20170320 #159 SMP Mon Mar 20 16:53:58 PDT
> 2017 x86_64 x86_64 x86_64 GNU/Linux
> [root@fc24 ~]# cat t.c
> int main()
> {
> return 0;
> }
> [root@fc24 ~]# gcc -m32 t.c

-m32 is i386, for x32 you need -mx32.

> [root@fc24 ~]# ./a.out
> Killed
> [root@fc24 ~]# dmesg
> [   90.033310] BUG: unable to handle kernel paging request at ffffffffff576060

Indeed, same for me for i386.
On x32 the process gets killed with SEGV with no core, no kernel output.

On the other hand, a bare glibc-less process (write(), _exit()) works fine
both on i386 and x32.

I haven't looked any closer yet.

-- 
⢀⣴⠾⠻⢶⣦⠀ Meow!
⣾⠁⢠⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋⠀ Collisions shmolisions, let's see them find a collision or second
⠈⠳⣄⠀⠀⠀⠀ preimage for double rot13!

Re: linux-next: x86: Unalbe to run x32 processes on the x86_64 kernel

[Andrei Vagin]

Here is my bisect log:
[avagin@laptop linux-next]$ git bisect log
# bad: [f921b263d9602fb7873710c2df70671f2ffcf658] Add linux-next
specific files for 20170320
# good: [4495c08e84729385774601b5146d51d9e5849f81] Linux 4.11-rc2
git bisect start 'HEAD' 'v4.11-rc2'
# good: [adeec71e7b8a11ff44103cfa4e1c6002c27ae9ac] Merge
remote-tracking branch 'drm/drm-next'
git bisect good adeec71e7b8a11ff44103cfa4e1c6002c27ae9ac
# bad: [e5b1cee1bb9d8a66b28d64db9d8250ae2b0803d2] Merge
remote-tracking branch 'tty/tty-next'
git bisect bad e5b1cee1bb9d8a66b28d64db9d8250ae2b0803d2
# good: [81cde6aecf21113c6bc65bc944587db4cbd3f64d] Merge
remote-tracking branch 'mmc/next'
git bisect good 81cde6aecf21113c6bc65bc944587db4cbd3f64d
# bad: [69d76288005784205678520826a74c28e49a1703] Merge
remote-tracking branch 'tip/auto-latest'
git bisect bad 69d76288005784205678520826a74c28e49a1703
# good: [6d32edf2be6c4e0f08b102e2d3227278ebb477c9] Merge
remote-tracking branch 'spi/for-next'
git bisect good 6d32edf2be6c4e0f08b102e2d3227278ebb477c9
# good: [61f63e383784bd0ab6529cfc95ddc59c713afcc9] Merge tag
'perf-core-for-mingo-4.12-20170316' of
git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into
perf/core
git bisect good 61f63e383784bd0ab6529cfc95ddc59c713afcc9
# good: [3069c5a046ec92dc552194686c95e27c8c9e919d] Merge branch 'x86/asm'
git bisect good 3069c5a046ec92dc552194686c95e27c8c9e919d
# bad: [5b804ec2fd3272385ba7530c3a67d7402fb6d8a0] Merge branch 'x86/mm'
git bisect bad 5b804ec2fd3272385ba7530c3a67d7402fb6d8a0
# good: [06c830a48346643e195801460dfe16d96ba4dff5] x86/power: Add
5-level paging support
git bisect good 06c830a48346643e195801460dfe16d96ba4dff5
# good: [2bbbd194fdca01f694e2ca3fb447a1acf9d19f76] Merge branch 'x86/cpu'
git bisect good 2bbbd194fdca01f694e2ca3fb447a1acf9d19f76
# good: [69218e47994da614e7af600bf06887750ab6657a] x86: Remap GDT
tables in the fixmap section
git bisect good 69218e47994da614e7af600bf06887750ab6657a
# bad: [74c8ce958dbf0b64f198becb5d8aa93afb967438] Merge branch 'linus'
into x86/mm, to pick up a bugfix
git bisect bad 74c8ce958dbf0b64f198becb5d8aa93afb967438
# bad: [45fc8757d1d2128e342b4e7ef39adedf7752faac] x86: Make the GDT
remapping read-only on 64-bit
git bisect bad 45fc8757d1d2128e342b4e7ef39adedf7752faac
# first bad commit: [45fc8757d1d2128e342b4e7ef39adedf7752faac] x86:
Make the GDT remapping read-only on 64-bit

On Mon, Mar 20, 2017 at 4:57 PM, Andrei Vagin <avagin@gmail.com> wrote:
> Hello,
>
> We run CRIU tests on linux-next. And today we found that when we start
> x32 processes, a kernel bug is triggered:
>
> [root@fc24 ~]# uname -a
> Linux fc24 4.11.0-rc2-next-20170320 #159 SMP Mon Mar 20 16:53:58 PDT
> 2017 x86_64 x86_64 x86_64 GNU/Linux
> [root@fc24 ~]# cat t.c
> int main()
> {
> return 0;
> }
> [root@fc24 ~]# gcc -m32 t.c
> [root@fc24 ~]# ./a.out
> Killed
> [root@fc24 ~]# dmesg
> [   90.033310] BUG: unable to handle kernel paging request at ffffffffff576060
> [   90.034008] IP: 0xf76fa9f4
> [   90.034008] PGD 13de1e067
> [   90.034008] P4D 13de1e067
> [   90.034008] PUD 13de20067
> [   90.034008] PMD 13de21067
> [   90.034008] PTE 800000013fd09161
>
> [   90.034008] Oops: 0003 [#1] SMP
> [   90.034008] Modules linked in:
> [   90.034008] CPU: 1 PID: 475 Comm: a.out Not tainted
> 4.11.0-rc2-next-20170320 #159
> [   90.034008] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
> BIOS 1.9.3-1.fc25 04/01/2014
> [   90.034008] task: ffff9d11efdca700 task.stack: ffffb0ccc0d4c000
> [   90.034008] RIP: 0023:0xf76fa9f4
> [   90.034008] RSP: 002b:00000000ffafc860 EFLAGS: 00010246
> [   90.034008] RAX: 0000000000000063 RBX: 00000000ffafc860 RCX: 0000000008aea440
> [   90.034008] RDX: 00000000f7515700 RSI: 00000000f771dfcc RDI: 0000000000000040
> [   90.034008] RBP: 00000000ffafc928 R08: 0000000000000000 R09: 0000000000000000
> [   90.034008] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000
> [   90.034008] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
> [   90.034008] FS:  0000000000000000(0000) GS:ffff9d11ffd00000(0000)
> knlGS:0000000000000000
> [   90.034008] CS:  0010 DS: 002b ES: 002b CR0: 0000000080050033
> [   90.034008] CR2: ffffffffff576060 CR3: 000000012fd8d000 CR4: 00000000003406e0
> [   90.034008] RIP: 0xf76fa9f4 RSP: 00000000ffafc860
> [   90.034008] CR2: ffffffffff576060
> [   90.034008] ---[ end trace 3c9a8bbd0d11f377 ]---
> [   90.034008] BUG: sleeping function called from invalid context at
> ./include/linux/percpu-rwsem.h:33
> [   90.034008] in_atomic(): 0, irqs_disabled(): 1, pid: 475, name: a.out
> [   90.034008] INFO: lockdep is turned off.
> [   90.034008] irq event stamp: 2014
> [   90.034008] hardirqs last  enabled at (2013): [<ffffffffb98dc39d>]
> entry_INT80_compat+0x3d/0x50
> [   90.034008] hardirqs last disabled at (2014): [<ffffffffb98dc03c>]
> error_entry+0x6c/0xd0
> [   90.034008] softirqs last  enabled at (1666): [<ffffffffb98df7cd>]
> __do_softirq+0x38d/0x4c3
> [   90.034008] softirqs last disabled at (1657): [<ffffffffb90947b7>]
> irq_exit+0xf7/0x100
> [   90.034008] CPU: 1 PID: 475 Comm: a.out Tainted: G      D
> 4.11.0-rc2-next-20170320 #159
> [   90.034008] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
> BIOS 1.9.3-1.fc25 04/01/2014
> [   90.034008] Call Trace:
> [   90.034008]  dump_stack+0x86/0xc1
> [   90.034008]  ___might_sleep+0x17d/0x250
> [   90.034008]  __might_sleep+0x4a/0x80
> [   90.034008]  exit_signals+0x33/0x250
> [   90.034008]  ? blocking_notifier_call_chain+0x16/0x20
> [   90.034008]  do_exit+0xbb/0xc60
> [   90.034008]  ? trace_do_page_fault+0x58/0x2a0
> [   90.034008]  rewind_stack_do_exit+0x17/0x20
> [   90.034008] RIP: 0023:0xf76fa9f4
> [   90.034008] RSP: 002b:00000000ffafc860 EFLAGS: 00010246
> [   90.034008] RAX: 0000000000000063 RBX: 00000000ffafc860 RCX: 0000000008aea440
> [   90.034008] RDX: 00000000f7515700 RSI: 00000000f771dfcc RDI: 0000000000000040
> [   90.034008] RBP: 00000000ffafc928 R08: 0000000000000000 R09: 0000000000000000
> [   90.034008] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000
> [   90.034008] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
>
> Thanks,
> Andrei

Re: linux-next: x86: Unalbe to run x32 processes on the x86_64 kernel

[Ingo Molnar]

* Andrei Vagin <avagin@gmail.com> wrote:

> Here is my bisect log:
> [avagin@laptop linux-next]$ git bisect log
> # bad: [f921b263d9602fb7873710c2df70671f2ffcf658] Add linux-next
> specific files for 20170320
> # good: [4495c08e84729385774601b5146d51d9e5849f81] Linux 4.11-rc2
> git bisect start 'HEAD' 'v4.11-rc2'
> # good: [adeec71e7b8a11ff44103cfa4e1c6002c27ae9ac] Merge
> remote-tracking branch 'drm/drm-next'
> git bisect good adeec71e7b8a11ff44103cfa4e1c6002c27ae9ac
> # bad: [e5b1cee1bb9d8a66b28d64db9d8250ae2b0803d2] Merge
> remote-tracking branch 'tty/tty-next'
> git bisect bad e5b1cee1bb9d8a66b28d64db9d8250ae2b0803d2
> # good: [81cde6aecf21113c6bc65bc944587db4cbd3f64d] Merge
> remote-tracking branch 'mmc/next'
> git bisect good 81cde6aecf21113c6bc65bc944587db4cbd3f64d
> # bad: [69d76288005784205678520826a74c28e49a1703] Merge
> remote-tracking branch 'tip/auto-latest'
> git bisect bad 69d76288005784205678520826a74c28e49a1703
> # good: [6d32edf2be6c4e0f08b102e2d3227278ebb477c9] Merge
> remote-tracking branch 'spi/for-next'
> git bisect good 6d32edf2be6c4e0f08b102e2d3227278ebb477c9
> # good: [61f63e383784bd0ab6529cfc95ddc59c713afcc9] Merge tag
> 'perf-core-for-mingo-4.12-20170316' of
> git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into
> perf/core
> git bisect good 61f63e383784bd0ab6529cfc95ddc59c713afcc9
> # good: [3069c5a046ec92dc552194686c95e27c8c9e919d] Merge branch 'x86/asm'
> git bisect good 3069c5a046ec92dc552194686c95e27c8c9e919d
> # bad: [5b804ec2fd3272385ba7530c3a67d7402fb6d8a0] Merge branch 'x86/mm'
> git bisect bad 5b804ec2fd3272385ba7530c3a67d7402fb6d8a0
> # good: [06c830a48346643e195801460dfe16d96ba4dff5] x86/power: Add
> 5-level paging support
> git bisect good 06c830a48346643e195801460dfe16d96ba4dff5
> # good: [2bbbd194fdca01f694e2ca3fb447a1acf9d19f76] Merge branch 'x86/cpu'
> git bisect good 2bbbd194fdca01f694e2ca3fb447a1acf9d19f76
> # good: [69218e47994da614e7af600bf06887750ab6657a] x86: Remap GDT
> tables in the fixmap section
> git bisect good 69218e47994da614e7af600bf06887750ab6657a
> # bad: [74c8ce958dbf0b64f198becb5d8aa93afb967438] Merge branch 'linus'
> into x86/mm, to pick up a bugfix
> git bisect bad 74c8ce958dbf0b64f198becb5d8aa93afb967438
> # bad: [45fc8757d1d2128e342b4e7ef39adedf7752faac] x86: Make the GDT
> remapping read-only on 64-bit
> git bisect bad 45fc8757d1d2128e342b4e7ef39adedf7752faac
> # first bad commit: [45fc8757d1d2128e342b4e7ef39adedf7752faac] x86:
> Make the GDT remapping read-only on 64-bit

Just wondering, does the following commit fix it:

  5b781c7e317f x86/tls: Forcibly set the accessed bit in TLS segments

?

Also attached below.

Thanks,

	Ingo

=================>
>From 5b781c7e317fcf9f74475dc82bfce2e359dfca13 Mon Sep 17 00:00:00 2001
From: Andy Lutomirski <luto@kernel.org>
Date: Sat, 18 Mar 2017 22:17:24 -0700
Subject: [PATCH] x86/tls: Forcibly set the accessed bit in TLS segments

For mysterious historical reasons, struct user_desc doesn't indicate
whether segments are accessed.  set_thread_area() has always programmed
segments as non-accessed, so the first write will set the accessed bit.
This will fault if the GDT is read-only.

Fix it by making TLS segments start out accessed.

If this ends up breaking something, we could, in principle, leave TLS
segments non-accessed and fix them up when we get the page fault.  I'd be
surprised, though -- AFAIK all the nasty legacy segmented programs (DOSEMU,
Wine, things that run on DOSEMU and Wine, etc.) do their nasty segmented
things using the LDT and not the GDT.  I assume this is mainly because old
OSes (Linux and otherwise) didn't historically provide APIs to do nasty
things in the GDT.

Fixes: 45fc8757d1d2 ("x86: Make the GDT remapping read-only on 64-bit")
Signed-off-by: Andy Lutomirski <luto@kernel.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Thomas Garnier <thgarnie@google.com>
Link: http://lkml.kernel.org/r/62b7748542df0164af7e0a5231283b9b13858c45.1489900519.git.luto@kernel.org
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
---
 arch/x86/kernel/tls.c | 11 +++++++++--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/arch/x86/kernel/tls.c b/arch/x86/kernel/tls.c
index 6c8934406dc9..dcd699baea1b 100644
--- a/arch/x86/kernel/tls.c
+++ b/arch/x86/kernel/tls.c
@@ -92,10 +92,17 @@ static void set_tls_desc(struct task_struct *p, int idx,
 	cpu = get_cpu();
 
 	while (n-- > 0) {
-		if (LDT_empty(info) || LDT_zero(info))
+		if (LDT_empty(info) || LDT_zero(info)) {
 			desc->a = desc->b = 0;
-		else
+		} else {
 			fill_ldt(desc, info);
+
+			/*
+			 * Always set the accessed bit so that the CPU
+			 * doesn't try to write to the (read-only) GDT.
+			 */
+			desc->type |= 1;
+		}
 		++info;
 		++desc;
 	}

Re: linux-next: x86: Unalbe to run x32 processes on the x86_64 kernel

[Adam Borowski]

On Tue, Mar 21, 2017 at 07:45:39AM +0100, Ingo Molnar wrote:
> * Andrei Vagin <avagin@gmail.com> wrote:
> 
> > # first bad commit: [45fc8757d1d2128e342b4e7ef39adedf7752faac] x86:
> > Make the GDT remapping read-only on 64-bit
> 
> Just wondering, does the following commit fix it:
> 
>   5b781c7e317f x86/tls: Forcibly set the accessed bit in TLS segments

It does fix i386 but not x32.

By "x32" I mean CONFIG_X86_X32, by "i386" CONFIG_IA32_EMULATION, contrary to
Andrei's first report.  The naming of the new ABI wasn't too fortunate...

-- 
⢀⣴⠾⠻⢶⣦⠀ Meow!
⣾⠁⢠⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋⠀ Collisions shmolisions, let's see them find a collision or second
⠈⠳⣄⠀⠀⠀⠀ preimage for double rot13!

Re: linux-next: x86: Unalbe to run x32 processes on the x86_64 kernel

[Thomas Gleixner]

On Tue, 21 Mar 2017, Adam Borowski wrote:
> On Tue, Mar 21, 2017 at 07:45:39AM +0100, Ingo Molnar wrote:
> > * Andrei Vagin <avagin@gmail.com> wrote:
> > 
> > > # first bad commit: [45fc8757d1d2128e342b4e7ef39adedf7752faac] x86:
> > > Make the GDT remapping read-only on 64-bit
> > 
> > Just wondering, does the following commit fix it:
> > 
> >   5b781c7e317f x86/tls: Forcibly set the accessed bit in TLS segments
> 
> It does fix i386 but not x32.
> 
> By "x32" I mean CONFIG_X86_X32, by "i386" CONFIG_IA32_EMULATION, contrary to
> Andrei's first report.  The naming of the new ABI wasn't too fortunate...

The X32 issue is unrelated to the GDT mapping.

What happens is that the mmap rework from Dmitry switched X32 to use 64bit
mappings, which is wrong. X32 has 64bit instructions and syscalls and 32bit
address space.

Dmitry, can you please have a look and fix that up? For reproduction just
compile helloworld.c with gcc -mx32.

Thanks,

	tglx

Re: linux-next: x86: Unalbe to run x32 processes on the x86_64 kernel

[Dmitry Safonov]

On 03/21/2017 03:49 PM, Thomas Gleixner wrote:
> On Tue, 21 Mar 2017, Adam Borowski wrote:
>> On Tue, Mar 21, 2017 at 07:45:39AM +0100, Ingo Molnar wrote:
>>> * Andrei Vagin <avagin@gmail.com> wrote:
>>>
>>>> # first bad commit: [45fc8757d1d2128e342b4e7ef39adedf7752faac] x86:
>>>> Make the GDT remapping read-only on 64-bit
>>>
>>> Just wondering, does the following commit fix it:
>>>
>>>   5b781c7e317f x86/tls: Forcibly set the accessed bit in TLS segments
>>
>> It does fix i386 but not x32.
>>
>> By "x32" I mean CONFIG_X86_X32, by "i386" CONFIG_IA32_EMULATION, contrary to
>> Andrei's first report.  The naming of the new ABI wasn't too fortunate...
>
> The X32 issue is unrelated to the GDT mapping.
>
> What happens is that the mmap rework from Dmitry switched X32 to use 64bit
> mappings, which is wrong. X32 has 64bit instructions and syscalls and 32bit
> address space.

Hmm, in_compat_syscall() checks x32 syscall bit.
I'll take a look, what happens there.

> Dmitry, can you please have a look and fix that up? For reproduction just
> compile helloworld.c with gcc -mx32.

Sure, thanks.

-- 
              Dmitry

Re: linux-next: x86: Unalbe to run x32 processes on the x86_64 kernel

[Dmitry Safonov]

On 03/21/2017 03:50 PM, Dmitry Safonov wrote:
> On 03/21/2017 03:49 PM, Thomas Gleixner wrote:
>> On Tue, 21 Mar 2017, Adam Borowski wrote:
>>> On Tue, Mar 21, 2017 at 07:45:39AM +0100, Ingo Molnar wrote:
>>>> * Andrei Vagin <avagin@gmail.com> wrote:
>>>>
>>>>> # first bad commit: [45fc8757d1d2128e342b4e7ef39adedf7752faac] x86:
>>>>> Make the GDT remapping read-only on 64-bit
>>>>
>>>> Just wondering, does the following commit fix it:
>>>>
>>>>   5b781c7e317f x86/tls: Forcibly set the accessed bit in TLS segments
>>>
>>> It does fix i386 but not x32.
>>>
>>> By "x32" I mean CONFIG_X86_X32, by "i386" CONFIG_IA32_EMULATION,
>>> contrary to
>>> Andrei's first report.  The naming of the new ABI wasn't too
>>> fortunate...
>>
>> The X32 issue is unrelated to the GDT mapping.
>>
>> What happens is that the mmap rework from Dmitry switched X32 to use
>> 64bit
>> mappings, which is wrong. X32 has 64bit instructions and syscalls and
>> 32bit
>> address space.
>
> Hmm, in_compat_syscall() checks x32 syscall bit.

Which is not set during exec() for x32. So in_compat_syscall() doesn't
work there.
I've tested this patch on x32-debian port:
https://lkml.org/lkml/2017/3/21/489

Though I'm not very happy with the resulting patch :(
Maybe one could suggest a better idea..

> I'll take a look, what happens there.
>
>> Dmitry, can you please have a look and fix that up? For reproduction just
>> compile helloworld.c with gcc -mx32.
>
> Sure, thanks.
>

-- 
              Dmitry

Re: linux-next: x86: Unalbe to run x32 processes on the x86_64 kernel

[Andy Lutomirski]

On Tue, Mar 21, 2017 at 8:59 AM, Dmitry Safonov <dsafonov@virtuozzo.com> wrote:
> On 03/21/2017 03:50 PM, Dmitry Safonov wrote:
>>
>> On 03/21/2017 03:49 PM, Thomas Gleixner wrote:
>>>
>>> On Tue, 21 Mar 2017, Adam Borowski wrote:
>>>>
>>>> On Tue, Mar 21, 2017 at 07:45:39AM +0100, Ingo Molnar wrote:
>>>>>
>>>>> * Andrei Vagin <avagin@gmail.com> wrote:
>>>>>
>>>>>> # first bad commit: [45fc8757d1d2128e342b4e7ef39adedf7752faac] x86:
>>>>>> Make the GDT remapping read-only on 64-bit
>>>>>
>>>>>
>>>>> Just wondering, does the following commit fix it:
>>>>>
>>>>>   5b781c7e317f x86/tls: Forcibly set the accessed bit in TLS segments
>>>>
>>>>
>>>> It does fix i386 but not x32.
>>>>
>>>> By "x32" I mean CONFIG_X86_X32, by "i386" CONFIG_IA32_EMULATION,
>>>> contrary to
>>>> Andrei's first report.  The naming of the new ABI wasn't too
>>>> fortunate...
>>>
>>>
>>> The X32 issue is unrelated to the GDT mapping.
>>>
>>> What happens is that the mmap rework from Dmitry switched X32 to use
>>> 64bit
>>> mappings, which is wrong. X32 has 64bit instructions and syscalls and
>>> 32bit
>>> address space.
>>
>>
>> Hmm, in_compat_syscall() checks x32 syscall bit.
>
>
> Which is not set during exec() for x32. So in_compat_syscall() doesn't
> work there.
> I've tested this patch on x32-debian port:
> https://lkml.org/lkml/2017/3/21/489

Seems generally reasonable to me.  It aligns x32 with existing
practice for i386, I think.

>
> Though I'm not very happy with the resulting patch :(
> Maybe one could suggest a better idea..

IMO it would be nice if execve() didn't call into any function that
checked in_compat_syscall(), etc, but maybe that's a pipe dream.