On Mon, Jan 02, 2017 at 11:36:55AM +0100, Thorsten Glaser wrote: > After upgrading from 1:7.3p1-5 to 1:7.4p1-3 I can no longer > 'ssh localhost' on x32; switching to openssh-server:i386 with > the exact same configuration works, though.
sshd's seccomp sandbox is denying a clock_gettime call. But it's more interesting than that: its seccomp filter allows clock_gettime; but the actual syscall being used is not the x32 clock_gettime (with bit 30 set), but the x86-64 variant instead. You can see a similar effect like this in an x32 environment: strace dmesg -e ... and buried in the output you'll find something like: strace: syscall_228(...) in unsupported 64-bit mode of process PID=19943 Neither sshd nor dmesg is using anything like manual syscall(2) here, just the glibc wrappers. This feels like a glibc bug to me. Shouldn't it be using x32 syscalls consistently? The x86-64 variants work, but that's not very seccomp-friendly. (And if necessary I can hack around it in sshd, but if you agree that it's a glibc bug then I think it should simply be fixed there.) Thanks, -- Colin Watson [cjwat...@debian.org]