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 VxWorks support #86

Merged
merged 14 commits into from
Oct 23, 2019
Merged

Add VxWorks support #86

merged 14 commits into from
Oct 23, 2019

Conversation

newpavlov
Copy link
Member

@newpavlov newpavlov commented Aug 14, 2019

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

@BaoshanPang
Copy link

@newpavlov

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,
Baoshan

@newpavlov
Copy link
Member Author

If I understood you correctly, then you don't have to do anything. Assuming this PR is correct, after publishing the next version of getrandom with it, rand v0.7 should start working on VxWorks automatically.

libstd only recently started using rand v0.7, I think after this PR: rust-lang/rust#61393.

@BaoshanPang
Copy link

libstd only recently started using rand v0.7, I think after this PR: rust-lang/rust#61393.
I see. Thanks.

src/vxworks.rs Outdated Show resolved Hide resolved
src/vxworks.rs Outdated Show resolved Hide resolved
@newpavlov
Copy link
Member Author

@n-salim
Also do we have to provide any linking arguments to Cargo? See build.rs. Note that in future getrandom may be used as a dependency of std.

@n-salim
Copy link

n-salim commented Aug 14, 2019

Also do we have to provide any linking arguments to Cargo?
Good question. Luckily randBytes is part of VxWorks libc.a, which we already always link against.

@newpavlov
Copy link
Member Author

Luckily randBytes is part of VxWorks libc.a, which we already always link against.

How about adding randBytes to the libc crate then? It would allow us to simplify code in getrandom a bit. Also please take look at rust-lang/libc#1469.

@BaoshanPang
Copy link

How about adding randBytes to the libc crate then?

I will do it as part of libc#1469.

@BaoshanPang
Copy link

If I understood you correctly, then you don't have to do anything. Assuming this PR is correct, after publishing the next version of getrandom with it, rand v0.7 should start working on VxWorks automatically.

libstd only recently started using rand v0.7, I think after this PR: rust-lang/rust#61393.

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
...
Compiling rand v0.6.1

bors added a commit to rust-lang/libc that referenced this pull request Aug 19, 2019
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
bors added a commit to rust-lang/libc that referenced this pull request Aug 20, 2019
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
@josephlr josephlr mentioned this pull request Sep 18, 2019
Copy link
Member

@josephlr josephlr left a 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).

Cargo.toml Show resolved Hide resolved
src/vxworks.rs Outdated Show resolved Hide resolved
src/lib.rs Outdated Show resolved Hide resolved
static RNG_INIT: AtomicBool = AtomicBool::new(false);

pub fn getrandom_inner(dest: &mut [u8]) -> Result<(), Error> {
while !RNG_INIT.load(Relaxed) {
Copy link
Member

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.

Copy link
Member Author

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?

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

Copy link
Member

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.

Cargo.toml Outdated Show resolved Hide resolved
@newpavlov newpavlov requested a review from dhardy October 22, 2019 15:31
Copy link
Member

@josephlr josephlr left a 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.

src/error.rs Outdated Show resolved Hide resolved
static RNG_INIT: AtomicBool = AtomicBool::new(false);

pub fn getrandom_inner(dest: &mut [u8]) -> Result<(), Error> {
while !RNG_INIT.load(Relaxed) {
Copy link
Member

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.

@newpavlov newpavlov merged commit 9a385f1 into master Oct 23, 2019
@newpavlov newpavlov deleted the vxworks branch October 28, 2019 15:51
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

Successfully merging this pull request may close these issues.

4 participants