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=-4.6 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FROM,MAILING_LIST_MULTI,NICE_REPLY_A, RCVD_IN_MSPIKE_H2 autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 17253 invoked from network); 19 Sep 2022 20:56:49 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 19 Sep 2022 20:56:49 -0000 Received: (qmail 23628 invoked by uid 550); 19 Sep 2022 20:56:46 -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 23593 invoked from network); 19 Sep 2022 20:56:46 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date; bh=eaqNlai3wa2bKjCmz1l8VWB4Y4JgnT04kYSSE6K0IUI=; b=FNmP3p8tlqQapNryA2aLgv9T7HBKcrXiqoEtD84xZoYEQkDeCXdSoCYNN0DAs/zoXN LVwWLq8xrIVjL+jo0IDLQWcqKpzqh6PLkUrPlSxjxO9WFe0CROf/7e8ONToorjehSZcx mPSZ/8/VDCY5ZAyJL0RLWX612SnmYsRRStc+vK11Vyby3EwEPH6OLK3KuIjW377eaHC3 QmdeWX7FfkqSMwJuEt3zSM9/BCusCp06Wqca8aS8ScDs6y/FQdVx6ZACgYEhZTFrdYc8 X78+2tItOiB2OIXG/PDpzROb9OMi8SKpz6UDJgoS7F7KxwDSRdZNtvGrl1BHtLPlFKjF Bbag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date; bh=eaqNlai3wa2bKjCmz1l8VWB4Y4JgnT04kYSSE6K0IUI=; b=aBFFPJNkpV4KegTX8H9Qw3YGsV7PaS64YMHftNPatT+1htseYAHJorMOw0ivnqztmH Q0YYOuNIIakeu3sh5OKsE4CXSYZBixsaOXgcxrEQ3NKxsCUWr50bciLgyNeSybedNrmC G0M98M3+7wdb4WOPECkZICCk68Pi7MNCMm/jWcBDtvgAyzgOfZIrlN7iOliGmwqu6x4T X4g5q0boeRlYHY1wJmav//dzOJxbUZFYd4MYJV+niipSz+OJoLoEkVEtpxkGfj2ILtlT TGc7uyLnWCdBWJ8vq7clOH3cyIcpYQjicjfJfG6gn+4M9YFpzaP8Epxi5VkXZaVKbgfU nLDA== X-Gm-Message-State: ACrzQf1hNZC4BvaZHaCMPCpBXOn8Og5kStwBYC1EWgxyTnFO0MMwVVmD QidKTM+zuW/H82KM5wLmkSE= X-Google-Smtp-Source: AMsMyM54gedwrHxi0hcXxgAuuoa8d+rt0N6V3iP95uBVk7jKbOnmwo0kAHIbQG1EoL0xiFTFBZvUGg== X-Received: by 2002:a05:6870:5628:b0:126:3b21:cbee with SMTP id m40-20020a056870562800b001263b21cbeemr37203oao.25.1663620993686; Mon, 19 Sep 2022 13:56:33 -0700 (PDT) Message-ID: <73d9ba57-bcef-370b-1384-0cbc1a313cb4@gmail.com> Date: Mon, 19 Sep 2022 14:56:32 -0600 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.2.2 Content-Language: en-US To: Rich Felker Cc: musl@lists.openwall.com References: <5642f27d-79ee-a231-f027-e0904ac4d6fc@gmail.com> <20220917204303.GM9709@brightrain.aerifal.cx> From: Lance Fredrickson In-Reply-To: <20220917204303.GM9709@brightrain.aerifal.cx> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [musl] 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, 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. Lance