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

Add random number capability for OSAL and UT assert #1316

Open
jphickey opened this issue Oct 21, 2022 · 0 comments
Open

Add random number capability for OSAL and UT assert #1316

jphickey opened this issue Oct 21, 2022 · 0 comments

Comments

@jphickey
Copy link
Contributor

Is your feature request related to a problem? Please describe.
There are some circumstances where software (validly) needs high-quality random numbers, such as for cryptographic algorithms. The ISO C standard API is not sufficient, as functions like rand() are only psuedo-random and thus are not useful for algorithms where true randomness is necessary.

Furthermore, to support the notion of "fuzz testing" the UT assert framework should also have a facility to easily get random numbers.

Describe the solution you'd like
Many OS's have a facility to interface with a true hardware random number generator or get much higher-quality random numbers through software by gathering entropy from a local platform-specific source (like keystrokes or mouse movements, or electrical noise from an ADC, etc).

Describe alternatives you've considered
Initially, this can be as simple as calling srand() once during startup with an unpredictable value, or the system clock tick counter if no real random source is available. This way, if the application does call rand(), the numbers at least will not be the same every time.

That would be good enough for low impact tasks like fuzz testing and things of that nature, but wouldn't be sufficient for crypto.

Additional context
To clarify - fuzz testing described here is a functional test concept, independent of coverage testing. For coverage testing using UT assert, it is important that the test case follows predictable branches, and thus random numbers should not be used there. Fuzz testing, if implemented, would be done as a completely separate test.

Requester Info
Joseph Hickey, Vantage Systems, Inc.

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

No branches or pull requests

1 participant