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

For platforms that implement runtime fallback logic, all paths should be tested #289

Open
briansmith opened this issue Oct 9, 2022 · 1 comment
Labels

Comments

@briansmith
Copy link
Contributor

Consider the case of Linux. We hope to use the getrandom syscall and then if that fails, we fall back to doing file I/O. We should test at least the following scenerios:

  • Linux returns ENOSYS, which should trigger the fallback to file I/O.
  • Linux returns EPERM, which is presently expected to do the same fallback, though there's an issue on file to change this.
  • The syscall succeeds.

This type of exhaustive testing might not be practical on all targets. However, BoringSSL has shown how to do it on Linux; see https://boringssl.googlesource.com/boringssl/+/refs/heads/master/crypto/fipsmodule/rand/urandom_test.cc.

@josephlr
Copy link
Member

I agree that this testing will be challenging for Platforms that aren't Tier 1, but I think we should look into it for Linux and MacOS. Maybe using LD_PRELOAD shenanigans with an older libc could work?

For the syscall vs file fallback, it would be interesting if we could get a ptrace-based test to work.

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

No branches or pull requests

2 participants