-
Notifications
You must be signed in to change notification settings - Fork 730
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
Adds rng support for Fuchsia #634
Conversation
Is there anything I can do to help move this forward? |
@cavedweller I think this comment summarises the projects current priorities. |
Thanks for the PR. I'm not excited about the new crate dependency. In my past experience with crates that have depended on Since we already have direct native code dependencies in ring, it seems better to me to just directlyu call the underlying function that |
I totally understand not wanting crate dependencies. However, I don't foresee any Fuchsia specific changes necessary beyond this, and I'm fairly certain you'll never need to download You'd also need to link against the Upsides of leaving it a crate, we might wind up changing this syscall a little bit and it's definitely easier to just bump the version. If you definitely want the dependency moved from |
In another project, when I do the docker build that targets x86-64, this is what I see: $ cargo fetch --locked
[...]
Downloading fuchsia-zircon-sys v0.3.3
[...]
Downloading fuchsia-zircon v0.3.3
[...]
Downloading bitflags v1.0.1
[...] Since Note that ring only depends on two crates right now: libc and untrusted, neither of which has dependencies. So adding support for calling this one function on one little-used platform (albeit one I am truly excited about) by more than doubling the crate dependencies doesn't seem worth it to me, without seeing a specific issue that makes it difficult to avoid the Rust wrapper. If there is something difficult about avoiding the Rust wrapper then I'd reconsider. |
OK, I see the problem is a limitation of So, I don't think the additional optional crate dependencies are are problem any more. I will review the PR more carefully soon. |
cargo can now fetch targets! Are there any more blockers I can help with? |
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.
Are there any more blockers I can help with?
I got bogged down trying to set up a Fuchsia build/test environment. Could you please document:
- What's the minimum build environment and configuration of Fuchsia/Zircon that one can use to build ring and run its test suite?
- Can you help add Fuchsia/Zircon to ring's CI? For now it would be convenient if we could run the build & tests on Travis CI however I would be happy with doing it in Google Cloud Container Builder or perhaps some other thing (I'm looking to containerize all of ring CI in the near future.)
use error; | ||
|
||
pub fn fill(dest: &mut [u8]) -> Result<(), error::Unspecified> { | ||
for s in dest.chunks_mut(fuchsia_zircon::sys::ZX_CPRNG_DRAW_MAX_LEN) { |
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.
Let's simplify this code by removing this outer loop and avoid using chunks_mut()
.
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 can't yet remove the outer loop. The current syscall guarantees on fuchsia for CPRNG_DRAW don't guarantee a full read, because you might be kicked out of the kernel space.
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 have an active issue addressing this, and it will be changed.
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 can't yet remove the outer loop. The current syscall guarantees on fuchsia for CPRNG_DRAW don't guarantee a full read, because you might be kicked out of the kernel space.
Isn't that handled by the inner loop? I agree we need to keep the inner loop, but the outer loop seems unnecessary. In particular, consider this case:
- The buffer to fill is 4/3 * ZX_CPRNG_DRAW_MAX_LEN bytes long.
- Each call to
fuchsia_zircon::cprng_draw
gives us 2/3 of ZX_CPRNG_DRAW_MAX_LEN bytes.
In such a scenerio, without the outer loop, 2 calls to fuchsia_zircon::cprng_draw
are needed. But, with the outer loop, 3 calls to fuchsia_zircon::cprng_draw
are needed.
In your commit message, please indicate who is making the contribution (e.g. "Contributed on behalf of Google, Inc."). Also please add the note that appears here to the commit message: https://github.com/briansmith/ring#contributing. |
I'm going to close this PR because, looking at the recent BoringSSL PRs, this is out-of-date w.r.t. the current Fuchsia API. If anybody has a solution for adding Fuchsia to CI (Travis CI or otherwise), I'd love to see it. |
This is another attempt for ring to support fuchsia, by directly calling `zx_cprng_draw` to generate random byte strings. This avoids having to pull in an extra dependency (which briansmith#634 did). With this change, all the ring tests pass on fuchsia. Closes briansmith#428
This is another attempt for ring to support fuchsia, by directly calling `zx_cprng_draw` to generate random byte strings. This avoids having to pull in an extra dependency (which briansmith#634 did). With this change, all the ring tests pass on fuchsia. I agree to license my contributions to each file under the terms given at the top of each file I changed. Closes briansmith#428
This is another attempt for ring to support fuchsia, by directly calling `zx_cprng_draw` to generate random byte strings. This avoids having to pull in an extra dependency (which briansmith#634 did). With this change, all the ring tests pass on fuchsia. I agree to license my contributions to each file under the terms given at the top of each file I changed. Closes briansmith#428
This is an alternative implementation to briansmith#634 that doesn't require pulling in the `fuchsia-zircon` crate. Also, another problem that we had in briansmith#634 is that zx_cprng_draw required a loop, that is no longer necessary in the latest fuchsia version.
This is another attempt for ring to support fuchsia, by directly calling `zx_cprng_draw` to generate random byte strings. This avoids having to pull in an extra dependency (which briansmith#634 did). With this change, all the ring tests pass on fuchsia. I agree to license my contributions to each file under the terms given at the top of each file I changed. Closes briansmith#428
This is another attempt for ring to support fuchsia, by directly calling `zx_cprng_draw` to generate random byte strings. This avoids having to pull in an extra dependency (which briansmith#634 did). With this change, all the ring tests pass on fuchsia. I agree to license my contributions to each file under the terms given at the top of each file I changed. Closes briansmith#428
This is another attempt for ring to support fuchsia, by directly calling `zx_cprng_draw` to generate random byte strings. This avoids having to pull in an extra dependency (which #634 did). With this change, all the ring tests pass on fuchsia. I agree to license my contributions to each file under the terms given at the top of each file I changed. Closes #428
We're considering using ring as the basis of our Rust crypto for Fuchsia. The std::rand crate already has Fuchsia OS specific support and it would be great if we could get it in ring as well.
I agree to license my contributions to each file under the terms given
at the top of each file I changed.