You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

114 lines
3.3 KiB

use proptest::prelude::*;
use std::convert::TryFrom;
use wiggle::{GuestMemory, GuestPtr};
use wiggle_test::{impl_errno, HostMemory, MemArea, WasiCtx};
wiggle::from_witx!({
witx: ["tests/flags.witx"],
ctx: WasiCtx,
});
impl_errno!(types::Errno, types::GuestErrorConversion);
impl<'a> flags::Flags for WasiCtx<'a> {
fn configure_car(
&self,
old_config: types::CarConfig,
other_config_ptr: &GuestPtr<types::CarConfig>,
) -> Result<types::CarConfig, types::Errno> {
Rewrite for recursive safety This commit rewrites the runtime crate to provide safety in the face of recursive calls to the guest. The basic principle is that `GuestMemory` is now a trait which dynamically returns the pointer/length pair. This also has an implicit contract (hence the `unsafe` trait) that the pointer/length pair point to a valid list of bytes in host memory &#34;until something is reentrant&#34;. After this changes the various suite of `Guest*` types were rewritten. `GuestRef` and `GuestRefMut` were both removed since they cannot safely exist. The `GuestPtrMut` type was removed for simplicity, and the final `GuestPtr` type subsumes `GuestString` and `GuestArray`. This means that there&#39;s only one guest pointer type, `GuestPtr&lt;&#39;a, T&gt;`, where `&#39;a` is the borrow into host memory, basically borrowing the `GuestMemory` trait object itself. Some core utilities are exposed on `GuestPtr`, but they&#39;re all 100% safe. Unsafety is now entirely contained within a few small locations: * Implementations of the `GuestType` for primitive types (e.g. `i8`, `u8`, etc) use `unsafe` to read/write memory. The `unsafe` trait of `GuestMemory` though should prove that they&#39;re safe. * `GuestPtr&lt;&#39;_, str&gt;` has a method which validates utf-8 contents, and this requires `unsafe` internally to read all the bytes. This is guaranteed to be safe however given the contract of `GuestMemory`. And that&#39;s it! Everything else is a bunch of safe combinators all built up on the various utilities provided by `GuestPtr`. The general idioms are roughly the same as before, with various tweaks here and there. A summary of expected idioms are: * For small values you&#39;d `.read()` or `.write()` very quickly. You&#39;d pass around the type itself. * For strings, you&#39;d pass `GuestPtr&lt;&#39;_, str&gt;` down to the point where it&#39;s actually consumed. At that moment you&#39;d either decide to copy it out (a safe operation) or you&#39;d get a raw view to the string (an unsafe operation) and assert that you won&#39;t call back into wasm while you&#39;re holding that pointer. * Arrays are similar to strings, passing around `GuestPtr&lt;&#39;_, [T]&gt;`. Arrays also have a `iter()` method which yields an iterator of `GuestPtr&lt;&#39;_, T&gt;` for convenience. Overall there&#39;s still a lot of missing documentation on the runtime crate specifically around the safety of the `GuestMemory` trait as well as how the utilities/methods are expected to be used. Additionally there&#39;s utilities which aren&#39;t currently implemented which would be easy to implement. For example there&#39;s no method to copy out a string or a slice, although that would be pretty easy to add. In any case I&#39;m curious to get feedback on this approach and see what y&#39;all think!
5 years ago
let other_config = other_config_ptr.read().map_err(|e| {
eprintln!("old_config_ptr error: {}", e);
types::Errno::InvalidArg
})?;
Ok(old_config ^ other_config)
}
}
fn car_config_strat() -> impl Strategy<Value = types::CarConfig> {
(1u8..=types::CarConfig::all().into())
.prop_map(|v| {
types::CarConfig::try_from(v).expect("invalid value for types::CarConfig flag")
})
.boxed()
}
#[derive(Debug)]
struct ConfigureCarExercise {
old_config: types::CarConfig,
other_config: types::CarConfig,
other_config_by_ptr: MemArea,
return_ptr_loc: MemArea,
}
impl ConfigureCarExercise {
pub fn strat() -> BoxedStrategy<Self> {
(
car_config_strat(),
car_config_strat(),
HostMemory::mem_area_strat(4),
HostMemory::mem_area_strat(4),
)
.prop_map(
|(old_config, other_config, other_config_by_ptr, return_ptr_loc)| Self {
old_config,
other_config,
other_config_by_ptr,
return_ptr_loc,
},
)
.prop_filter("non-overlapping ptrs", |e| {
MemArea::non_overlapping_set(&[e.other_config_by_ptr, e.return_ptr_loc])
})
.boxed()
}
pub fn test(&self) {
Rewrite for recursive safety This commit rewrites the runtime crate to provide safety in the face of recursive calls to the guest. The basic principle is that `GuestMemory` is now a trait which dynamically returns the pointer/length pair. This also has an implicit contract (hence the `unsafe` trait) that the pointer/length pair point to a valid list of bytes in host memory &#34;until something is reentrant&#34;. After this changes the various suite of `Guest*` types were rewritten. `GuestRef` and `GuestRefMut` were both removed since they cannot safely exist. The `GuestPtrMut` type was removed for simplicity, and the final `GuestPtr` type subsumes `GuestString` and `GuestArray`. This means that there&#39;s only one guest pointer type, `GuestPtr&lt;&#39;a, T&gt;`, where `&#39;a` is the borrow into host memory, basically borrowing the `GuestMemory` trait object itself. Some core utilities are exposed on `GuestPtr`, but they&#39;re all 100% safe. Unsafety is now entirely contained within a few small locations: * Implementations of the `GuestType` for primitive types (e.g. `i8`, `u8`, etc) use `unsafe` to read/write memory. The `unsafe` trait of `GuestMemory` though should prove that they&#39;re safe. * `GuestPtr&lt;&#39;_, str&gt;` has a method which validates utf-8 contents, and this requires `unsafe` internally to read all the bytes. This is guaranteed to be safe however given the contract of `GuestMemory`. And that&#39;s it! Everything else is a bunch of safe combinators all built up on the various utilities provided by `GuestPtr`. The general idioms are roughly the same as before, with various tweaks here and there. A summary of expected idioms are: * For small values you&#39;d `.read()` or `.write()` very quickly. You&#39;d pass around the type itself. * For strings, you&#39;d pass `GuestPtr&lt;&#39;_, str&gt;` down to the point where it&#39;s actually consumed. At that moment you&#39;d either decide to copy it out (a safe operation) or you&#39;d get a raw view to the string (an unsafe operation) and assert that you won&#39;t call back into wasm while you&#39;re holding that pointer. * Arrays are similar to strings, passing around `GuestPtr&lt;&#39;_, [T]&gt;`. Arrays also have a `iter()` method which yields an iterator of `GuestPtr&lt;&#39;_, T&gt;` for convenience. Overall there&#39;s still a lot of missing documentation on the runtime crate specifically around the safety of the `GuestMemory` trait as well as how the utilities/methods are expected to be used. Additionally there&#39;s utilities which aren&#39;t currently implemented which would be easy to implement. For example there&#39;s no method to copy out a string or a slice, although that would be pretty easy to add. In any case I&#39;m curious to get feedback on this approach and see what y&#39;all think!
5 years ago
let ctx = WasiCtx::new();
let host_memory = HostMemory::new();
// Populate input ptr
Rewrite for recursive safety This commit rewrites the runtime crate to provide safety in the face of recursive calls to the guest. The basic principle is that `GuestMemory` is now a trait which dynamically returns the pointer/length pair. This also has an implicit contract (hence the `unsafe` trait) that the pointer/length pair point to a valid list of bytes in host memory &#34;until something is reentrant&#34;. After this changes the various suite of `Guest*` types were rewritten. `GuestRef` and `GuestRefMut` were both removed since they cannot safely exist. The `GuestPtrMut` type was removed for simplicity, and the final `GuestPtr` type subsumes `GuestString` and `GuestArray`. This means that there&#39;s only one guest pointer type, `GuestPtr&lt;&#39;a, T&gt;`, where `&#39;a` is the borrow into host memory, basically borrowing the `GuestMemory` trait object itself. Some core utilities are exposed on `GuestPtr`, but they&#39;re all 100% safe. Unsafety is now entirely contained within a few small locations: * Implementations of the `GuestType` for primitive types (e.g. `i8`, `u8`, etc) use `unsafe` to read/write memory. The `unsafe` trait of `GuestMemory` though should prove that they&#39;re safe. * `GuestPtr&lt;&#39;_, str&gt;` has a method which validates utf-8 contents, and this requires `unsafe` internally to read all the bytes. This is guaranteed to be safe however given the contract of `GuestMemory`. And that&#39;s it! Everything else is a bunch of safe combinators all built up on the various utilities provided by `GuestPtr`. The general idioms are roughly the same as before, with various tweaks here and there. A summary of expected idioms are: * For small values you&#39;d `.read()` or `.write()` very quickly. You&#39;d pass around the type itself. * For strings, you&#39;d pass `GuestPtr&lt;&#39;_, str&gt;` down to the point where it&#39;s actually consumed. At that moment you&#39;d either decide to copy it out (a safe operation) or you&#39;d get a raw view to the string (an unsafe operation) and assert that you won&#39;t call back into wasm while you&#39;re holding that pointer. * Arrays are similar to strings, passing around `GuestPtr&lt;&#39;_, [T]&gt;`. Arrays also have a `iter()` method which yields an iterator of `GuestPtr&lt;&#39;_, T&gt;` for convenience. Overall there&#39;s still a lot of missing documentation on the runtime crate specifically around the safety of the `GuestMemory` trait as well as how the utilities/methods are expected to be used. Additionally there&#39;s utilities which aren&#39;t currently implemented which would be easy to implement. For example there&#39;s no method to copy out a string or a slice, although that would be pretty easy to add. In any case I&#39;m curious to get feedback on this approach and see what y&#39;all think!
5 years ago
host_memory
.ptr(self.other_config_by_ptr.ptr)
.write(self.other_config)
.expect("deref ptr mut to CarConfig");
let res = flags::configure_car(
Rewrite for recursive safety This commit rewrites the runtime crate to provide safety in the face of recursive calls to the guest. The basic principle is that `GuestMemory` is now a trait which dynamically returns the pointer/length pair. This also has an implicit contract (hence the `unsafe` trait) that the pointer/length pair point to a valid list of bytes in host memory &#34;until something is reentrant&#34;. After this changes the various suite of `Guest*` types were rewritten. `GuestRef` and `GuestRefMut` were both removed since they cannot safely exist. The `GuestPtrMut` type was removed for simplicity, and the final `GuestPtr` type subsumes `GuestString` and `GuestArray`. This means that there&#39;s only one guest pointer type, `GuestPtr&lt;&#39;a, T&gt;`, where `&#39;a` is the borrow into host memory, basically borrowing the `GuestMemory` trait object itself. Some core utilities are exposed on `GuestPtr`, but they&#39;re all 100% safe. Unsafety is now entirely contained within a few small locations: * Implementations of the `GuestType` for primitive types (e.g. `i8`, `u8`, etc) use `unsafe` to read/write memory. The `unsafe` trait of `GuestMemory` though should prove that they&#39;re safe. * `GuestPtr&lt;&#39;_, str&gt;` has a method which validates utf-8 contents, and this requires `unsafe` internally to read all the bytes. This is guaranteed to be safe however given the contract of `GuestMemory`. And that&#39;s it! Everything else is a bunch of safe combinators all built up on the various utilities provided by `GuestPtr`. The general idioms are roughly the same as before, with various tweaks here and there. A summary of expected idioms are: * For small values you&#39;d `.read()` or `.write()` very quickly. You&#39;d pass around the type itself. * For strings, you&#39;d pass `GuestPtr&lt;&#39;_, str&gt;` down to the point where it&#39;s actually consumed. At that moment you&#39;d either decide to copy it out (a safe operation) or you&#39;d get a raw view to the string (an unsafe operation) and assert that you won&#39;t call back into wasm while you&#39;re holding that pointer. * Arrays are similar to strings, passing around `GuestPtr&lt;&#39;_, [T]&gt;`. Arrays also have a `iter()` method which yields an iterator of `GuestPtr&lt;&#39;_, T&gt;` for convenience. Overall there&#39;s still a lot of missing documentation on the runtime crate specifically around the safety of the `GuestMemory` trait as well as how the utilities/methods are expected to be used. Additionally there&#39;s utilities which aren&#39;t currently implemented which would be easy to implement. For example there&#39;s no method to copy out a string or a slice, although that would be pretty easy to add. In any case I&#39;m curious to get feedback on this approach and see what y&#39;all think!
5 years ago
&ctx,
&host_memory,
self.old_config.into(),
self.other_config_by_ptr.ptr as i32,
self.return_ptr_loc.ptr as i32,
);
assert_eq!(res, types::Errno::Ok.into(), "configure car errno");
Rewrite for recursive safety This commit rewrites the runtime crate to provide safety in the face of recursive calls to the guest. The basic principle is that `GuestMemory` is now a trait which dynamically returns the pointer/length pair. This also has an implicit contract (hence the `unsafe` trait) that the pointer/length pair point to a valid list of bytes in host memory &#34;until something is reentrant&#34;. After this changes the various suite of `Guest*` types were rewritten. `GuestRef` and `GuestRefMut` were both removed since they cannot safely exist. The `GuestPtrMut` type was removed for simplicity, and the final `GuestPtr` type subsumes `GuestString` and `GuestArray`. This means that there&#39;s only one guest pointer type, `GuestPtr&lt;&#39;a, T&gt;`, where `&#39;a` is the borrow into host memory, basically borrowing the `GuestMemory` trait object itself. Some core utilities are exposed on `GuestPtr`, but they&#39;re all 100% safe. Unsafety is now entirely contained within a few small locations: * Implementations of the `GuestType` for primitive types (e.g. `i8`, `u8`, etc) use `unsafe` to read/write memory. The `unsafe` trait of `GuestMemory` though should prove that they&#39;re safe. * `GuestPtr&lt;&#39;_, str&gt;` has a method which validates utf-8 contents, and this requires `unsafe` internally to read all the bytes. This is guaranteed to be safe however given the contract of `GuestMemory`. And that&#39;s it! Everything else is a bunch of safe combinators all built up on the various utilities provided by `GuestPtr`. The general idioms are roughly the same as before, with various tweaks here and there. A summary of expected idioms are: * For small values you&#39;d `.read()` or `.write()` very quickly. You&#39;d pass around the type itself. * For strings, you&#39;d pass `GuestPtr&lt;&#39;_, str&gt;` down to the point where it&#39;s actually consumed. At that moment you&#39;d either decide to copy it out (a safe operation) or you&#39;d get a raw view to the string (an unsafe operation) and assert that you won&#39;t call back into wasm while you&#39;re holding that pointer. * Arrays are similar to strings, passing around `GuestPtr&lt;&#39;_, [T]&gt;`. Arrays also have a `iter()` method which yields an iterator of `GuestPtr&lt;&#39;_, T&gt;` for convenience. Overall there&#39;s still a lot of missing documentation on the runtime crate specifically around the safety of the `GuestMemory` trait as well as how the utilities/methods are expected to be used. Additionally there&#39;s utilities which aren&#39;t currently implemented which would be easy to implement. For example there&#39;s no method to copy out a string or a slice, although that would be pretty easy to add. In any case I&#39;m curious to get feedback on this approach and see what y&#39;all think!
5 years ago
let res_config = host_memory
.ptr::<types::CarConfig>(self.return_ptr_loc.ptr)
Rewrite for recursive safety This commit rewrites the runtime crate to provide safety in the face of recursive calls to the guest. The basic principle is that `GuestMemory` is now a trait which dynamically returns the pointer/length pair. This also has an implicit contract (hence the `unsafe` trait) that the pointer/length pair point to a valid list of bytes in host memory &#34;until something is reentrant&#34;. After this changes the various suite of `Guest*` types were rewritten. `GuestRef` and `GuestRefMut` were both removed since they cannot safely exist. The `GuestPtrMut` type was removed for simplicity, and the final `GuestPtr` type subsumes `GuestString` and `GuestArray`. This means that there&#39;s only one guest pointer type, `GuestPtr&lt;&#39;a, T&gt;`, where `&#39;a` is the borrow into host memory, basically borrowing the `GuestMemory` trait object itself. Some core utilities are exposed on `GuestPtr`, but they&#39;re all 100% safe. Unsafety is now entirely contained within a few small locations: * Implementations of the `GuestType` for primitive types (e.g. `i8`, `u8`, etc) use `unsafe` to read/write memory. The `unsafe` trait of `GuestMemory` though should prove that they&#39;re safe. * `GuestPtr&lt;&#39;_, str&gt;` has a method which validates utf-8 contents, and this requires `unsafe` internally to read all the bytes. This is guaranteed to be safe however given the contract of `GuestMemory`. And that&#39;s it! Everything else is a bunch of safe combinators all built up on the various utilities provided by `GuestPtr`. The general idioms are roughly the same as before, with various tweaks here and there. A summary of expected idioms are: * For small values you&#39;d `.read()` or `.write()` very quickly. You&#39;d pass around the type itself. * For strings, you&#39;d pass `GuestPtr&lt;&#39;_, str&gt;` down to the point where it&#39;s actually consumed. At that moment you&#39;d either decide to copy it out (a safe operation) or you&#39;d get a raw view to the string (an unsafe operation) and assert that you won&#39;t call back into wasm while you&#39;re holding that pointer. * Arrays are similar to strings, passing around `GuestPtr&lt;&#39;_, [T]&gt;`. Arrays also have a `iter()` method which yields an iterator of `GuestPtr&lt;&#39;_, T&gt;` for convenience. Overall there&#39;s still a lot of missing documentation on the runtime crate specifically around the safety of the `GuestMemory` trait as well as how the utilities/methods are expected to be used. Additionally there&#39;s utilities which aren&#39;t currently implemented which would be easy to implement. For example there&#39;s no method to copy out a string or a slice, although that would be pretty easy to add. In any case I&#39;m curious to get feedback on this approach and see what y&#39;all think!
5 years ago
.read()
.expect("deref to CarConfig value");
assert_eq!(
self.old_config ^ self.other_config,
res_config,
"returned CarConfig should be an XOR of inputs"
);
}
}
proptest! {
#[test]
fn configure_car(e in ConfigureCarExercise::strat()) {
e.test()
}
}
#[test]
fn flags_fmt() {
let empty = format!("{}", types::CarConfig::empty());
assert_eq!(empty, "empty (0x0)");
let one_flag = format!("{}", types::CarConfig::AWD);
assert_eq!(one_flag, "awd (0x2)");
let two_flags = format!("{}", types::CarConfig::AUTOMATIC | types::CarConfig::SUV);
assert_eq!(two_flags, "automatic|suv (0x5)");
let all = format!("{}", types::CarConfig::all());
assert_eq!(all, "automatic|awd|suv (0x7)");
}