Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Fri, 16 Sep 2022 12:05:02 -0600
From: Lance Fredrickson <lancethepants@...il.com>
To: musl@...ts.openwall.com
Subject: getrandom fallback - wrapper functions dilema

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

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.