From: Lance Fredrickson <lancethepants@gmail.com>
To: musl@lists.openwall.com
Subject: [musl] getrandom fallback - wrapper functions dilema
Date: Fri, 16 Sep 2022 12:05:02 -0600 [thread overview]
Message-ID: <5642f27d-79ee-a231-f027-e0904ac4d6fc@gmail.com> (raw)
I'm using musl on an arm embedded router (netgear R7000) running an old
kernel, 2.6.36.4. I compiled an application using the meson build system
which does a check for the getentropy function which it does of course
find in musl and ultimately the program aborts. I see getentropy uses
getrandom which is a wrapper around the syscall which came around kernel
version 3.17 . In the mailing list I saw in one discussion way back
about adding a fallback to getrandom, maybe after integrating arc4random
which doesn't seem to have ever happened.
I appreciate that musl strives for correctness, so what is the correct
solution for this issue?
I think meson checks for the function availability, but I'm not sure
that it checks for valid output. Is this a meson issue?
Should a libc be compiling in syscalls and functions the running kernel
can't support?
Help my lack of understanding but I think at least syscalls will return
not supported right? So maybe the bigger issue are these syscall wrappers?
I know that if down the road I try to run musl on another router, mipsel
& kernel 2.6.22.19, I'm going to run into prlimit issues because prlimit
came after this kernel version, but the prlimit function will be
unconditionally compiled in. And it seems the autoconfs and cmakes and
mesons are only really checking for the function availability and not so
much if the syscall they're wrapping is actually going to work.
getentropy is even more removed because it's a function that relies on
a syscall wrapped in another function.
So I really hope the solution isn't bumping up the minimum kernel
requirement. Sure I'm using an old kernel and maybe I should upgrade,
but in this case I can't because I'm vendor locked. This type of issue
will still arise down the road however. Say kernel 6.3 adds a new
syscall and musl adds a syscall wrapper, well then your shiny 6.1 kernel
running musl 1.2.4 (or whatever future version) might claim it has
functionality it really doesn't, and that could trip something up.
I know uclibc-ng tracks syscalls/functions to kernel availability in
kernel-features.h that they carry, but I don't know what is correct for
musl. Unconditionally included every feature regardless of kernel
support doesn't feel correct, and in practice causes issue like this. My
only other option is to start ripping functionality out of musl to match
the functionality of that particular kernel, and I know that really
doesn't feel correct either.
Or do the software authors and build systems need better
syscall/function availability checks?
respectfully,
Lance Fredrickson
next reply other threads:[~2022-09-16 18:05 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-16 18:05 Lance Fredrickson [this message]
2022-09-17 5:58 ` Markus Wichmann
2022-09-17 20:43 ` Rich Felker
2022-09-19 20:56 ` Lance Fredrickson
2022-09-19 21:41 ` Rich Felker
2022-10-18 17:20 ` Lance Fredrickson
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=5642f27d-79ee-a231-f027-e0904ac4d6fc@gmail.com \
--to=lancethepants@gmail.com \
--cc=musl@lists.openwall.com \
/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.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/musl/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).