[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20220917204303.GM9709@brightrain.aerifal.cx>
Date: Sat, 17 Sep 2022 16:43:04 -0400
From: Rich Felker <dalias@...c.org>
To: Lance Fredrickson <lancethepants@...il.com>
Cc: musl@...ts.openwall.com
Subject: Re: getrandom fallback - wrapper functions dilema
On Fri, Sep 16, 2022 at 12:05:02PM -0600, Lance Fredrickson wrote:
> 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?
No, it's not a meson issue. You cannot build-time test properties that
are variable at runtime because you're not (necessarily) building on
the system you're running on. You may be cross compiling, or building
native binaries for the system you're on but planning to run them on a
different system.
If you want to make software that behaves gracefully across a range of
old systems, you need to do *runtime* tests for the specific optional
functionality that might or might not be present. Normally this means
just checking failure returns for ENOSYS, EINVAL, etc. and falling
back to doing something else or reporting that the needed
functionality is not available. Or, if the functionality isn't
actually needed to begin with -- like if you're gratuitously using
getrandom for monte carlo stuff or for salting a hash table hash
function to make it collision-resistant -- then *don't*, and instead
use a deterministic function.
> Should a libc be compiling in syscalls and functions the running
> kernel can't support?
Yes. There is no concept of "the running kernel" in musl. musl is not
built for any particular kernel version, only to run on top of the
Linux syscall API/ABI as the underlying layer, with syscalls present
in 2.6.0 as the baseline for providing the majority of the standard
functionality (all that's possible to implement with that), later 2.6
series for a few POSIX conformance things that early 2.6 couldn't
supply, and everything else as extension functionality that might or
might not be available at runtime.
> 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.
uclibc has a very different philosophy with a combinatoric explosion
of build configurations, no officially stable ABI, and an intent that
you build a version for your particular hardware+kernel target.
Rejecting this philosophy was one of the big differences (and, in my
opinion, the big successes) of 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.
Ripping things out is not the right solution at all.
> Or do the software authors and build systems need better
> syscall/function availability checks?
Nothing to do with build systems. The applications just need to be
checking (at runtime) error returns for functions which are not
guaranteed-not-to-fail. This includes any Linux extensions not present
in the minimum kernel version they require.
All of this should be documented better on musl's side too -- what the
actual (non-)guarantees for availability of functionality are.
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
