Use getrandom on Linux for Guid generation for a 12% speed boost.

[vcsjones]

Since Linux 3.17, the syscall getrandom can be used to generate bytes from the same entropy source as /dev/urandom. This makes it suitable for cryptographic random number generation, something our Guid generator needs.

If getrandom is not available because the LibC provided is too old - or if the syscall itself is not available, it will fall back to the previous method of reading from /dev/urandom.

EPERM is treated like ENOSYS - some older Linux kernels returned this when the syscall is not available. The syscall can also be blocked by seccomp. That would be weird, and Docker permits it by default, but if anyone has explicitly gone out of their way to block it, it falls back to using the file descriptor mechanism.

The use of the syscall implementation instead of the file device offers some performance improvements. Anywhere from 10% to 15% in benchmarks.

This does require glibc 2.25. For non-portable builds, that's largely fine. For Microsoft builds, those are (currently) being done on Ubuntu Xenial, which has 2.23. However, it is expected that with .NET 10, the glibc floor is going to change to 2.27 with #109939. When that happens, then the Microsoft portable builds will pick this up as well.

This PR does not change the user-facing RandomNumberGenerator that will continue to use RAND_bytes from OpenSSL.

Method	Toolchain	Mean	Error	StdDev	Ratio
NewGuid	branch	265.1 ns	0.24 ns	0.22 ns	0.87
NewGuid	main	304.6 ns	0.16 ns	0.15 ns	1.00
CreateVersion7	branch	293.2 ns	0.20 ns	0.18 ns	0.88
CreateVersion7	main	335.0 ns	0.27 ns	0.23 ns	1.00

[jkoritzinsky]

Can we extract the new code-path into a static function that returns true if getrandom was used and false if the device random should be used? I'd like to get rid of the goto if we can.

[am11]

Suggested change

	static bool sMissingGetRandomSysCall = false;
	if (!sMissingGetRandomSysCall)
	static short sGetRandomSupport = -1;
	if (sGetRandomSupport == -1)
	{
	sGetRandomSupport = syscall(SYS_getrandom, nullptr, 0, GRND_NONBLOCK) == -1 && errno == ENOSYS ? 0 : 1;
	}
	if (sGetRandomSupport == 1)

This run-time introspection will only run once; the first time.

[vcsjones]

Why is this better than using the getrandom provided by the C runtime?

[jkotas]

The direct syscall has a small advantage in that it does not introduce hard dependency on the new glibc version, and so the binaries work in practice on older baselines too.

For example, even though our current baseline is Ubuntu 16, the binaries work in practice on older baselines too since we do not actually have a hard dependency on anything from Ubuntu 16 (it has been verified for native AOT compiled binaries, I am not sure about full coreclr).

[am11]

This looks good. I missed that you already handled ENOSYS. :)

It will also improve #31271 since it also ends up calling minipal implementation.

@vcsjones, I posted a benchmark with managed impl. here, if case you want to try out #31271 (comment).

[jkotas]

This does require glibc 2.25. For non-portable builds, that's largely fine. For Microsoft builds, those are (currently) being done on Ubuntu Xenial, which has 2.23.

This means that we have close to non-existing test coverage for this change. We do nearly all our testing in this repo on portable builds.

We should either wait with merging this until we have updated the baseline, or define the syscall locally for portable builds like we have done in similar situations in the past see e.g. #111846 .

[vcsjones]

I will take a look at doing a local definition.

[dotnet-policy-service]

Draft Pull Request was automatically closed for 30 days of inactivity. Please let us know if you'd like to reopen it.