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, 18.104.22.168. 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 22.214.171.124, 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.