On 9/4/20 3:01 PM, Jacek Caban wrote:
Hi Hans,
On 04/09/2020 13:15, Hans Leidekker wrote:
This will cause a performance regression. SystemFunction036 (RtlGenRandom) is already an order of magnitude slower than native because it opens and closes /dev/urandom on every call. Going through wineserver makes it 2 orders of magnitude slower:
int buf[4], i; for (i = 0; i < 100000; i++) RtlGenRandom(buf, sizeof(buf));
Windows: 16 ticks Wine/open(): 209 ticks Wine/NtCreateFile(): 3612 ticks Wine/NtCreateFile()/cached: 96 ticks
We could cache the file handle to mitigate that, but then there's the risk that an application accidentally closes the handle.
The difference would be probably even larger with NtClose() calls. Caching the handle seems good to me. With that, it's essentially a wrapped read syscall. To go beyond that, you could try to read larger chunks and cache the data.
Is there /dev/urandom equivalent on Windows? I'm wondering if a create_unix_device-based solution similar to /dev/null handling would be suitable to expose /dev/urandom as a Windows file.
I suspect that the answer is no, and that Windows achieves cryptographic randomness mostly in user space. See the documentation for NtQuerySystemInformation [1], which lists several statistics that can be used "to generate an unpredictable seed for a random number generator". Note also that applications depend on these being at least a little random; see bug 39123 [and the linked Staging patch].
[1] https://docs.microsoft.com/en-us/windows/win32/api/winternl/nf-winternl-ntqu...
Thanks,
Jacek