[PATCH 0/1] MR2025: advapi32: Bump random buffer size.
From: Hans Leidekker <hans(a)codeweavers.com> 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; -- GitLab https://gitlab.winehq.org/wine/wine/-/merge_requests/2025
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. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2025#note_21784
Actually, with a custom class we could as well fill this buffer at unix side entirely. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2025#note_21789
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. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2025#note_21792
participants (3)
-
Hans Leidekker -
Hans Leidekker (＠hans)
-
Nikolay Sivov (＠nsivov)