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.

553 lines
16 KiB

use proptest::prelude::*;
use wiggle::{GuestMemory, GuestPtr};
use wiggle_test::{impl_errno, HostMemory, MemArea, MemAreas, WasiCtx};
wiggle::from_witx!({
witx: ["$CARGO_MANIFEST_DIR/tests/records.witx"],
});
impl_errno!(types::Errno, types::GuestErrorConversion);
impl<'a> records::Records for WasiCtx<'a> {
fn sum_of_pair(&self, an_pair: &types::PairInts) -> Result<i64, types::Errno> {
Ok(an_pair.first as i64 + an_pair.second as i64)
}
fn sum_of_pair_of_ptrs(&self, an_pair: &types::PairIntPtrs) -> Result<i64, 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 first = an_pair
.first
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("dereferencing GuestPtr should succeed");
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 second = an_pair
.second
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("dereferncing GuestPtr should succeed");
Ok(first as i64 + second as i64)
}
fn sum_of_int_and_ptr(&self, an_pair: &types::PairIntAndPtr) -> Result<i64, 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 first = an_pair
.first
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("dereferencing GuestPtr should succeed");
let second = an_pair.second as i64;
Ok(first as i64 + second)
}
fn return_pair_ints(&self) -> Result<types::PairInts, types::Errno> {
Ok(types::PairInts {
first: 10,
second: 20,
})
}
fn return_pair_of_ptrs<'b>(
&self,
first: &GuestPtr<'b, i32>,
second: &GuestPtr<'b, i32>,
) -> Result<types::PairIntPtrs<'b>, types::Errno> {
Ok(types::PairIntPtrs {
first: *first,
second: *second,
})
}
fn sum_array<'b>(&self, record_of_list: &types::RecordOfList<'b>) -> Result<u16, types::Errno> {
// my kingdom for try blocks
fn aux(record_of_list: &types::RecordOfList) -> Result<u16, wiggle::GuestError> {
let mut s = 0;
for elem in record_of_list.arr.iter() {
let v = elem?.read()?;
s += v as u16;
}
Ok(s)
}
match aux(record_of_list) {
Ok(s) => Ok(s),
Err(guest_err) => {
eprintln!("guest error summing array: {:?}", guest_err);
Err(types::Errno::PicketLine)
}
}
}
}
#[derive(Debug)]
struct SumOfPairExercise {
pub input: types::PairInts,
pub input_loc: MemArea,
pub return_loc: MemArea,
}
impl SumOfPairExercise {
pub fn strat() -> BoxedStrategy<Self> {
(
prop::num::i32::ANY,
prop::num::i32::ANY,
HostMemory::mem_area_strat(8),
HostMemory::mem_area_strat(8),
)
.prop_map(|(first, second, input_loc, return_loc)| SumOfPairExercise {
input: types::PairInts { first, second },
input_loc,
return_loc,
})
.prop_filter("non-overlapping pointers", |e| {
MemArea::non_overlapping_set(&[e.input_loc, e.return_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();
host_memory
.ptr(self.input_loc.ptr)
.write(self.input.first)
.expect("input ref_mut");
host_memory
.ptr(self.input_loc.ptr + 4)
.write(self.input.second)
.expect("input ref_mut");
let sum_err = records::sum_of_pair(
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.input_loc.ptr as i32,
self.return_loc.ptr as i32,
);
4 years ago
assert_eq!(sum_err, Ok(types::Errno::Ok as i32), "sum 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 return_val: i64 = host_memory
.ptr(self.return_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("return ref");
assert_eq!(
return_val,
self.input.first as i64 + self.input.second as i64,
"sum return value"
);
}
}
proptest! {
#[test]
fn sum_of_pair(e in SumOfPairExercise::strat()) {
e.test();
}
}
#[derive(Debug)]
struct SumPairPtrsExercise {
input_first: i32,
input_second: i32,
input_first_loc: MemArea,
input_second_loc: MemArea,
input_struct_loc: MemArea,
return_loc: MemArea,
}
impl SumPairPtrsExercise {
pub fn strat() -> BoxedStrategy<Self> {
(
prop::num::i32::ANY,
prop::num::i32::ANY,
HostMemory::mem_area_strat(4),
HostMemory::mem_area_strat(4),
HostMemory::mem_area_strat(8),
HostMemory::mem_area_strat(8),
)
.prop_map(
|(
input_first,
input_second,
input_first_loc,
input_second_loc,
input_struct_loc,
return_loc,
)| SumPairPtrsExercise {
input_first,
input_second,
input_first_loc,
input_second_loc,
input_struct_loc,
return_loc,
},
)
.prop_filter("non-overlapping pointers", |e| {
MemArea::non_overlapping_set(&[
e.input_first_loc,
e.input_second_loc,
e.input_struct_loc,
e.return_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();
host_memory
.ptr(self.input_first_loc.ptr)
.write(self.input_first)
.expect("input_first ref");
host_memory
.ptr(self.input_second_loc.ptr)
.write(self.input_second)
.expect("input_second ref");
host_memory
.ptr(self.input_struct_loc.ptr)
.write(self.input_first_loc.ptr)
.expect("input_struct ref");
host_memory
.ptr(self.input_struct_loc.ptr + 4)
.write(self.input_second_loc.ptr)
.expect("input_struct ref");
let res = records::sum_of_pair_of_ptrs(
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.input_struct_loc.ptr as i32,
self.return_loc.ptr as i32,
);
Fixes #2418: Enhance wiggle to generate its UserErrorConverstion trait with a function that returns Result&lt;abi_err, String&gt; (#2419) * Enhance wiggle to generate its UserErrorConverstion trait with a function that returns a Result&lt;abi_err, String&gt;. This enhancement allows hostcall implementations using wiggle to return an actionable error to the instance (the abi_err) or to terminate the instance using the String as fatal error information. * Enhance wiggle to generate its UserErrorConverstion trait with a function that returns a Result&lt;abi_err, String&gt;. This enhancement allows hostcall implementations using wiggle to return an actionable error to the instance (the abi_err) or to terminate the instance using the String as fatal error information. * Enhance the wiggle/wasmtime integration to leverage new work in ab7e9c6. Hostcall implementations generated by wiggle now return an Result&lt;abi_error, Trap&gt;. As a result, hostcalls experiencing fatal errors may trap, thereby terminating the wasmtime instance. This enhancement has been performed for both wasi snapshot1 and wasi snapshot0. * Update wasi-nn crate to reflect enhancement in issue #2418. * Update wiggle test-helpers for wiggle enhancement made in issue #2418. * Address PR feedback; omit verbose return statement. * Address PR feedback; manually format within a proc macro. * Address PR feedback; manually format proc macro. * Restore return statements to wasi.rs. * Restore return statements in funcs.rs. * Address PR feedback; omit TODO and fix formatting. * Ok-wrap error type in assert statement.
4 years ago
assert_eq!(
res,
4 years ago
Ok(types::Errno::Ok as i32),
Fixes #2418: Enhance wiggle to generate its UserErrorConverstion trait with a function that returns Result&lt;abi_err, String&gt; (#2419) * Enhance wiggle to generate its UserErrorConverstion trait with a function that returns a Result&lt;abi_err, String&gt;. This enhancement allows hostcall implementations using wiggle to return an actionable error to the instance (the abi_err) or to terminate the instance using the String as fatal error information. * Enhance wiggle to generate its UserErrorConverstion trait with a function that returns a Result&lt;abi_err, String&gt;. This enhancement allows hostcall implementations using wiggle to return an actionable error to the instance (the abi_err) or to terminate the instance using the String as fatal error information. * Enhance the wiggle/wasmtime integration to leverage new work in ab7e9c6. Hostcall implementations generated by wiggle now return an Result&lt;abi_error, Trap&gt;. As a result, hostcalls experiencing fatal errors may trap, thereby terminating the wasmtime instance. This enhancement has been performed for both wasi snapshot1 and wasi snapshot0. * Update wasi-nn crate to reflect enhancement in issue #2418. * Update wiggle test-helpers for wiggle enhancement made in issue #2418. * Address PR feedback; omit verbose return statement. * Address PR feedback; manually format within a proc macro. * Address PR feedback; manually format proc macro. * Restore return statements to wasi.rs. * Restore return statements in funcs.rs. * Address PR feedback; omit TODO and fix formatting. * Ok-wrap error type in assert statement.
4 years ago
"sum of pair of ptrs 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 doubled: i64 = host_memory
.ptr(self.return_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("return ref");
assert_eq!(
doubled,
(self.input_first as i64) + (self.input_second as i64),
"sum of pair of ptrs return val"
);
}
}
proptest! {
#[test]
fn sum_of_pair_of_ptrs(e in SumPairPtrsExercise::strat()) {
e.test()
}
}
#[derive(Debug)]
struct SumIntAndPtrExercise {
input_first: i32,
input_second: i32,
input_first_loc: MemArea,
input_struct_loc: MemArea,
return_loc: MemArea,
}
impl SumIntAndPtrExercise {
pub fn strat() -> BoxedStrategy<Self> {
(
prop::num::i32::ANY,
prop::num::i32::ANY,
HostMemory::mem_area_strat(4),
HostMemory::mem_area_strat(8),
HostMemory::mem_area_strat(8),
)
.prop_map(
|(input_first, input_second, input_first_loc, input_struct_loc, return_loc)| {
SumIntAndPtrExercise {
input_first,
input_second,
input_first_loc,
input_struct_loc,
return_loc,
}
},
)
.prop_filter("non-overlapping pointers", |e| {
MemArea::non_overlapping_set(&[e.input_first_loc, e.input_struct_loc, e.return_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();
host_memory
.ptr(self.input_first_loc.ptr)
.write(self.input_first)
.expect("input_first ref");
host_memory
.ptr(self.input_struct_loc.ptr)
.write(self.input_first_loc.ptr)
.expect("input_struct ref");
host_memory
.ptr(self.input_struct_loc.ptr + 4)
.write(self.input_second)
.expect("input_struct ref");
let res = records::sum_of_int_and_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
&ctx,
&host_memory,
self.input_struct_loc.ptr as i32,
self.return_loc.ptr as i32,
);
4 years ago
assert_eq!(res, Ok(types::Errno::Ok as i32), "sum of int and ptr 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 doubled: i64 = host_memory
.ptr(self.return_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("return ref");
assert_eq!(
doubled,
(self.input_first as i64) + (self.input_second as i64),
"sum of pair of ptrs return val"
);
}
}
proptest! {
#[test]
fn sum_of_int_and_ptr(e in SumIntAndPtrExercise::strat()) {
e.test()
}
}
#[derive(Debug)]
struct ReturnPairInts {
pub return_loc: MemArea,
}
impl ReturnPairInts {
pub fn strat() -> BoxedStrategy<Self> {
HostMemory::mem_area_strat(8)
.prop_map(|return_loc| ReturnPairInts { return_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();
let err = records::return_pair_ints(&ctx, &host_memory, self.return_loc.ptr as i32);
4 years ago
assert_eq!(err, Ok(types::Errno::Ok as i32), "return struct 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 return_struct: types::PairInts = host_memory
.ptr(self.return_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("return ref");
assert_eq!(
return_struct,
types::PairInts {
first: 10,
second: 20
},
"return_pair_ints return value"
);
}
}
proptest! {
#[test]
fn return_pair_ints(e in ReturnPairInts::strat()) {
e.test();
}
}
#[derive(Debug)]
struct ReturnPairPtrsExercise {
input_first: i32,
input_second: i32,
input_first_loc: MemArea,
input_second_loc: MemArea,
return_loc: MemArea,
}
impl ReturnPairPtrsExercise {
pub fn strat() -> BoxedStrategy<Self> {
(
prop::num::i32::ANY,
prop::num::i32::ANY,
HostMemory::mem_area_strat(4),
HostMemory::mem_area_strat(4),
HostMemory::mem_area_strat(8),
)
.prop_map(
|(input_first, input_second, input_first_loc, input_second_loc, return_loc)| {
ReturnPairPtrsExercise {
input_first,
input_second,
input_first_loc,
input_second_loc,
return_loc,
}
},
)
.prop_filter("non-overlapping pointers", |e| {
MemArea::non_overlapping_set(&[e.input_first_loc, e.input_second_loc, e.return_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();
host_memory
.ptr(self.input_first_loc.ptr)
.write(self.input_first)
.expect("input_first ref");
host_memory
.ptr(self.input_second_loc.ptr)
.write(self.input_second)
.expect("input_second ref");
let res = records::return_pair_of_ptrs(
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.input_first_loc.ptr as i32,
self.input_second_loc.ptr as i32,
self.return_loc.ptr as i32,
);
Fixes #2418: Enhance wiggle to generate its UserErrorConverstion trait with a function that returns Result&lt;abi_err, String&gt; (#2419) * Enhance wiggle to generate its UserErrorConverstion trait with a function that returns a Result&lt;abi_err, String&gt;. This enhancement allows hostcall implementations using wiggle to return an actionable error to the instance (the abi_err) or to terminate the instance using the String as fatal error information. * Enhance wiggle to generate its UserErrorConverstion trait with a function that returns a Result&lt;abi_err, String&gt;. This enhancement allows hostcall implementations using wiggle to return an actionable error to the instance (the abi_err) or to terminate the instance using the String as fatal error information. * Enhance the wiggle/wasmtime integration to leverage new work in ab7e9c6. Hostcall implementations generated by wiggle now return an Result&lt;abi_error, Trap&gt;. As a result, hostcalls experiencing fatal errors may trap, thereby terminating the wasmtime instance. This enhancement has been performed for both wasi snapshot1 and wasi snapshot0. * Update wasi-nn crate to reflect enhancement in issue #2418. * Update wiggle test-helpers for wiggle enhancement made in issue #2418. * Address PR feedback; omit verbose return statement. * Address PR feedback; manually format within a proc macro. * Address PR feedback; manually format proc macro. * Restore return statements to wasi.rs. * Restore return statements in funcs.rs. * Address PR feedback; omit TODO and fix formatting. * Ok-wrap error type in assert statement.
4 years ago
assert_eq!(
res,
4 years ago
Ok(types::Errno::Ok as i32),
Fixes #2418: Enhance wiggle to generate its UserErrorConverstion trait with a function that returns Result&lt;abi_err, String&gt; (#2419) * Enhance wiggle to generate its UserErrorConverstion trait with a function that returns a Result&lt;abi_err, String&gt;. This enhancement allows hostcall implementations using wiggle to return an actionable error to the instance (the abi_err) or to terminate the instance using the String as fatal error information. * Enhance wiggle to generate its UserErrorConverstion trait with a function that returns a Result&lt;abi_err, String&gt;. This enhancement allows hostcall implementations using wiggle to return an actionable error to the instance (the abi_err) or to terminate the instance using the String as fatal error information. * Enhance the wiggle/wasmtime integration to leverage new work in ab7e9c6. Hostcall implementations generated by wiggle now return an Result&lt;abi_error, Trap&gt;. As a result, hostcalls experiencing fatal errors may trap, thereby terminating the wasmtime instance. This enhancement has been performed for both wasi snapshot1 and wasi snapshot0. * Update wasi-nn crate to reflect enhancement in issue #2418. * Update wiggle test-helpers for wiggle enhancement made in issue #2418. * Address PR feedback; omit verbose return statement. * Address PR feedback; manually format within a proc macro. * Address PR feedback; manually format proc macro. * Restore return statements to wasi.rs. * Restore return statements in funcs.rs. * Address PR feedback; omit TODO and fix formatting. * Ok-wrap error type in assert statement.
4 years ago
"return pair of ptrs errno"
);
5 years ago
let ptr_pair_int_ptrs: types::PairIntPtrs<'_> = host_memory
.ptr(self.return_loc.ptr)
.read()
.expect("failed to read return location");
let ret_first_ptr = ptr_pair_int_ptrs.first;
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 ret_second_ptr = ptr_pair_int_ptrs.second;
assert_eq!(
self.input_first,
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
ret_first_ptr
.read()
.expect("deref extracted ptr to first element")
);
assert_eq!(
self.input_second,
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
ret_second_ptr
.read()
.expect("deref extracted ptr to second element")
);
}
}
proptest! {
#[test]
fn return_pair_of_ptrs(e in ReturnPairPtrsExercise::strat()) {
e.test()
}
}
#[derive(Debug)]
struct SumArrayExercise {
inputs: Vec<u8>,
input_array_loc: MemArea,
input_struct_loc: MemArea,
output_loc: MemArea,
}
impl SumArrayExercise {
pub fn strat() -> BoxedStrategy<Self> {
(0..256u32)
.prop_flat_map(|len| {
let len_usize = len as usize;
(
prop::collection::vec(prop::num::u8::ANY, len_usize..=len_usize),
HostMemory::mem_area_strat(8), // Input struct is 8 bytes - ptr and len
HostMemory::mem_area_strat(4), // Output is 4 bytes - stores a u16, but abi requires 4 byte alignment
)
})
.prop_filter(
"non-overlapping input struct and output pointers",
|(_inputs, input_struct_loc, output_loc)| {
MemArea::non_overlapping_set(&[input_struct_loc.clone(), output_loc.clone()])
},
)
.prop_flat_map(|(inputs, input_struct_loc, output_loc)| {
(
Just(inputs.clone()),
HostMemory::byte_slice_strat(
inputs.len() as u32,
1,
&MemAreas::from([input_struct_loc, output_loc]),
),
Just(input_struct_loc.clone()),
Just(output_loc.clone()),
)
})
.prop_map(
|(inputs, input_array_loc, input_struct_loc, output_loc)| SumArrayExercise {
inputs,
input_array_loc,
input_struct_loc,
output_loc,
},
)
.boxed()
}
pub fn test(&self) {
let ctx = WasiCtx::new();
let host_memory = HostMemory::new();
// Write inputs to memory as an array
for (ix, val) in self.inputs.iter().enumerate() {
let ix = ix as u32;
host_memory
.ptr(self.input_array_loc.ptr + ix)
.write(*val)
.expect("write val to array memory");
}
// Write struct that contains the array
host_memory
.ptr(self.input_struct_loc.ptr)
.write(self.input_array_loc.ptr)
.expect("write ptr to struct memory");
host_memory
.ptr(self.input_struct_loc.ptr + 4)
.write(self.inputs.len() as u32)
.expect("write len to struct memory");
// Call wiggle-generated func
let res = records::sum_array(
&ctx,
&host_memory,
self.input_struct_loc.ptr as i32,
self.output_loc.ptr as i32,
);
// should be no error - if hostcall did a GuestError it should eprintln it.
4 years ago
assert_eq!(res, Ok(types::Errno::Ok as i32), "reduce excuses errno");
// Sum is inputs upcasted to u16
let expected: u16 = self.inputs.iter().map(|v| *v as u16).sum();
// Wiggle stored output value in memory as u16
let given: u16 = host_memory
.ptr(self.output_loc.ptr)
.read()
.expect("deref ptr to returned value");
// Assert the two calculations match
assert_eq!(expected, given, "sum_array return val");
}
}
proptest! {
#[test]
fn sum_of_array(e in SumArrayExercise::strat()) {
e.test()
}
}