Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

unpredictableSeed doesn't work with ASAN #10613

Open
ljmf00-wekaio opened this issue Jan 7, 2025 · 4 comments
Open

unpredictableSeed doesn't work with ASAN #10613

ljmf00-wekaio opened this issue Jan 7, 2025 · 4 comments

Comments

@ljmf00-wekaio
Copy link
Contributor

import std.random;

void main()
{
    auto n = unpredictableSeed!ulong;
}

Fails when compiling with ldc2 -fsanitize=address %s.

Even though -fsanitize=address is specific to LDC, this is mainly a problem with the current Phobos implementation, assuming that the compiler wont poison the assembly block. In the current form, the assembly block should be marked as naked and optimally, be on a separate function to completely avoid conflicting registers.

Also, compare and jump instructions shouldn't really be in an inline assembly block, but rather, on readable D code.

@ljmf00-wekaio
Copy link
Contributor Author

CC @JohanEngelen

@0xEAB
Copy link
Member

0xEAB commented Jan 9, 2025

I’d go as far as to say that this function should probably just call the system’s CSPRNG – instead of executing RDRAND by itself (assuming that’s available on the respective platform).

@ljmf00-wekaio
Copy link
Contributor Author

ljmf00-wekaio commented Jan 9, 2025

I’d go as far as to say that this function should probably just call the system’s CSPRNG – instead of executing RDRAND by itself (assuming that’s available on the respective platform).

Arguably, but I wouldn't, unless its vDSO-based (if that is even possible to implement securely and fast enough), but mostly for performance reasons, although I can totally see a point security-wise, but if that's the argument, don't use unpredictableSeed at all. Accessing the random device with enough entropy is not strictly required here, and I think this function has a balanced trade-off of not calling a syscall, being reasonably random and being fast.

On a side note, specifically to LLVM, this should be probably an intrinsic.

@JohanEngelen
Copy link
Contributor

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants