Expand description
Kernel-mediated reads of the module’s own loaded image.
§Why this crate exists at all
oxicrypt-integrity keeps #![forbid(unsafe_code)], because the
failure mode of a raw pointer read, in the crate whose whole job is
integrity, is the one failure mode worth spending effort to avoid.
On Linux and Android it can hold that line completely: the loaded
image is readable through /proc/self/mem or through the backing
file, so every acquisition is an ordinary positioned file read and a
wrong offset produces a short read rather than undefined behaviour.
Darwin and Windows offer no file-shaped route to a process’s own
memory. Reading the image there needs a system call, and a system
call needs an extern declaration — so the declarations live here,
in a crate that does nothing else, rather than eroding the guarantee
in the crate that performs the test.
§Why a system call rather than a pointer read
Both mechanisms below are kernel-mediated copies, and that is the
point of choosing them. The addresses this crate is asked to read
come from a range table inside the artifact; a corrupt or hostile
table can name an address that is not mapped. Dereferencing it would
fault and take the process down — a denial of service triggered by
exactly the malformed input the integrity test exists to detect.
mach_vm_read_overwrite and ReadProcessMemory return a status
instead, so an unreadable range becomes an error return and the
module enters its error state, which is the required outcome.
The unsafe here is therefore confined to calling two documented
system interfaces with a buffer this crate owns. It performs no
pointer arithmetic on the addresses it is given, parses no executable
format, and never dereferences them.
Enums§
- Read
Error - Why a self-image read did not complete.