9.3p1 Daemon Rejects Client Connections on armv7l-dey-linux-gnueabihf w/ GCC 10/11/12

Grant Erickson gerickson at nuovations.com
Sat Nov 4 02:28:00 AEDT 2023

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.


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),
    extern int __REDIRECT_NTH (clock_getres, (clockid_t __clock_id,
                                              struct timespec *__res),
    extern int __REDIRECT_NTH (clock_gettime, (clockid_t __clock_id, struct
                                               timespec *__tp), __clock_gettime64)
    extern int __REDIRECT_NTH (clock_settime, (clockid_t __clock_id, const struct
                                               timespec *__tp), __clock_settime64)
    #  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

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!



gerickson at nuovations.com

More information about the openssh-unix-dev mailing list