-
Notifications
You must be signed in to change notification settings - Fork 184
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 VxWorks support #86
Conversation
Thanks for working this, I am actually looking for the way to port rand for vxWorks with latest version, the layout of version 0.7.0 is quiet different than 0.6.1 which we have ported for. I don't see any problem with the code, it is good to me. Can you teach me how to test it for vxWorks? I am seeing rand 0.6.1(and 0.6.5) is used when runing rust libstd unit test, but I can't figure out where/how rand 0.7.0 is used. Thanks, |
If I understood you correctly, then you don't have to do anything. Assuming this PR is correct, after publishing the next version of
|
|
|
How about adding |
I will do it as part of libc#1469. |
I just built the latest rust code , although there are both rand 0.7 and rand 0.6.1 listed in Cargo.lock, but the rand used is still 0.6.1 when building libstd unit test: $ ./x.py test -i --stage 1 src/libstd |
Some update for vxWorks This is to address issues: #1469 and rust-random/getrandom#86 (comment) What have been changed in this PR: 1. adding randBytes(), randABytes(), randUBytes(), randSecure() and taskDelay() 2. change armv7-wrs-vxworks to armv7-wrs-vxworks-eabihf 3. code cleanup
Some update for vxWorks This is to address issues: #1469 and rust-random/getrandom#86 (comment) What have been changed in this PR: 1. adding randBytes(), randABytes(), randUBytes(), randSecure() and taskDelay() 2. change armv7-wrs-vxworks to armv7-wrs-vxworks-eabihf 3. code cleanup
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The basic gist of this looks good, just a few things to prevent some build issues.
I'm not sure if you need to rebase onto latest master (I guess it couldn't hurt).
static RNG_INIT: AtomicBool = AtomicBool::new(false); | ||
|
||
pub fn getrandom_inner(dest: &mut [u8]) -> Result<(), Error> { | ||
while !RNG_INIT.load(Relaxed) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should use LazyBool
here, something like:
fn rng_init() -> bool {
loop {
let ret = unsafe { libc::randSecure() }
if ret != 0 {
return ret > 0;
}
unsafe { libc::usleep(10) };
}
}
pub fn getrandom_inner(dest: &mut [u8]) -> Result<(), Error> {
static RNG_INIT: LazyBool = LazyBool::new();
if !RNG_INIT.unsync_init(rng_init) {
return Err(RAND_SECURE_FATAL);
}
// Prevent overflow of i32
...
You could also use a lambda, if you think it would look better.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@BaoshanPang @n-salim
Is it possible for the system to recover after randSecure
failure or can we assume that once it has failed it will always fail?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, the system can recover after randSecure failure. This is the randSecure's function desciption:
- randSecure - determine if state is secure
- This routine determines if state is secure and returns status.
- When the system boots, the SW random number lib contains no entropy. Once
- enough entropy has been collected in order to make the random numbers
- cryptographically secure, the state is considered to be secure.
- It will make a system call to a kernel side handler.
- RETURNS: 1 if the state is secure, 0 if the state is not secure, ERROR if
- the random number generator module is not initialized.
- ERRNOS: N/A
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"ERROR if the random number generator module is not initialized."
If I'm understanding this right, the RNG module might not be initialized, but it could become initialized later?
If that's the case, the current code looks good to me.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice job @newpavlov for fixing this.
static RNG_INIT: AtomicBool = AtomicBool::new(false); | ||
|
||
pub fn getrandom_inner(dest: &mut [u8]) -> Result<(), Error> { | ||
while !RNG_INIT.load(Relaxed) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"ERROR if the random number generator module is not initialized."
If I'm understanding this right, the RNG module might not be initialized, but it could become initialized later?
If that's the case, the current code looks good to me.
I couldn't find a proper documentation for VxWorks, so I've mostly just copied code from
std
.Relevant issue: openssl/openssl#7946
This PR will not work until rust-lang/libc#1473 lands.
cc @bpangWR @BaoshanPang