On 22/9/2022 0:01, Martin Storsjö wrote:
> +static void __cdecl __attribute__((__constructor__)) init(void)
> +{
> +  HCRYPTPROV crypt = 0;
> +  if (__stack_chk_guard != 0)
> +    return;
> +
> +  if (CryptAcquireContext(&crypt, NULL, NULL, PROV_RSA_FULL, 
> CRYPT_VERIFYCONTEXT | CRYPT_SILENT)) {
> +    if (CryptGenRandom(crypt, sizeof(__stack_chk_guard), (BYTE*) 
> &__stack_chk_guard) && __stack_chk_guard != 0) {
> +      CryptReleaseContext(crypt, 0);
> +      return;
> +    }
> +    CryptReleaseContext(crypt, 0);
> +  }

I guess this is just following whatever libssp does, but I did just stumble 
across some talks about RNG functions elsewhere, mainly an old comment on 
Mozilla's bugzilla <https://bugzilla.mozilla.org/show_bug.cgi?id=504270#c5> 
recommending `RtlGenRandom` over `CryptGenRandom` and a discussion in 
rust-random <https://github.com/rust-random/getrandom/issues/65> advocating for 
`BCryptGenRandom` over `RtlGenRandom` and its references. Firefox, Chrome, Rust 
and Go all prefer to use `RtlGenRandom` instead of `CryptGenRandom`. The 
documentation of CryptGenRandom 
<https://learn.microsoft.com/en-us/windows/win32/api/wincrypt/nf-wincrypt-cryptgenrandom>
 says the API is deprecated and may be removed in the future (though I doubt 
they will really remove it) which may be a good reason to avoid using 
`CryptGenRandom`.

Now whether to use `RtlGenRandom` or `BCryptGenRandom` as the replacement: For 
UWP, `BCryptGenRandom` is the only choice. For desktop, a comment in a 
BoringSSL issue <https://bugs.chromium.org/p/boringssl/issues/detail?id=307#c9> 
claims that they both use "the same internal RNG infrastructure".

It seems we'd be better off replacing this use of `CryptGenRandom` with 
`RtlGenRandom` for desktop and `BCryptGenRandom` for UWP. Do you think this 
make sense?

> +  /* Didn't manage to initialize to a strong random value; set any
> +   * nonzero pointer instead. */
> +  __stack_chk_guard = (void*)0xdeadbeef;
> +}

This should probably set a 64-bit value on 64-bit architectures.

Best Regards,
Alvin



_______________________________________________
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Reply via email to