You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Taking rust-style references to guest memory of a running virtual
machine might violate the aliasing rules, as the guest can modify
its memory at will. Additionally, since the `read_from` and
`write_to` functions "leak" references to guest memory to code
outside of the vm-memory crate, it is possible to trigger undefined
behavior in single-threaded, safe code, for example by creating a
`Read` implementation the reads from a volatile slice:
struct VolatileSliceReader<'a> {
src: VolatileSlice<'a, ()>
}
impl<'a> Read for VolatileSliceReader<'a> {
fn read(&mut self, buf: &mut [u8]) -> io::Result<usize> {
Ok(self.src.copy_to(buf))
}
}
\#[test] // test fails under miri
fn undefined_behavior() {
let mut data = vec![0u8; 20];
let vslice = unsafe {VolatileSlice::new(data.as_mut_ptr(), 20)};
let mut reader = VolatileSliceReader {src: vslice};
vslice.read_from(0, &mut reader, 10);
}
Since this trait was marked `pub(crate)`, this is not a breaking
change.
As a consequence, the `read_from` and `write_to` functions of
`Bytes` implementations now always first copy to a buffer
allocated within the function, before transferign data from/to
the Read/Write object provided. There is no safe way to keep
the existing abstraction, as Rust does not give us a low-level
interface to Read/Write that operates with pointers.
Signed-off-by: Patrick Roy <[email protected]>
0 commit comments