From: bugzilla@busybox.net
To: buildroot@uclibc.org
Subject: [Buildroot] [Bug 14796] 64 bit time and seccomp conflict (OpenSSH server crash)
Date: Sun, 18 Sep 2022 13:06:01 +0000 [thread overview]
Message-ID: <bug-14796-163-SDgXeXYLLg@https.bugs.busybox.net/> (raw)
In-Reply-To: <bug-14796-163@https.bugs.busybox.net/>
https://bugs.busybox.net/show_bug.cgi?id=14796
--- Comment #1 from Thomas Petazzoni <thomas.petazzoni@bootlin.com> ---
Peter Korsgaard and I finally had a look at this today, and we think we finally
understand what is going on.
glibc does not care about the kernel headers when deciding whether to use the
clock_gettime64() syscall or not: it always use it, and if that fails at
runtime, it falls back to clock_gettime(). This is how glibc ends up using
clock_gettime64() even if your kernel does not support it.
On the other hand, the OpenSSL seccomp code relies on kernel headers to decide
whether the clock_gettime64() syscall should be in the allowed list of syscalls
or not.
So when you are in a situation where glibc is recent, but your kernel is older,
you get into precisely the problem you have: glibc tries to use
clock_gettime64, but OpenSSH seccomp configuration prevents that, which does
not allow glibc to gracefully fallback to clock_gettime.
The only solution that we see is to disable seccomp support in OpenSSH. Peter
will send a patch for this. I will keep this bug open until this patch is
posted and hopefully merged.
--
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot
next prev parent reply other threads:[~2022-09-18 13:06 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-10 6:54 [Buildroot] [Bug 14796] New: 64 bit time and seccomp conflict (OpenSSH server crash) bugzilla
2022-09-18 13:06 ` bugzilla [this message]
2022-09-18 15:06 ` [Buildroot] [Bug 14796] " bugzilla
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=bug-14796-163-SDgXeXYLLg@https.bugs.busybox.net/ \
--to=bugzilla@busybox.net \
--cc=buildroot@uclibc.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.