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
* atomic read for unmap
* send and recv
* switching to Atomics
* atomics
* bring back compiler_fence (maybe needed for signals?)
* only acquire mem if new msg is available
* unused compiler fence
* caching for msg ids to not have to read atomics as much
* fix build
* speed++
* only in a spinloop for the second try
* cleanup logs
* docu, error log
* documentation, warnings
* fixed docs
* docs
* no_std
* test
* windows
* nautilus docs
* more fixes
* more docs
* nits
* windows clippy
* docs, windows
* nits
* debug all the things
* derive debug for all core library components
* Docu for libafl_targets
* nits
* reordered generics
* add docs to frida, debug
* nits
* fixes
* more docu for frida, nits
* more docu
* more docu
* Sugar docs
* debug for qemu
* more debug
* import debug
* fmt
* debug
* anyap_debug feature no longer needed
* tidy up unused fn
* indicate if we left out values for struct debug
* implement Debug for sugar
* debug allthethings
* ci
`libqasan/libqasan.so` never exists during a normal `cargo build` because the .so is built in the target_dir, not in the source directory. This was triggering cargo to rerun the build script every time a user of this library made an incremental change to their code.
pointing `rerun-if-changed` to a directory will make cargo rerun build.rs if any file in that directory changes.
