Bug#708070: enable x32 support for the amd64 kernels

2014-07-26 Thread Robert de Bath

On Fri, 25 Jul 2014, Robert de Bath wrote:


On Fri, 25 Jul 2014, Ben Hutchings wrote:


I had an idea how to unblock this, and finally got round to trying it,
and it seems to work.  That is, we build in x32 support but require a
run-time parameter to enable.  So, please try the attached patch
(against the sid branch), adding syscall.x32=y to the kernel command
line.

Okay,
With the flag set the kernel boots happily and runs gcc-mx32 executables.

With the flag off ...
First (simple) thing; with the patch in the kernel tree there is no
configuration to default the x32 switch to on. Thinking ahead to when
this may be well tested, I think it'd be nice if there were a .config
option to default this patch to enabling the x32 syscalls and have a
kernel command line option to disable them in special cases.

More importantly ...  this is rather ugly; I think you're going to get
complaints when ld.so segfaults.

You may want to reinstate the ENOEXEC error for the 'wrong sort' of executables.

# strace  ./x
execve(./x, [./x], [/* 17 vars */]) = 0
[ Process PID=12286 runs in x32 mode. ]
brk(0)  = -1 ENOSYS (Function not implemented)
access(/etc/ld.so.nohwcap, F_OK)  = -1 ENOSYS (Function not implemented)
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = -1 
ENOSYS (Function not implemented)
writev(2, [{./x, 3}, {: , 2}, {error while loading shared libra..., 36}, {: , 2}, {, 0}, {, 0}, 
{cannot create cache for search p..., 35}, {: , 2}, {Cannot allocate memory, 22}, {\n, 1}], 10) = -1 ENOSYS (Function not 
implemented)
exit_group(127) = ?
... exit_group resumed _exit returned!
)  = ?
_exit(127)  = ?
... _exit resumed _exit returned!
)   = ?
--- SIGSEGV {si_signo=SIGSEGV, si_code=SI_KERNEL, si_addr=0} ---
+++ killed by SIGSEGV +++
Segmentation fault
#


--
Rob.  (Robert de Bath robert$ @ debath.co.uk)
 http://www.debath.co.uk/


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#708070: enable x32 support for the amd64 kernels

2014-07-26 Thread Ben Hutchings
On Sat, 2014-07-26 at 10:52 +0100, Robert de Bath wrote:
 On Fri, 25 Jul 2014, Robert de Bath wrote:
 
  On Fri, 25 Jul 2014, Ben Hutchings wrote:
 
  I had an idea how to unblock this, and finally got round to trying it,
  and it seems to work.  That is, we build in x32 support but require a
  run-time parameter to enable.  So, please try the attached patch
  (against the sid branch), adding syscall.x32=y to the kernel command
  line.
 Okay,
 With the flag set the kernel boots happily and runs gcc-mx32 executables.
 
 With the flag off ...
 First (simple) thing; with the patch in the kernel tree there is no
 configuration to default the x32 switch to on. Thinking ahead to when
 this may be well tested, I think it'd be nice if there were a .config
 option to default this patch to enabling the x32 syscalls and have a
 kernel command line option to disable them in special cases.
 
 More importantly ...  this is rather ugly; I think you're going to get
 complaints when ld.so segfaults.
 
 You may want to reinstate the ENOEXEC error for the 'wrong sort' of 
 executables.
[...]

What do you mean, reinstate?  This is the same behaviour you get at
present.  Well, here's a new version that might do that.

Ben.

