Grant Erickson
2023-Nov-03 15:28 UTC
9.3p1 Daemon Rejects Client Connections on armv7l-dey-linux-gnueabihf w/ GCC 10/11/12
On Nov 2, 2023, at 4:39 PM, Grant Erickson <gerickson at nuovations.com> wrote:> On Nov 2, 2023, at 4:32 PM, Damien Miller <djm at mindrot.org> wrote: >> On Mon, 30 Oct 2023, Grant Erickson wrote: >> >>> I have an NXP i.MX6-based armv7l-dey-linux-gnueabihf system in which I >>> am seeing some as-yet-unaccountable behavior in sshd when compiled with >>> Arm/GCC 10/11/12. That is, when attempting to scp/slogin/ssh to >>> 'root@<host>', where <host> is either a name or IPv4 or IPv6 address, >>> the connection is quickly closed by the server without prompting for a >>> password. >>> >>> The variable I can consistently change across all others to impact >>> whether things work or do not work is the toolchain. Under the >>> arm-dey-linux-gnueabi-gcc 8.2.0 from Digi Embedded Yocto (DEY), >>> scp/slogin/ssh works. Under arm-none-linux-gnueabihf-gcc 10/11/12 >>> (specifically those from https://developer.arm.com/-/media/Files/downloads/gnu-a/10.3-2021.07/binrel/gcc-arm-10.3-2021.07-x86_64-arm-none-linux-gnueabihf.tar.xz, https://developer.arm.com/-/media/Files/downloads/gnu/11.3.rel1/binrel/arm-gnu-toolchain-11.3.rel1-x86_64-arm-none-linux-gnueabihf.tar.xz, and https://developer.arm.com/-/media/Files/downloads/gnu/12.3.rel1/binrel/arm-gnu-toolchain-12.3.rel1-x86_64-arm-none-linux-gnueabihf.tar.xz) they do not, failing consistently and with the same failure across the three of them. >> >> This might be a syscall sandbox violation. Try building with >> SANDBOX_SECCOMP_FILTER_DEBUG defined and see if you get any more information. > > Thanks for the reply. I?ll give that a try and report back.Damien, Thank you; that was an absolutely golden recommendation. Turning on SANDBOX_SECCOMP_FILTER_DEBUG was the magic, that did, in fact, uncover an unexpected system call violation: ? debug3: monitor_read: checking request 6 debug3: mm_answer_sign: entering debug3: mm_answer_sign: ecdsa-sha2-nistp256 KEX signature len=101 debug3: mm_request_send: entering, type 7 debug2: monitor_read: 6 used once, disabling now debug3: send packet: type 31 [preauth] debug3: send packet: type 21 [preauth] debug2: ssh_set_newkeys: mode 1 [preauth] debug1: rekey out after 134217728 blocks [preauth] ssh_sandbox_violation: unexpected system call (arch:0x40000028,syscall:403 @ 0x76ccaa66) [preauth] debug1: monitor_read_log: child log fd closed debug3: mm_request_receive: entering debug1: do_cleanup debug1: Killing privsep child 528 ... The last defined system call in <asm/unistd-common.h> is __NR_io_pgetevents, 399. According to this URL, https://gpages.juszkiewicz.com.pl/syscalls-table/syscalls.html, system call 403 is clock_gettime64 in Arm32. clock_gettime64 is not defined for the older Digi DEY 8.2.0 toolchain that does work with OpenSSH: % grep -r clock_gettime64 /opt/sysroots/cortexa9t2hf-neon-dey-linux-gnueabi/ /opt/sysroots/x86_64-deysdk-linux/ but is defined for Arm GNU Toolchain 12.3.1 (and 11.3.1 and 10.3-2021.07): % grep -r clock_gettime64 /opt/sysroots/arm-gnu-toolchain-12.3.rel1-x86_64-arm-none-linux-gnueabihf/ /opt/sysroots/arm-gnu-toolchain-12.3.rel1-x86_64-arm-none-linux-gnueabihf/arm-none-linux-gnueabihf/libc/usr/include/bits/syscall.h:#ifdef __NR_clock_gettime64 /opt/sysroots/arm-gnu-toolchain-12.3.rel1-x86_64-arm-none-linux-gnueabihf/arm-none-linux-gnueabihf/libc/usr/include/bits/syscall.h:# define SYS_clock_gettime64 __NR_clock_gettime64 /opt/sysroots/arm-gnu-toolchain-12.3.rel1-x86_64-arm-none-linux-gnueabihf/arm-none-linux-gnueabihf/libc/usr/include/time.h: timespec *__tp), __clock_gettime64) /opt/sysroots/arm-gnu-toolchain-12.3.rel1-x86_64-arm-none-linux-gnueabihf/arm-none-linux-gnueabihf/libc/usr/include/time.h:# define clock_gettime __clock_gettime64 The <time.h> header has this block: #ifdef __USE_POSIX199309 # ifndef __USE_TIME_BITS64 /* Pause execution for a number of nanoseconds. This function is a cancellation point and therefore not marked with __THROW. */ extern int nanosleep (const struct timespec *__requested_time, struct timespec *__remaining); /* Get resolution of clock CLOCK_ID. */ extern int clock_getres (clockid_t __clock_id, struct timespec *__res) __THROW; /* Get current value of clock CLOCK_ID and store it in TP. */ extern int clock_gettime (clockid_t __clock_id, struct timespec *__tp) __THROW __nonnull((2)); /* Set clock CLOCK_ID to value TP. */ extern int clock_settime (clockid_t __clock_id, const struct timespec *__tp) __THROW __nonnull((2)); # else # ifdef __REDIRECT extern int __REDIRECT (nanosleep, (const struct timespec *__requested_time, struct timespec *__remaining), __nanosleep64); extern int __REDIRECT_NTH (clock_getres, (clockid_t __clock_id, struct timespec *__res), __clock_getres64); extern int __REDIRECT_NTH (clock_gettime, (clockid_t __clock_id, struct timespec *__tp), __clock_gettime64) __nonnull((2)); extern int __REDIRECT_NTH (clock_settime, (clockid_t __clock_id, const struct timespec *__tp), __clock_settime64) __nonnull((2)); # else # define nanosleep __nanosleep64 # define clock_getres __clock_getres64 # define clock_gettime __clock_gettime64 # define clock_settime __clock_settime64 # endif # endif and <bits/syscall.h> this block: #ifdef __NR_clock_gettime64 # define SYS_clock_gettime64 __NR_clock_gettime64 #endif However, it looks like the Digi DEY Linux 4.9.212 kernel is too old and does not define clock_gettime64 or the corresponding system call in the Arm architecture-specific headers: % grep -r __NR_clock_gettime64 $BuildRoot/results/arm/gnu-toolchain/12.3.1/release/third_party/linux/linux-dey/include/ or in the kernel source at all, for that matter: % git grep clock_gettime64 $BuildRoot/third_party/linux/linux-dey/repo/ It looks like the 64-bit clock interfaces were introduced in linux-5.1 and glibc-2.31. Thank you again for the suggestion; very helpful! Best, Grant -- Principal Nuovations gerickson at nuovations.com http://www.nuovations.com/
Seemingly Similar Threads
Wisdom of the Ancients
