Documentation for the master branch
A dirty hack to support deserialization of arbitrary trait objects.
This is a proof-of-concept created in response to rust-lang/rfcs#668 as well as Dmitry Gordon's question How can deserialization of polymorphic trait objects be added in Rust if at all? (related Rust Forum post).
Deserialization may cause arbitrary code execution. The library has some sanity checks to make it hard to accidentally screw up, but there's no guarantee that this library is safe against a malicious attacker.
Even for trusted data, deserializing may cause undefined behavior on platforms and configurations that violate any of the following assumptions:
- The data being deserialized was originally serialized by the exact same executable built under identical conditions (architecture, optimization levels, other compiler flags, etc)
- All vtables are mapped to a single contiguous block of memory, located at fixed positions relative to each other (same for every execution)
- Trait objects have the layout
{ data: *mut _, vtable: *mut _ } - Vtables have the layout
{ destructor: fn(_), size: usize, alignment: usize, ... } - A POSIX system with either
/dev/randomor/dev/null(it shouldn't be too hard to port this to other platforms) - 64-bit pointers (not entirely necessary, but 32-bit pointers would make it easier to exploit)
If Rust adds support for #[repr(align = "N")], it may be possible to use a custom alignment as a secondary sanity check.