This allows users to get an actionable error message about this
particular problem. We also add detection for this problem.
Signed-off-by: Joe Richey <joerichey@google.com>
Now we look for the standard Web Cryptography API before attempting to
check for Node.js support. This allows Node.js ES6 module users to add
a polyfill like:
```js
import {webcrypto} from 'crypto'
globalThis.crypto = webcrypto
```
as described in https://github.com/rust-random/getrandom/issues/256#issuecomment-1161028902
Signed-off-by: Joe Richey <joerichey@google.com>
* add description about Cargo js feature
* add note about different crate types
* clean up
* Fix wording/grammer
* Remove "Indirect Depenencies" section
* Note that libraries shouldn't add their own JS feature
Signed-off-by: Joe Richey <joerichey@google.com>
Co-authored-by: Mauri Mustonen <mauri.mustonen@hotmail.com>
Co-authored-by: Joe Richey <joerichey@google.com>
This PR adds more benchmarks so we can get and accurate idea about two
things:
- What is the cost of having to zero the buffer before calling
`getrandom`?
- What is the performance on aligned, 32-byte buffers?
- This is by far the most common use, as its used to seed
usersapce CSPRNGs.
I ran the benchmarks on my system:
- CPU: AMD Ryzen 7 5700G
- OS: Linux 5.15.52-1-lts
- Rust Version: 1.62.0-nightly (ea92b0838 2022-05-07)
I got the following results:
```
test bench_large ... bench: 3,759,323 ns/iter (+/- 177,100) = 557 MB/s
test bench_large_init ... bench: 3,821,229 ns/iter (+/- 39,132) = 548 MB/s
test bench_page ... bench: 7,281 ns/iter (+/- 59) = 562 MB/s
test bench_page_init ... bench: 7,290 ns/iter (+/- 69) = 561 MB/s
test bench_seed ... bench: 206 ns/iter (+/- 3) = 155 MB/s
test bench_seed_init ... bench: 206 ns/iter (+/- 1) = 155 MB/s
```
These results were very consistent across multiple runs, and roughtly
behave as we would expect:
- The thoughput is highest with a buffer large enough to amoritize the
syscall overhead, but small enough to stay in the L1D cache.
- There is a _very_ small cost to zeroing the buffer beforehand.
- This cost is imperceptible in the common 32-byte usecase, where the
syscall overhead dominates.
- The cost is slightly higher (1%) with multi-megabyte buffers as the
data gets evicted from the L1 cache between the `memset` and the
call to `getrandom`.
I would love to see results for other platforms. Could we get someone to
run this on an M1 Mac?
Signed-off-by: Joe Richey <joerichey@google.com>
This allows Strict Provenance to work properly, fixing #262. It also
now matches what `libstd` does:
9f7e997c8b/library/std/src/sys/unix/weak.rs (L85-L141)
Also, while reading the `libstd` code, I noticed that they use an
`Acquire` fence and `Release` store as the returned pointer should
have "consume" semantics. As this doesn't yet exist in Rust, we
instead do exactly what `libstd` does, which means:
- Relaxed Load
- Release Store
- Acquire fence when returning pointer
Signed-off-by: Joe Richey <joerichey@google.com>
Co-authored-by: Joe ST <joe@fbstj.net>
* Update to wasi 0.11
The main breaking change between v0.10 and v0.11 is that Error is
removed in favour of Errno. Unfortunately we can't create an Errno from
outside the wasi create so we're loosing some debug information for
errors.
I've opened an issue to add back such a constructor, see
<https://github.com/bytecodealliance/wasi/issues/64>.
* Use libc::strerror to get the error message on wasi
Since wasi v0.11 doesn't (yet) provided a way to create Errno, see
<https://github.com/bytecodealliance/wasi/issues/64>.
* Remove libc dependency for WASI
This does mean that we won't get an error message for the error type.
The open call can be interrupted. Since sys_fill_exact covers this for
read operation already, it should be done here as well.
Signed-off-by: Tobias Stoeckmann <tobias@stoeckmann.org>
Webpack supports dynamic importing only for some special cases in which
it is able to narrow down the set of packages to bundled. In the
general case it just produces an empty (Webpack) context plus the
warning stating that "the request of a dependency is an expression."
Apparently the commit 120a1d7f changed the Javascript generated by
wasm-bindgen so that the binding for the `require` became:
```
module.require(getStringFromWasm0(arg0, arg1))
```
when it used to be:
```
getObject(arg0).require(getStringFromWasm0(arg1, arg2))
```
In the latter case Webpack did not even realize that this code imported
a package and, hence, did not try to bundle it. The new code triggers
the bundling and because the dependency is fully dynamic Webpack has
problems with it.
This commit reverts partially the commit 120a1d7f so that the generated
binding obfuscates the `require` call enough to hide it from Webpack
again.
This uses `process.versions.node` to see if we are in Node.js rather
than using `global.self` to check if we are in a Browser.
This change also makes some minor `wasm_bindgen` improvements:
- Use `js_sys::global()` to get the global object
- Bind the node require as `module.require`
- Improving error messages
Signed-off-by: Joe Richey <joerichey@google.com>
DragonFly BSD supports the getrandom system call since version 5.7 [1].
Use it if available, otherwise fall back to /dev/random.
[1] https://leaf.dragonflybsd.org/cgi/web-man?command=getrandom
Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
