[Bug libc/29437] New: arc4random is too slow

["mlichvar at redhat dot com" <sourceware-bugzilla@sourceware.org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=29437

            Bug ID: 29437
           Summary: arc4random is too slow
           Product: glibc
           Version: 2.36
            Status: NEW
          Severity: normal
          Priority: P2
         Component: libc
          Assignee: unassigned at sourceware dot org
          Reporter: mlichvar at redhat dot com
                CC: drepper.fsp at gmail dot com
  Target Milestone: ---

The new arc4random using getrandom() seems to have a significant impact on
performance of chronyd operating as an NTP server. On an Intel E3-1220 CPU, I
see that the maximum number of requests per second dropped by about 25%. That
would be an issue for some public NTP servers.

chronyd needs a random generator for the low-order bits below the clock
precision in the receive and transmit timestamps to make them less predictable
and make off-path attacks more difficult. The generator doesn't necessarily
have to be cryptographically secure.

The assumption in the code is that arc4random is fast and buffered, as it is on
FreeBSD for instance. It is preferred over getrandom(), for which chrony has to
implement its own buffering. With arc4random using getrandom() and no buffering
the number of syscalls needed per NTP request is now almost doubled.

This can be fixed easily in the chrony source code, but I thought it might be a
good example of a real-world application impacted by this change and there
could be others.

If the plan is to fix this by adding getrandom() to the Linux vDSO, would it
make sense to wait for it to be available before releasing the new arc4random?

-- 
You are receiving this mail because:
You are on the CC list for the bug.