totally_safe_transmute, Line-by-Line (2021)
blog.yossarian.net
totally_safe_transmute, Line-by-Line (2021)
1–10 of 41 posts
Re: totally_safe_transmute, Line-by-Line (2021)
#2This is cute, but I hope it never turns up in any real codebase!
There’s an updated version with Windows support and better performance: https://github.com/John2143/totally-speedy-transmute/
What worries me is this macro, which “smuggles” the unsafe keyword past the forbid(unsafe_code) flag: https://github.com/John2143/totally-speedy-transmute/blob/ma...
In my mind, this kind of capability makes Rust crate safety scanning and associated metadata worthless as currently implemented.
Package management tools ought to store code instead of binaries, and perform safety checks to via instrumented compilers.
Re: totally_safe_transmute, Line-by-Line (2021)
#3I appreciate that "totally_safe_transmute" carries some connotation that this is not a "safe" transmute, but rather a suspiciously specific denial.
Re: totally_safe_transmute, Line-by-Line (2021)
#4Why don't the safe file I/O operations panic when /proc/self/mem is opened for writing?
I understand why they don't want to make all of File I/O unsafe just for edge cases like this, but shouldn't this be handled at runtime?
Re: totally_safe_transmute, Line-by-Line (2021)
#5This is cute, but I hope it never turns up in any real codebase! There’s an updated version with Windows support and better performance: https://github.com/John2143/totally-speedy-transmute/ What worries me is this macro, which “smuggles” the unsafe keyword past the forbid(unsafe_code) flag: https://github.com/John2143/totally-speedy-transmute/blob/ma... In my mind, this kind of capability makes Rust crate safety sca…
> In my mind, this kind of capability makes Rust crate safety scanning and associated metadata worthless as currently implemented.
If you wanted to backdoor a Rust program, you wouldn't need the `unsafe` keyword at all. And if you want to use unsafe code, that's fine, plenty of crates use unsafe code without anyone being up in arms about it (e.g. the regex crate). This is a party trick rather than something to be concerned about; at the end of the day either you're auditing your dependencies (in which case this would stick out like a sore thumb) or you're not (in which case there are far easier ways to pwn you).
Re: totally_safe_transmute, Line-by-Line (2021)
#6This is cute, but I hope it never turns up in any real codebase! There’s an updated version with Windows support and better performance: https://github.com/John2143/totally-speedy-transmute/ What worries me is this macro, which “smuggles” the unsafe keyword past the forbid(unsafe_code) flag: https://github.com/John2143/totally-speedy-transmute/blob/ma... In my mind, this kind of capability makes Rust crate safety sca…
You can always smuggle unsafe past the compiler, it can't stop you even in principle.
The totally safe transmute is at runtime, so an instrumented compiler cannot detect it (halting problem is in the way). You'd need runtime instrumentation of your binary. And even then, it's wildly impractical.
If you let an application interact with the environment, tomorrow Linux or Windows could add a new magic file, or a special COM call, or whatever it is that creates unsafe. Rust can't have a complete list of all the unsafe things that are outside of its control.
What you probably want is a runtime VM, like WASM.
Re: totally_safe_transmute, Line-by-Line (2021)
#7Why don't the safe file I/O operations panic when /proc/self/mem is opened for writing? I understand why they don't want to make all of File I/O unsafe just for edge cases like this, but shouldn't this be handled at runtime?
It's hard to do by accident and is pretty unix specific. Also, what if you really want do access this and it panics?
Re: totally_safe_transmute, Line-by-Line (2021)
#8Why don't the safe file I/O operations panic when /proc/self/mem is opened for writing? I understand why they don't want to make all of File I/O unsafe just for edge cases like this, but shouldn't this be handled at runtime?
I've considered proposing this before, but presumably it's a cat and mouse game. Can the Rust stdlib reliably detect writes to /proc/mem in the face of links and raw FDs? And it probably should be reliable, because nobody writes to /proc/mem by accident.
And even then, it doesn't help with whole-system security when every program in every other language on your system, including safe ones like Java and Python, have the same capability. (Although if I'm wrong that there's no precedence for languages attempting to block this, I'd love to see the prior art.)
Re: totally_safe_transmute, Line-by-Line (2021)
#9C doesn't provide any reinterpretation operator, and the C++ one's name is a misnomer.
Casts are conversion: a new value is produced based on an existing one.
Reinterpretation requires a value to be in memory, and to be accessed using an lvalue of a different type. Most situations of this kind are undefined behavior.
Re: totally_safe_transmute, Line-by-Line (2021)
#10Why don't the safe file I/O operations panic when /proc/self/mem is opened for writing? I understand why they don't want to make all of File I/O unsafe just for edge cases like this, but shouldn't this be handled at runtime?
I've considered proposing this before, but presumably it's a cat and mouse game. Can the Rust stdlib reliably detect writes to /proc/mem in the face of links and raw FDs? And it probably should be reliable, because nobody writes to /proc/mem by accident. And even then, it doesn't help with whole-system security when every program in every other language on your system, including safe ones like Java and Python, have t…
It’s not just /proc/sys/mem. One could also modify executable files and cause all manner of other mayhem. At the end of they, if you have access to all ambient privileges available to your process, you can use them. Trying to specifically block memory safety violations would be a bit odd.