From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FROM,MAILING_LIST_MULTI,RCVD_IN_MSPIKE_H2, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 3890 invoked from network); 17 Sep 2022 05:58:24 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 17 Sep 2022 05:58:24 -0000 Received: (qmail 14116 invoked by uid 550); 17 Sep 2022 05:58:21 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 14080 invoked from network); 17 Sep 2022 05:58:20 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1663394288; bh=C8rq6Y/8MPU8pCr6SBZYxbLK3nYmSestD5mCS+d5zdA=; h=X-UI-Sender-Class:Date:From:To:Subject:References:In-Reply-To; b=DmG5h0RRoJM9kUbDKVxli6BrGFxOn9RZwZT5zEOIDDBLyJRVGdtckpK6ec4FxKVnI f6yFDVg8XcqkBl04jziM8Bn3PmeHve8IIr0YY7o9HSQbAGrLSCkkx59+5kShRD3X1M y2JZ5xk8mB3uz5jS+uholqnqEMMxiAU4wMUW7Rwo= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Date: Sat, 17 Sep 2022 07:58:07 +0200 From: Markus Wichmann To: musl@lists.openwall.com Message-ID: <20220917055807.GA2645@voyager> References: <5642f27d-79ee-a231-f027-e0904ac4d6fc@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: <5642f27d-79ee-a231-f027-e0904ac4d6fc@gmail.com> User-Agent: Mutt/1.9.4 (2018-02-28) X-Provags-ID: V03:K1:njp91i73fjhAI7YGgitEHyVmInowsNnTbD7sekenfrmNed1mMu5 +BMpINm0QC3XwHd9hCpnffSrrn0v7WH4E4OGzzgK1p4dzmw8BoSgxxEORod3KoWtG9d7grj dENSpKrBcrHKMbMTZ4PuDEVZDI143m5XqL5VPI40nw17Lh6izBH++RES+l9s0zO1Llub8Yy Um03ve0faL7EV9KuSXY6w== X-UI-Out-Filterresults: notjunk:1;V03:K0:d/cFq/jjT+U=:ZcPwXDbXW6issumdu4iNZt DHB8wjpqYIbVqamv+IcdF9qKEUbBLlOcY1yDFG54P501P1FSUhPMjK5xIop8X4UHkYyLBuEiY 7awV8KJbLigo8PJgtLBxye1ljs2t0qWrXGyRA2ag8xdoZ5kXLpS8WK8DYn6adCaROmZsk7wNC YaOG5w4Mzg3ks2DBfct71Cz4ee4FYrH/cr5I4KWtiI9VoxL8opXWIhs6y7wL5i4RyCBvlVGe+ EvRTkeNmyNRGPuALxQVx3C29ezhY3zBteeJUdLMpEBf8zqQfaHNzyTRRf5KKQv9d5V+VE7i1p orhZvL+O90HNSsF/tA+DJWU0A3xYGwIbevJFjFwUj6d6qZ3MbWkzxf3ZvdNFV8a6SGnKc6put wOSBmr+08JLXvva4n4GpwKWkKSCFRM75MZp6uRJN0K3HfxWDmMY0AlHTlSVnM1ZpOo1pod74z i3IKO4k6Yp+XDe8aKK3mCApBelgQBDma0xsJeoHsMNzskrQQTRvcX0CrqD1V508Q/f1pMRhGV MM8lmbbg8zhqw8pUSolz2gkh0MYoVn4WPDvvjuc10JpJd+nhxejpdzVI2V7S28zUiLBsyhNY8 z837oQMkHtboNSs5r3Ee4ZXVIuc+cBGc7CoF6I13qru/kUJwRV4nNzh5abxiNuWG2RWdh8R5B IwRtdqdWCwD6Uk6lIYzdhafh+PjpFUsRad4cKbQ6x1sgmwqarfo1oYdx7m03Po3KLMjUd3pac dDcyWB1rwpLbOpdDn6Ic6E3yCNLssLpz0aIOUkeKMqM9sL0J1XebrTXipwZiX1BZCSwT888dc p8xz7RJzBGuwHFg61/XunXQqwsWGRtJvggJao/PkomaiHXZ8jL9f1zPjoVXOaE1LurXUc8dNX zOMFtUHdQ00uEeJj+xdOhQNuPzYIkcv1wSBA17qlRAjst4BnIl2u8FwDTDzdzEUnFxGZ8CVr/ cqeaqnxQP0d+2y+ZrwUlrm2q8GtBSa8JfCPgpUkWII2dsevOzB1sJr96wLTf4+2drTjj5pJdG CN/dlm4N+5AJGAd4bE7WfyUQutsKtbUB2dKUCf0DlI9680y/VJhpZ9XKTGs9w0G8zmDC9GU7E c4QMQ6GarsmQ9O29JxOLbxSEwG33ooW5ruBqbDi416Ekx01rLmCxATVIjjQ64TfsMwRT2Lr4b fWvV5iAyif4b0M05fVBunW2DkD Subject: Re: [musl] getrandom fallback - wrapper functions dilema 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 f= ind > in musl and ultimately the program aborts. I see getentropy uses getrand= om > 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 tha= t it > checks for valid output. Is this a meson issue? > I think the application that aborts if getentropy() fails is in the wrong here. Well, possibly. It is possible that application sees kernel 3.17 as minimum necessity. In that case, they are doing fine (although then I would question why they detect the function during configuration). If not, then aborting if a system call fails seems like the wrong thing to do. The application should instead attempt to fall back to a different method, e.g. opening /dev/urandom, trying getauxval(AT_RANDOM) and seeding an RNG with it, or anything of the sort. The fundamental disconnect here is that just because a function is available doesn't mean it will succeed at run-time. And no, the build system isn't doing anything wrong. The most it can do is compile a test binary and if that worked, it has to be good enough. In case of cross-compilation, it cannot run the binary. And anyway, the build system is not necessarily the run-time system. > Should a libc be compiling in syscalls and functions the running kernel > can't support? Yes. libc and kernel are always linked together dynamically through the syscall interface. In general, libc cannot know what syscalls the kernel will support. So musl uses the newest syscall interface and falls back to older ones as necessary. In case of getentropy(), however, no fallback was ever implemented. > 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? Yes, unsupported system calls will return failure with ENOSYS. And I just checked getentropy(), and it too will report getrandom() failure. SO the application should see failure with errno set to ENOSYS and act accordingly. And that doesn't mean abort. > 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 c= ame > after this kernel version, but the prlimit function will be unconditiona= lly > 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 sys= call > they're wrapping is actually going to work. > getentropy is even more removed because it's a=A0 function that relies o= n a > syscall wrapped in another function. > It is possible that lots of open source code out there is badly made. In this case, they assume that libc defining a certain function means the run-time kernel will also support the underlying system call, and absolutely nothing can fail. But it is also illogical to have a configure option for a function and then abort if it fails. I thought the function was optional? Your options are: 1) Bump up the kernel version. Apparently not an option for you. 2) Patch the application to deal with failures appropriately. 3) Patch musl to fall back on failure. Whether to pursue 2 or 3 depends highly on the applications involved and whether a change to the libc or the application is more appropriate. For instance, instead of getentropy(), you can open /dev/urandom. Now, the application might be the better place to contain that change, since it can more easily manage the file descriptor life cycle. Changing it in libc would mean you open the file on each call to getrandom() and close it again at the end. Or else you use a static variable for the FD and then the application gets messed with in other ways. > Or do the software authors and build systems need better syscall/functio= n > availability checks? > They need better run-time logic to deal with failures. Function availability does not mean the function will succeed. Ciao, Markus