[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Tue, 18 Oct 2022 11:20:27 -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/19/2022 3:41 PM, Rich Felker wrote:
> On Mon, Sep 19, 2022 at 02:56:32PM -0600, Lance Fredrickson wrote:
>>
>> 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.
> Yes, absolutely. It's on the wishlist and I have a draft of the core
> backend using sysctl, but it still needs some work hooking it up.
> Hopefully this will meet your needs. The (long deprecated, later
> removed) SYS__sysctl syscall is really the only way to get reliable
> randomness on these old kernels that's not dependent on being able to
> open device nodes (requires available fd slots and system open file
> slots, mitigations for entropy-pool-not-ready condition, etc.)
>
> Rich
Awesome, looking forward to it, thanks!
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.
