Re: Bug#849923: openssh-server: no login possible after upgrade on x32
clone 849923 -1
reassign -1 linux
retitle -1 linux: x32 __vdso_clock_gettime falls back to x86-64 syscall
thanks
On Tue, Jan 03, 2017 at 02:31:35PM +0100, Thorsten Glaser wrote:
> On Mon, 2 Jan 2017, Aurelien Jarno wrote:
> > 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.
>
> Ouch – and the kernel probably thinks it’s getting away with this as
> the kernel architecture is amd64…
>
> Can you please forward this to someone at the kernel side (either Debian
> or upstream) who can have a look? In the meantime, I’ll point this issue
> out in #debian-x32 on IRC, so the other porters can also look.
I've cloned a kernel bug for this with this message.
> > On 2017-01-02 17:49, Colin Watson wrote:
>
> > > sshd's seccomp sandbox is denying a clock_gettime call. But it's more
>
> Probably a stupid idea, but a short-term stopgap: can we disable seccomp
> on x32 for now? That needs:
Here's a better stopgap that lets us keep the sandbox enabled:
https://anonscm.debian.org/cgit/pkg-ssh/openssh.git/commit/?id=e346421ca6852fbf9f95cf0e764ecc345e5ce21d
> • in debian/rules:
> +confflags += --host=${DEB_HOST_GNU_TYPE}
> This sets $host to x86_64-pc-linux-gnux32 instead of the
> auto-detected x86_64-pc-linux-gnu (which is amd64)
Unnecessary: the default is --build=x86_64-linux-gnux32, and --host
shouldn't be passed when not cross-compiling.
You're probably being misled by config.guess's default, but that's
already overridden appropriately by dpkg/debhelper.
Cheers,
--
Colin Watson [cjwat...@debian.org]
Re: Bug#849923: openssh-server: no login possible after upgrade on x32
On Mon, 2 Jan 2017, Aurelien Jarno wrote:
> 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.
Ouch – and the kernel probably thinks it’s getting away with this as
the kernel architecture is amd64…
Can you please forward this to someone at the kernel side (either Debian
or upstream) who can have a look? In the meantime, I’ll point this issue
out in #debian-x32 on IRC, so the other porters can also look.
> On 2017-01-02 17:49, Colin Watson wrote:
> > sshd's seccomp sandbox is denying a clock_gettime call. But it's more
Probably a stupid idea, but a short-term stopgap: can we disable seccomp
on x32 for now? That needs:
• in debian/rules:
+confflags += --host=${DEB_HOST_GNU_TYPE}
This sets $host to x86_64-pc-linux-gnux32 instead of the
auto-detected x86_64-pc-linux-gnu (which is amd64)
• in configure.ac:
AC_MSG_CHECKING([for seccomp architecture])
seccomp_audit_arch=
case "$host" in
+x86_64-*-gnux32)
+ # disabled for now, see Debian #849923
+ ;;
x86_64-*)
seccomp_audit_arch=AUDIT_ARCH_X86_64
;;
With this, we can then also later fix the architecture, should
the kernel be fixed.
Thanks,
//mirabilos
--
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg
Re: 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 aurel...@aurel32.net http://www.aurel32.net
Re: Bug#849923: openssh-server: no login possible after upgrade on x32
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]