-- 
Ben Hutchings
73.46% of all statistics are made up.
Index: linux/debian/changelog
===
--- linux/debian/changelog	(revision 21631)
+++ linux/debian/changelog	(working copy)
@@ -1,3 +1,11 @@
+linux (3.14.13-2+x32) UNRELEASED; urgency=medium
+
+  [ Ben Hutchings ]
+  * [amd64] Enable X86_X32 (Closes: #708070)
+  * [amd64] syscall: Make x32 syscall support conditional on a kernel parameter
+
+ -- Ben Hutchings b...@decadent.org.uk  Fri, 25 Jul 2014 01:48:06 +0100
+
 linux (3.14.13-2) unstable; urgency=medium
 
   [ Aurelien Jarno ]
Index: linux/debian/config/kernelarch-x86/config-arch-64
===
--- linux/debian/config/kernelarch-x86/config-arch-64	(revision 21631)
+++ linux/debian/config/kernelarch-x86/config-arch-64	(working copy)
@@ -15,7 +15,7 @@
 CONFIG_NUMA_EMU=y
 CONFIG_PCI_MMCONFIG=y
 CONFIG_ISA_DMA_API=y
-# CONFIG_X86_X32 is not set
+CONFIG_X86_X32=y
 
 ##
 ## file: arch/x86/Kconfig.cpu
Index: linux/debian/patches/bugfix/x86/x86-reject-x32-executables-if-x32-abi-not-supported.patch
===
--- linux/debian/patches/bugfix/x86/x86-reject-x32-executables-if-x32-abi-not-supported.patch	(revision 0)
+++ linux/debian/patches/bugfix/x86/x86-reject-x32-executables-if-x32-abi-not-supported.patch	(working copy)
@@ -0,0 +1,18 @@
+From: Ben Hutchings b...@decadent.org.uk
+Date: Sat, 26 Jul 2014 15:03:11 +0100
+Subject: x86: Reject x32 executables if x32 ABI not supported
+
+--- a/arch/x86/include/asm/elf.h
 b/arch/x86/include/asm/elf.h
+@@ -155,8 +155,9 @@ do {		\
+ #define elf_check_arch(x)			\
+ 	((x)-e_machine == EM_X86_64)
+ 
+-#define compat_elf_check_arch(x)		\
+-	(elf_check_arch_ia32(x) || (x)-e_machine == EM_X86_64)
++#define compat_elf_check_arch(x)	\
++	(elf_check_arch_ia32(x) ||	\
++	 (IS_ENABLED(CONFIG_X86_X32_ABI)  (x)-e_machine == EM_X86_64))
+ 
+ #if __USER32_DS != __USER_DS
+ # error The following code assumes __USER32_DS == __USER_DS
Index: linux/debian/patches/features/x86/x86-syscall-make-x32-syscall-support-conditional.patch
===
--- linux/debian/patches/features/x86/x86-syscall-make-x32-syscall-support-conditional.patch	(revision 0)
+++ linux/debian/patches/features/x86/x86-syscall-make-x32-syscall-support-conditional.patch	(working copy)
@@ -0,0 +1,164 @@
+From: Ben Hutchings b...@decadent.org.uk
+Date: Fri, 25 Jul 2014 01:16:15 +0100
+Subject: x86/syscall: Make x32 syscall support conditional on a kernel parameter
+Bug-Debian: https://bugs.debian.org/708070
+
+Enabling x32 in the standard amd64 kernel would increase its attack
+surface while provide no benefit to the vast majority of its users.
+No-one seems interested in regularly checking for vulnerabilities
+specific to x32 (at least no-one with a white hat).
+
+Still, adding another flavour just to turn on x32 seems wasteful.  And
+the only difference on syscall entry is whether we mask the x32 flag
+out of the syscall number before range-checking it.
+
+So replace the mask (andl) instruction with a nop and add a kernel
+parameter syscall.x32 which allows it to be turned back on again.
+
+Change the comparison instruction to cmpq because the upper 32 bits
+may or may not be cleared by the previous instruction.
+
+--- a/arch/x86/kernel/entry_64.S
 b/arch/x86/kernel/entry_64.S
+@@ -618,12 +618,14 @@ GLOBAL(system_call_after_swapgs)
+ 	testl $_TIF_WORK_SYSCALL_ENTRY,TI_flags+THREAD_INFO(%rsp,RIP-ARGOFFSET)
+ 	jnz tracesys
+ system_call_fastpath:
+-#if __SYSCALL_MASK == ~0
+-	cmpq $__NR_syscall_max,%rax
+-#else
+-	andl $__SYSCALL_MASK,%eax
+-	cmpl $__NR_syscall_max,%eax

Bug#708070: enable x32 support for the amd64 kernels

2014-07-26 Thread Robert de Bath

On Sat, 26 Jul 2014, Ben Hutchings wrote:


On Sat, 2014-07-26 at 10:52 +0100, Robert de Bath wrote:

On Fri, 25 Jul 2014, Robert de Bath wrote:


On Fri, 25 Jul 2014, Ben Hutchings wrote:


What do you mean, reinstate?  This is the same behaviour you get at
present.  Well, here's a new version that might do that.

I was sure ... hmmm, segfault? ... Oh I see.

I'd copied the (static) exe to a wheezy (3.2 kernel) machine; that's
where it gives a 'cannot execute' error. I suppose that means it's an
upstream 'bug'.

Okay, the new patch is good for me. I've again tried it with the flag
both ways. It runs the executables correctly when the flag is set and
gives a reasonably nice (and quite specific) error when it's not. (Exec
format error)

I also have a i386 userspace running happily.

I'd say it's good to go.


Ben.

--
Ben Hutchings
73.46% of all statistics are made up.


--
Rob.  (Robert de Bath robert$ @ debath.co.uk)
 http://www.debath.co.uk/


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#708070: enable x32 support for the amd64 kernels

2014-07-26 Thread Ben Hutchings
On Sat, 2014-07-26 at 21:05 +0100, Robert de Bath wrote:
 On Sat, 26 Jul 2014, Ben Hutchings wrote:
 
  On Sat, 2014-07-26 at 10:52 +0100, Robert de Bath wrote:
  On Fri, 25 Jul 2014, Robert de Bath wrote:
 
  On Fri, 25 Jul 2014, Ben Hutchings wrote:
 
  What do you mean, reinstate?  This is the same behaviour you get at
  present.  Well, here's a new version that might do that.
 I was sure ... hmmm, segfault? ... Oh I see.
 
 I'd copied the (static) exe to a wheezy (3.2 kernel) machine; that's
 where it gives a 'cannot execute' error.

Linux 3.2 predates addition of x32 support.

 I suppose that means it's an upstream 'bug'.

Yes, I would say so.

 Okay, the new patch is good for me. I've again tried it with the flag
 both ways. It runs the executables correctly when the flag is set and
 gives a reasonably nice (and quite specific) error when it's not. (Exec
 format error)
 
 I also have a i386 userspace running happily.
 
 I'd say it's good to go.

Great!

But I should maybe add the config option you suggested, so people can
build custom kernels from Debian source that won't need this parameter.

Ben.

-- 
Ben Hutchings
The generation of random numbers is too important to be left to chance.
- Robert Coveyou


signature.asc
Description: This is a digitally signed message part


Bug#708070: enable x32 support for the amd64 kernels

2014-07-25 Thread Robert de Bath

On Fri, 25 Jul 2014, Ben Hutchings wrote:


No, there should be no extra kernel flavours for i386 or amd64.

Hmm, still not getting this. I thought the point of flavours was to split
off options that, though popular, have undesirable side effects.


I had an idea how to unblock this, and finally got round to trying it,
and it seems to work.  That is, we build in x32 support but require a
run-time parameter to enable.  So, please try the attached patch
(against the sid branch), adding syscall.x32=y to the kernel command
line.

But this sounds perfectly acceptable.


The general instructions for building a patched package are:
http://kernel-handbook.alioth.debian.org/ch-common-tasks.html#s-common-official.

Oh, yes ... I remember that :-(


You'll need to follow subsection 4.2.3 and apply the patch like so:
   patch -p1  ../x86-syscall-make-x32-syscall-support-conditional.patch
   quilt push

Will try this shortly. Though I may have to spin up a VM to build it.

--
Rob.  (Robert de Bath robert$ @ debath.co.uk)
 http://www.debath.co.uk/


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#708070: enable x32 support for the amd64 kernels

2014-07-24 Thread Carlos Alberto Lopez Perez
I was just hit by bug https://bugs.debian.org/736659 after installing
gcc-multilib and later rebuilding my initramfs.

I don't think this situation of having several x32 packages on the
archive (which other packages depend on) while the official debian
kernel don't supports x32 at all is sustainable in the long run.

Please consider enabling CONFIG_X86_X32 on 3.14 and superior.

Thanks



signature.asc
Description: OpenPGP digital signature


Bug#708070: enable x32 support for the amd64 kernels

2014-07-24 Thread Ian Campbell
On Thu, 2014-07-24 at 13:20 +0200, Carlos Alberto Lopez Perez wrote:
 I was just hit by bug https://bugs.debian.org/736659 after installing
 gcc-multilib and later rebuilding my initramfs.
 
 I don't think this situation of having several x32 packages on the
 archive (which other packages depend on) while the official debian
 kernel don't supports x32 at all is sustainable in the long run.
 
 Please consider enabling CONFIG_X86_X32 on 3.14 and superior.

I think Ben has been pretty clear in his first reply to this bugreport
about what needs to happen first.

Ian.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#708070: enable x32 support for the amd64 kernels

2014-07-24 Thread Robert de Bath

On Thu, 24 Jul 2014, Ian Campbell wrote:


On Thu, 2014-07-24 at 13:20 +0200, Carlos Alberto Lopez Perez wrote:

I was just hit by bug https://bugs.debian.org/736659 after installing
gcc-multilib and later rebuilding my initramfs.

I don't think this situation of having several x32 packages on the
archive (which other packages depend on) while the official debian
kernel don't supports x32 at all is sustainable in the long run.

Please consider enabling CONFIG_X86_X32 on 3.14 and superior.


I think Ben has been pretty clear in his first reply to this bugreport
about what needs to happen first.


Yes, he's made it clear that such a kernel would be considered as much of
a risk as the amd64 syscalls were originally. So I've been quietly waiting
for them to be treated the same way ... When are we going to get a special
variant of the kernel package with this attribute turned on ?

--
Rob.  (Robert de Bath robert$ @ debath.co.uk)
 http://www.debath.co.uk/


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#708070: enable x32 support for the amd64 kernels

2014-07-24 Thread Ian Campbell
On Thu, 2014-07-24 at 20:22 +0100, Robert de Bath wrote:
 On Thu, 24 Jul 2014, Ian Campbell wrote:
 
  On Thu, 2014-07-24 at 13:20 +0200, Carlos Alberto Lopez Perez wrote:
  I was just hit by bug https://bugs.debian.org/736659 after installing
  gcc-multilib and later rebuilding my initramfs.
 
  I don't think this situation of having several x32 packages on the
  archive (which other packages depend on) while the official debian
  kernel don't supports x32 at all is sustainable in the long run.
 
  Please consider enabling CONFIG_X86_X32 on 3.14 and superior.
 
  I think Ben has been pretty clear in his first reply to this bugreport
  about what needs to happen first.
 
 Yes, he's made it clear that such a kernel would be considered as much of
 a risk as the amd64 syscalls were originally. So I've been quietly waiting
 for them to be treated the same way ... When are we going to get a special
 variant of the kernel package with this attribute turned on ?

amd64 was a complete new arch, so an arch=amd64 kernel came along with
it.

But that's rather different to now enabling x32 in the arch=amd64 kernel
which is what #708070 is about. Likewise creating a new
flavour=x86,arch=amd64 kernel.

What the people responsible for the x32 arch on debian-ports do wrt an
arch=x32 flavour is up to them, but that's the situation analogous to
what you are referring to.

Ian.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#708070: enable x32 support for the amd64 kernels

2014-07-24 Thread Robert de Bath

On Thu, 24 Jul 2014, Ian Campbell wrote:


On Thu, 2014-07-24 at 20:22 +0100, Robert de Bath wrote:

On Thu, 24 Jul 2014, Ian Campbell wrote:


But that's rather different to now enabling x32 in the arch=amd64 kernel
which is what #708070 is about. Likewise creating a new
flavour=x86,arch=amd64 kernel.

What the people responsible for the x32 arch on debian-ports do wrt an
arch=x32 flavour is up to them, but that's the situation analogous to
what you are referring to.

Ian.


I was referring to the package that's now called
linux-image-3.14-1-amd64:i386 not linux-image-3.14-1-amd64:amd64

The equivalents would be approximatly linux-image-3.14-1-x32:amd64 and
linux-image-3.14-1-x32:i386 not any packages in the new port.

Frankly when Ben said ... those where the administrator actually wants to
support x32. I took that to be him hinting that there would be such a 
package shortly so the administrator could make the choice easily.


As that doesn't seem to be the case I decided to speak up; but now I'm
wondering where you're going with this?


--
To unsubscribe, send mail to 708070-unsubscr...@bugs.debian.org.


--
Rob.  (Robert de Bath robert$ @ debath.co.uk)
 http://www.debath.co.uk/


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#708070: enable x32 support for the amd64 kernels

2014-07-24 Thread Ben Hutchings
Control: tag -1 patch

On Thu, 2014-07-24 at 21:47 +0100, Robert de Bath wrote:
 On Thu, 24 Jul 2014, Ian Campbell wrote:
 
  On Thu, 2014-07-24 at 20:22 +0100, Robert de Bath wrote:
  On Thu, 24 Jul 2014, Ian Campbell wrote:
 
  But that's rather different to now enabling x32 in the arch=amd64 kernel
  which is what #708070 is about. Likewise creating a new
  flavour=x86,arch=amd64 kernel.
 
  What the people responsible for the x32 arch on debian-ports do wrt an
  arch=x32 flavour is up to them, but that's the situation analogous to
  what you are referring to.
 
  Ian.
 
 I was referring to the package that's now called
 linux-image-3.14-1-amd64:i386 not linux-image-3.14-1-amd64:amd64
 
 The equivalents would be approximatly linux-image-3.14-1-x32:amd64 and
 linux-image-3.14-1-x32:i386 not any packages in the new port.
[...]

No, there should be no extra kernel flavours for i386 or amd64.

I had an idea how to unblock this, and finally got round to trying it,
and it seems to work.  That is, we build in x32 support but require a
run-time parameter to enable.  So, please try the attached patch
(against the sid branch), adding syscall.x32=y to the kernel command
line.

The general instructions for building a patched package are:
http://kernel-handbook.alioth.debian.org/ch-common-tasks.html#s-common-official.
 

You'll need to follow subsection 4.2.3 and apply the patch like so:
patch -p1  ../x86-syscall-make-x32-syscall-support-conditional.patch
quilt push

You won't need to change the ABI name.

Ben.

-- 
Ben Hutchings
Absolutum obsoletum. (If it works, it's out of date.) - Stafford Beer
Index: linux/debian/changelog
===
--- linux/debian/changelog	(revision 21631)
+++ linux/debian/changelog	(working copy)
@@ -1,3 +1,11 @@
+linux (3.14.13-2+x32) UNRELEASED; urgency=medium
+
+  [ Ben Hutchings ]
+  * [amd64] Enable X86_X32 (Closes: #708070)
+  * [amd64] syscall: Make x32 syscall support conditional on a kernel parameter
+
+ -- Ben Hutchings b...@decadent.org.uk  Fri, 25 Jul 2014 01:48:06 +0100
+
 linux (3.14.13-2) unstable; urgency=medium
 
   [ Aurelien Jarno ]
Index: linux/debian/config/kernelarch-x86/config-arch-64
===
--- linux/debian/config/kernelarch-x86/config-arch-64	(revision 21631)
+++ linux/debian/config/kernelarch-x86/config-arch-64	(working copy)
@@ -15,7 +15,7 @@
 CONFIG_NUMA_EMU=y
 CONFIG_PCI_MMCONFIG=y
 CONFIG_ISA_DMA_API=y
-# CONFIG_X86_X32 is not set
+CONFIG_X86_X32=y
 
 ##
 ## file: arch/x86/Kconfig.cpu
Index: linux/debian/patches/features/x86/x86-syscall-make-x32-syscall-support-conditional.patch
===
--- linux/debian/patches/features/x86/x86-syscall-make-x32-syscall-support-conditional.patch	(revision 0)
+++ linux/debian/patches/features/x86/x86-syscall-make-x32-syscall-support-conditional.patch	(working copy)
@@ -0,0 +1,140 @@
+From: Ben Hutchings b...@decadent.org.uk
+Date: Fri, 25 Jul 2014 01:16:15 +0100
+Subject: x86/syscall: Make x32 syscall support conditional on a kernel parameter
+Bug-Debian: https://bugs.debian.org/708070
+
+Enabling x32 in the standard amd64 kernel would increase its attack
+surface while provide no benefit to the vast majority of its users.
+No-one seems interested in regularly checking for vulnerabilities
+specific to x32 (at least no-one with a white hat).
+
+Still, adding another flavour just to turn on x32 seems wasteful.  And
+the only difference on syscall entry is whether we mask the x32 flag
+out of the syscall number before range-checking it.
+
+So replace the mask (andl) instruction with a nop and add a kernel
+parameter syscall.x32 which allows it to be turned back on again.
+
+Change the comparison instruction to cmpq because the upper 32 bits
+may or may not be cleared by the previous instruction.
+
+--- a/arch/x86/kernel/entry_64.S
 b/arch/x86/kernel/entry_64.S
+@@ -618,12 +618,14 @@ GLOBAL(system_call_after_swapgs)
+ 	testl $_TIF_WORK_SYSCALL_ENTRY,TI_flags+THREAD_INFO(%rsp,RIP-ARGOFFSET)
+ 	jnz tracesys
+ system_call_fastpath:
+-#if __SYSCALL_MASK == ~0
+-	cmpq $__NR_syscall_max,%rax
+-#else
+-	andl $__SYSCALL_MASK,%eax
+-	cmpl $__NR_syscall_max,%eax
++#if __SYSCALL_MASK != ~0
++	.globl system_call_fast_maybe_mask
++	.globl system_call_fast_masked
++system_call_fast_maybe_mask:
++	.byte P6_NOP5_ATOMIC
++system_call_fast_masked:
+ #endif
++	cmpq $__NR_syscall_max,%rax
+ 	ja badsys
+ 	movq %r10,%rcx
+ 	call *sys_call_table(,%rax,8)  # XXX:	 rip relative
+@@ -737,12 +739,14 @@ tracesys:
+ 	 */
+ 	LOAD_ARGS ARGOFFSET, 1
+ 	RESTORE_REST
+-#if __SYSCALL_MASK == ~0
+-	cmpq $__NR_syscall_max,%rax
+-#else
+-	andl $__SYSCALL_MASK,%eax
+-	cmpl $__NR_syscall_max,%eax
++#if __SYSCALL_MASK != ~0
++	.globl system_call_trace_maybe_mask
++	.globl system_call_trace_masked
++system_call_trace_maybe_mask:
++	.byte P6_NOP5_ATOMIC
++system_call_trace_masked:
+ 

Bug#708070: enable x32 support for the amd64 kernels

2013-05-12 Thread Matthias Klose
Package: linux
Severity: wishlist

Please enable support for the x32 syscalls, so that it becomes possible to run a
x32 chroot on such a kernel.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org