Bug#849923: openssh-server: no login possible after upgrade on x32
On 2017-01-02 17:49, Colin Watson wrote:
> 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.)
Looking at the issue, it actually appears in __vdso_clock_gettime, which
is provided by the kernel. This code handle the simple cases (REALTIME,
MONOTONIC, REALTIME_COARSE and _MONOTONIC_COARSE) and fallbacks to
the syscall in otherwise, CLOCK_BOOTTIME in the case of sshd.
This therefore looks like a kernel issue to me.
Aurelien
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurelien@aurel32.net http://www.aurel32.net
Reply to: