[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20260411015428.GV1827@brightrain.aerifal.cx>
Date: Fri, 10 Apr 2026 21:54:28 -0400
From: Rich Felker <dalias@...c.org>
To: Gilles Peskine <gilles.peskine@....com>
Cc: musl@...ts.openwall.com
Subject: Re: Detecting getrandom() or syscall()
On Fri, Apr 10, 2026 at 06:06:44PM +0200, Gilles Peskine wrote:
> Hello,
>
> I'm a maintainer of a cryptography library (TF-PSA-Crypto, recently split
> out
> of Mbed TLS), which is used on a wide variety of embedded systems.
>
> Our library is mostly portable C, but we do try to detect the presence of
> some
> critical system features. One such feature is a source of random data. When
> running on a Linux kernel, we prefer the getrandom() system call, and fall
> back
> to /dev/random or /dev/urandom.
>
> Experimentally, at least with a modern musl version, we can call the
> getrandom() system call with
>
> #include <unistd.h>
> #include <sys/syscall.h>
> syscall(SYS_getrandom, ...) // or __NR_getrandom perhaps on some libc?
>
> However, not all systems have <unistd.h>, <sys/syscall.h> and syscall(). So
> we need to wrap this code in preprocessor directives. We know that
> Linux-Glibc
> and Midipix have these headers, so our code currently looks for getrandom()
> on
> these systems.
> https://github.com/Mbed-TLS/TF-PSA-Crypto/blob/tf-psa-crypto-1.1.0/platform/platform_util.c#L297
>
> #if ((defined(__linux__) && defined(__GLIBC__)) || defined(__midipix__))
> #include <unistd.h>
> #include <sys/syscall.h>
> #if defined(SYS_getrandom)
> ...
> syscall(SYS_getrandom, ...)
>
> It would be nice to also use getrandom() on Linux-musl. But how can we
> detect
> musl? We can't just use #if defined(__linux__) since not all Linux build
> environments have <sys/syscall.h> and a syscall() function.
>
> The musl FAQ explains that there's no feature detection macro for musl
> because "it's a bug to assume a certain implementation has particular
> properties rather than testing". But looking at the musl headers, I can't
> find anything that I could test to guarantee the presence of <sys/syscall.h>
> and syscall().
The historical and current way this is recommended to be done is with
compile and link tests at build time. This can be done with autoconf,
or on your own with a build rule (e.g. in a makefile) that executes
the compile or link attempt command and generates a header fragment
from the exit status. I imagine cmake and other build systems some
folks prefer nowadays have similar facilities.
There is a proposal I put forth on the libc-coord mailing list in
2020, titled "Macro-based advertisement of libc extensions", for
implementors to agree on a naming convention for macros that would
declare the presence of nonstandardized but common interfaces and
features, so that you could use preprocessor conditionals on these
directly without having to run your own tests, and so you could know
the availability of untestable things (things where any test would
produce undefined behavior).
In any case, though, the 1980s-era giant trees of hard-coded ifdefs
for every particular system you know about is NOT the right way to do
this. Please, for everybody's sake, just use autoconf or something
comparable that actually probes rather than hard-coding assumptions.
Rich
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.
