[PATCH 0/1] MR2025: advapi32: Bump random buffer size.

[Hans Leidekker (＠hans)]

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=54364

[PATCH 1/1] advapi32: Bump random buffer size.

[Hans Leidekker]

From: Hans Leidekker

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=54364
---
 dlls/advapi32/crypt.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/dlls/advapi32/crypt.c b/dlls/advapi32/crypt.c
index 66ad7db3ab2..73c9b1d219d 100644
--- a/dlls/advapi32/crypt.c
+++ b/dlls/advapi32/crypt.c
@@ -2390,7 +2390,7 @@ static CRITICAL_SECTION_DEBUG random_debug =
 };
 static CRITICAL_SECTION random_cs = { &random_debug, -1, 0, 0, 0, 0 };

-#define MAX_CPUS 128
+#define MAX_CPUS 256
 static char random_buf[sizeof(SYSTEM_INTERRUPT_INFORMATION) * MAX_CPUS];
 static ULONG random_len;
 static ULONG random_pos;

[Nikolay Sivov (＠nsivov)]

I would be great to figure out how this is supposed to work of course, maybe it's using bcrypt, and bcrypt is using some other interface.

But maybe we could simply add a custom information class, and use fixed size buffer, regardless of cpu count.

[Nikolay Sivov (＠nsivov)]

Actually, with a custom class we could as well fill this buffer at unix side entirely.

[Hans Leidekker (＠hans)]

Yes, googling suggested that this goes through bcrypt on Windows. We don't have an RNG implementation in bcrypt though (we do it the other way around; bcrypt calls RtlGenRandom()). I guess we could add a Unix call in bcrypt that calls getrandom() in the GnuTLS backend and implement BCryptGenRandom on top of that. The downside is that this depends on having GnuTLS available, although missing it breaks Wine in many other ways as well.

Anyway, I thought that until we figure this out it should be fine to bump the buffer size.