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