Open Speykious opened 4 months ago
Miri is too strong. Even without any
unsafe
blocks, it detects problems.
Well, at least we always have the alternative possibility to port this from using transmute shenanigans to using std::fs
to write/read to /proc/self/mem
: https://github.com/rust-lang/rust/issues/32670
Miri is too strong. Even without any
unsafe
blocks, it detects problems.Well, at least we always have the alternative possibility to port this from using transmute shenanigans to using
std::fs
to write/read to/proc/self/mem
: https://github.com/rust-lang/rust/issues/32670
This is a bad approach as this will cause this project to be platform specific. The aim of the project is to give a platform agnostic/cross platform solution for safe vulnerabilities in your projects.
Miri is too strong. Even without any
unsafe
blocks, it detects problems.Well, at least we always have the alternative possibility to port this from using transmute shenanigans to using
std::fs
to write/read to/proc/self/mem
: rust-lang/rust#32670
Even if you were to do this, this is actually an unsafe operation at its core, there's no safety guarantees behind calling into operating system code and the underlying functionality for it is all implemented with unsafe, thus meaning that it's not 100% safe code either.
there's no safety guarantees behind calling into operating system code and the underlying functionality for it is all implemented with unsafe, thus meaning that it's not 100% safe code either.
Yes, it is safe, as it is using Rust's std::fs
API without using the unsafe
keyword once, meaning it enjoys:
there's no safety guarantees behind calling into operating system code and the underlying functionality for it is all implemented with unsafe, thus meaning that it's not 100% safe code either.
Yes, it is safe, as it is using Rust's
std::fs
API without using theunsafe
keyword once, meaning it enjoys:
- zero-cost abstractions
- move semantics
- guaranteed memory safety
- threads without data races
- trait-based generics
- pattern matching
- type inference
- minimal runtime
- efficient C bindings
No, this isn't the case. I advise you to look at your target's underlying filesystem implementation. The underlying standard library code cannot access your system's filesystem without making a syscall, which is unsafe. You aren't truly bypassing Rust's safety checks by just calling into code with underlying unsafety. Rust's safety model doesn't guarantee that your operating system will be free of bugs or ways to break memory safety, it guarantees safety within exclusively Rust code interacting with itself. You can check your target's filesystem implementation to see for yourself how they implement it, here's how it's done on Linux:
impl FileDesc {
pub fn read(&self, buf: &mut [u8]) -> io::Result<usize> {
let result = cvt(unsafe { abi::read(self.fd.as_raw_fd(), buf.as_mut_ptr(), buf.len()) })?;
Ok(result as usize)
}
pub fn read_to_end(&self, buf: &mut Vec<u8>) -> io::Result<usize> {
let mut me = self;
(&mut me).read_to_end(buf)
}
pub fn write(&self, buf: &[u8]) -> io::Result<usize> {
let result = cvt(unsafe { abi::write(self.fd.as_raw_fd(), buf.as_ptr(), buf.len()) })?;
Ok(result as usize)
}
// ...
}
Miri is too strong. Even without any
unsafe
blocks, it detects problems.Miri defeats our tests
Miri defeats our CLI