[PATCH v10] linux: Add support for getrandom vDSO

[Jason A. Donenfeld]

On Mon, Dec 30, 2024 at 05:22:41PM +0100, Jason A. Donenfeld wrote:
> On Mon, Dec 30, 2024 at 02:15:25PM +0100, Florian Weimer wrote:
> > * Adhemerval Zanella:
> > 
> > > +/* Allocate an opaque state for vgetrandom.  If the grnd_alloc does not have
> > > +   any, mmap() another page of them using the vgetrandom parameters.  */
> > > +static void *
> > > +vgetrandom_get_state (void)
> > > +{
> > > +  void *state = NULL;
> > > +
> > > +  /* The signal blocking avoid the potential issue where _Fork() (which is
> > > +     async-signal-safe) is called with the lock taken.  The function is
> > > +     called only once during thread lifetime, so the overhead should be
> > > +     minimal.  */
> > > +  internal_sigset_t set;
> > > +  internal_signal_block_all (&set);
> > > +  __libc_lock_lock (grnd_alloc.lock);
> > 
> > This caused a regression in dhcpcd because it did not have
> > __NR_rt_sigprocmask in its seccomp allowlist:
> > 
> >   dhcpcd crashes with SIGSYS with latest Ferdora 41
> >   <https://github.com/NetworkConfiguration/dhcpcd/issues/421>
> > 
> > I investigated if we can avoid the new system call if no signals have
> > been installed, but I don't think it would help dhcpcd because it has
> > signal handlers, so it doesn't look like its worth the effort.
> 
> This seems very much like a non-issue... This happens frequently as
> software evolves, and it's always just a matter of updating the seccomp
> whitelist. __NR_rt_sigprocmask is a pretty ordinary one to be added
> there too. Not a big deal.

Plus, it looks like this was fixed 3 weeks ago:
https://github.com/NetworkConfiguration/dhcpcd/commit/e9e40400003db2e4f12dba85acabbaf2212a520f