Guest addresses now represented by correct sized integers.
Previously u64 was used to represent guest addresses. This is great for
64-bit targets, but clunky for other architectures. This introduces a
GuestAddr type alias that is defined based on the selected emulation
architecture.
Note: This changes only the user-facing Rust interface. Before
traversing the FFI boundary, all GuestAddrs are sized back to u64.
Another Note: Guest addresses _from_ the FFI boundary are completely
trusted. Values that are too large are truncated to fit into a GuestAddr
using the `as GuestAddr` cast. This may not be ideal, as errors could be
masked. If desired and the performance is ok, a non-breaking update
could change all `as` casts to `.try_into().unwrap()` so that critical
failures in FFI are always checked.
Methods read_mem and write_mem now operate on &[u8], not &[T]
The generic T slice interface was prone to various footguns:
* i32 is the default Rust integer type, but buffers are often expected
to hold u8. This means the following code writes 16 bytes to the
guest, not 4:
let buf = [0; 4];
emu.write_mem(addr, &buf);
* If a buffer of 16-bit or larger integers (&[u64] for example) is
needed to read/write, the user will need to consider host/guest
endianness. The byte array methods in std are a good, explicit
alternative.
Perhaps libafl_qemu could expose/define "to/from guest endianness"
helper functions or extension traits using the established cfg flags,
so that guest endianness is always right by default.
* emu::read_mem causes insta-UB if a user did something like:
let mut my_bool = false;
emu.read_mem(addr, &mut my_bool);
It's less surprising for users to just operate on plain-ol' bytes,
which they can explicitly transmute if they wish.
The `debug_child` command line argument presence was not properly checked,
so it couldn't be set to true. Hence it was not possible to print out
the content of the buffer sent to the harness while fuzzing.
* first working version
* full gui
* remove warnings
* remove errors in release
* allow missing_docs in tui
* tui_monitor flag
* working graphs
* disable tui on windows
* clippy
* clippy
* tui module only under std
* use tui from git
* fmt
* tui from crates
* Optional signal value to kill forked processes on timeout
* Cargo format
* Properly initialize TimeoutForkserverExecutor
* Added with_signal constructor
* Removed duplicate code
Specifically for Has{Rand,Corpus,Solutions,FeedbackStates}
The Has* family of traits offer getters and get-mut-ers. The previous
implementation had a fully generic return type:
trait HasX<X: TraitX> {
get_x(&self) -> &Self::X;
get_mut_x(&mut self) -> &mut Self::X;
}
meaning a single type could implement both `HasRand<Romu>` and
`HasRand<XorShift>`. The advantage of having multiple implementations is
not clear at this time, so it vastly simplifies the trait (and its
impls) to bring the return type in the body as an associated type:
trait HasX {
type X: TraitX;
get_x(&self) -> &Self::X;
get_mut_x(&mut self) -> &mut Self::X;
}
This comes with the limitation that any type that impls these traits can
only do so once, choosing only one associated type.
* HasRand's only generic parameter (Rand) is now an associated type
* HasCorpus and HasSolutions are now only generic over the Input type
they store
* HasFeedbackStates generic parameter now associated type