Skip to content

wasip2 uses wasi:random/random to generate hashmap_random_keys #129402

Open
@juntyr

Description

wasip2 currently still uses (all?) wasip1 implementations internally. The generation of hashmap_random_keys for wasip1 is implemented here:

pub fn hashmap_random_keys() -> (u64, u64) {
let mut ret = (0u64, 0u64);
unsafe {
let base = &mut ret as *mut (u64, u64) as *mut u8;
let len = mem::size_of_val(&ret);
wasi::random_get(base, len).expect("random_get failure");
}
return ret;
}

using the wasi::random_get (https://github.com/WebAssembly/WASI/blob/main/legacy/preview1/docs.md#-random_getbuf-pointeru8-buf_len-size---result-errno) general-purpose function. With the popular wasi-preview1-component adapter crate (https://github.com/bytecodealliance/wasmtime/tree/main/crates/wasi-preview1-component-adapter), this call is mapped to the wasi:random/random wasip2 interface, which must be backed by a secure random source. This is unfortunate as wasip2 Rust code which only uses randomness in hashmaps now required a secure random source when an insecure one would suffice.

In wasip2, there is the separate wasi:random/insecure-seed interface, which is specifically designed to provide DoS protection when initialising a hash map. When the wasip2 implementation is fleshed out, perhaps the hashmap_random_keys function could be implemented with a pseudo-RNG that is seeded with one call to wasi:random/insecure-seed's insecure-seed()?

cc @alexcrichton

Activity

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

Metadata

Assignees

No one assigned

    Labels

    O-wasiOperating system: Wasi, Webassembly System InterfaceO-wasmTarget: WASM (WebAssembly), http://webassembly.org/

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions