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=-0.8 required=5.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,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 3202 invoked from network); 16 Sep 2022 18:05:19 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 16 Sep 2022 18:05:19 -0000 Received: (qmail 7181 invoked by uid 550); 16 Sep 2022 18:05:15 -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 6125 invoked from network); 16 Sep 2022 18:05:14 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:subject:from:content-language:to :user-agent:mime-version:date:message-id:from:to:cc:subject:date; bh=o2TIFl08/M8BaT81h/ju2z1v9+apdKnZi++lzgoD9Ks=; b=I7G0MIkihumBuOB6F8ChLZYZ11Asa86GcHF17VRgXQ0OTVIbYfNg5zA4gMQ7cX9bvB tZgwFwp0Lm0Q3OlfuefsQ2sQJbMJZYEQ5Wj25HwDpLUxW5D0aQIF4b7WUVkWu94Nz6uV /vZPhCGDccHN8axLhNf5z8J0qcluAUMt5PAPq7MzTjIMYXJ1KvJ6n8oexjLwdgCTYqap x8PKxLiGGJDPWwOW2FoZd+WM+Lsj22sYBpAoV75HdK0f/fasNH5gZl/SZaTgO5e2cnSJ vD2TFbUM2SjmOVSPjGLN2AmpmKzhFs3YosfSfHRHKYegTEYGPs2GUawbJn7reQaOhFUW Df5w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:subject:from:content-language:to :user-agent:mime-version:date:message-id:x-gm-message-state:from:to :cc:subject:date; bh=o2TIFl08/M8BaT81h/ju2z1v9+apdKnZi++lzgoD9Ks=; b=tklokw/71j/uBU+0vNEhAwPl5bnhDbnT2eHrJ8IqKyePNLCgWT5NROI5/slAzMqtpN 4s2o+PxSPghr8MXxpdEjSzD2M1eGepOf6NW83AIXH8ustHFnjM0lld7K0dPrAC3oAe/1 uRKfTfmACOpn3XDWQtJlHDMVlFgQGFJkAVXFzc2kWtOXcbDx9WH0s6ocI/+8DCSz1u69 qPN59g1ZQBK5hPU/j1275nKNzg3oAvWSHO9HhZWJ5RaSqTnKPrSWtZd/RiDBorJjgtiP JxGZr7pxZ9Gsmy5gD0QgB0ZH5Wxm9odnwCSCdTiPLR+RGA+APKZxGXPq4qUb3QpEfLXM +ufw== X-Gm-Message-State: ACgBeo0aT842yemW3rC1W7VZ+VA0Jq3Grnyi/dJFX+IHVwlVIaGnj99X 9+vn2QKNQo0Iq+uIkZVxWqMapbaC8b31UQ== X-Google-Smtp-Source: AA6agR4QcZTIyBQDh6kcOx4Ec9SeeiN8KaotjJeZ1O6yzVlKX+0OpSpzQBhCAEWH1B+Z92DkwCbmbw== X-Received: by 2002:a05:6870:fb87:b0:126:2e4f:cf4d with SMTP id kv7-20020a056870fb8700b001262e4fcf4dmr9791697oab.240.1663351502647; Fri, 16 Sep 2022 11:05:02 -0700 (PDT) Message-ID: <5642f27d-79ee-a231-f027-e0904ac4d6fc@gmail.com> Date: Fri, 16 Sep 2022 12:05:02 -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 To: musl@lists.openwall.com Content-Language: en-US From: Lance Fredrickson Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: [musl] 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