[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 19 Sep 2022 14:56:32 -0600
From: Lance Fredrickson <lancethepants@...il.com>
To: Rich Felker <dalias@...c.org>
Cc: musl@...ts.openwall.com
Subject: Re: getrandom fallback - wrapper functions dilema
On 9/17/2022 2:43 PM, Rich Felker wrote:
> 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
Thanks for the response! Would having a getrandom fallback still be on
the table for musl? It's not the first time I've hit this issue so
having the libc automatically take care of things would be a
nice-to-have, especially as I've seen getrandom become more prevalent in
coding projects.
Lance
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.
