[RFC PATCH] advapi32: Use Windows APIs to read /dev/urandom.

[Zebediah Figura]

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-ntquerysysteminformation

> 
> 
> Thanks,
> 
> Jacek
> 
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20200904/81628ca3/attachment.sig>