feat!: update rust bindings

[amaanq]

Note

This PR is quite large - fortunately, every commit is atomic in nature, and should be easy to review if gone in order

Problem

The current Rust bindings have a few problems:

• A lot of the FFI code is hand-written, which is error prone, and can easily become out of sync, ideally, we should auto-generate this from the C header.
• There's some unsound behavior that needs to be rectified (see 32e36c5)
• There's some missing functionality, such as TCG hooks, ARM insn sys hooks, missing methods on uc_context, and reading from ARM coprocessor registers
• There isn't a dedicated -sys crate for unsafe FFI bindings
• We could do with some clippy linting ;)

Solution

First, there were a couple of fixes I made in the C code when tying the bindings to the C code with bindgen. I noticed UC_MIPS_REG was in all caps, whereas all the other architectures have the enum name in lowercase.

Then, I introduced a -sys crate (unicorn-engine-sys), which leverages bindgen to generate a bindings file, as well as some QoL implementations.

Afterwards, I refactored the Rust bindings to use a workspace Cargo.toml, and switched to using unicorn-engine-sys in the unicorn-engine crate.

Following this, I've added some missing functionality in the Rust bindings, which I noticed was missing while I was porting the C tests:

• Reading ARM coprocessor registers
• Hooking arm64 sys instructions
• TCG hook
• Missing uc_context methods

Lastly, I fixed UB in the reg_read/write_batch methods - &[T] was being casted to *mut i32, which wasn't sound because T wasn't known to be of the same size as i32 - I changed this to instead copy the array of T into an array of i32, and constrained T to be Copy to guarantee that copying the array is cheap.

Verification

Running cargo test in the repo root works as is, and running cargo clippy shows that there's no lints to be address. Also, bindings/rust/src/sys/bindings.rs contains all the public types and constants in the corresponding C headers.

Additional Notes

I've updated the CI implementation so that publishing should work with the workspace setup. The notable changes are:

• Switching to actions-rust-lang/setup-rust-toolchain@v1 for setting up Rust, as it's actively maintained
• Using katyo/publish-crates@v2 for publishing, as it automatically handles workspaces & the order to publish crates.

Also, this is a breaking change, because I've renamed a C enum type and some Rust enum types. Since this is a large rewrite of the Rust bindings, I went ahead with including breaking changes as it made the rewrite easier, and maintaining 100% compatibility with the old, inconsistent bindings would be a lot more work.

[wtdcode]

I'm okay with break changes and the overall changes look good to me. Honestly I have a private unicorn-engine-sys crate exactly built with bindgen but lack time to polish. Thanks for your work for making everything work. I will review this asap and include it in 2.2.0 release.

[wtdcode]

I created a tiny placeholder crate: https://crates.io/crates/unicorn-engine-sys

[amaanq]

Great, I'm looking into the windows error

[amaanq]

So test_ppc32_fadd was randomly crashing on Ubuntu in CI & in Windows, yet not on macOS & my local Linux machine. I tried to dig into it, but it was quite difficult and the QEMU TCG stuff went over my head. From what I can tell, in PPC's float add implementation, it eventually calls round_canonical, and when we check the FloatClass, it's -1, thus this assertion is reached, and we crashed. When I tried to get a backtrace here, there wasn't much to go off of - the highest frame in the trace pointed to helper_fadd, and I don't see any references to this. I'm assuming calls to this are generated on the fly by TCG.

The problem in here is that for some reason, the float_status of the CPUPPCState is corrupted in certain cases (maybe it's compiler/OS dependent).

On my machine, I get:

float_status:
float_detect_tininess: 1
float_rounding_mode: 0
float_exception_flags: 0
floatx80_rounding_precision: 0
flush_to_zero: 0
flush_inputs_to_zero: 0
default_nan_mode: 0
snan_bit_is_one: 0

but on an Ubuntu machine, I get:

float_status:
float_detect_tininess: -1
float_rounding_mode: -1
float_exception_flags: 0
floatx80_rounding_precision: -1
flush_to_zero: 255
flush_inputs_to_zero: 255
default_nan_mode: 255
snan_bit_is_one: 255

If I explicitly write 0 to the PPC register FPSCR, Ubuntu then works, but Windows still crashes (and I have very little experience debugging on Windows), so I decided to ignore the test for now.

Anyway, this should be ready to go now 🙂

[wtdcode]

I can have a look at the crash and review the PR asap but expect a bit delay.

[Evian-Zhang]

Wow excellent improvement! Will the rust binding in unicornafl also be adjusted? (BTW, I don't know why that binding need to copy all codes instead of re-exporting unicorn-engine crate)

[amaanq]

Sure, I could update it after this PR's merged

[wtdcode]

I have been refactoring unicornafl to rust recently: https://github.com/AFLplusplus/unicornafl/tree/v3 and it already works as a normal persistent target, i.e. can be fuzzed with afl-fuzz without​ unicorn mode. @Evian-Zhang You can have a look if you are interested. Currently the last thing is that I need maturin to build a python bindings.

…

________________________________ From: Amaan Qureshi ***@***.***> Sent: Friday, April 4, 2025 7:57:02 AM To: unicorn-engine/unicorn ***@***.***> Cc: lazymio ***@***.***>; Comment ***@***.***> Subject: Re: [unicorn-engine/unicorn] feat!: update rust bindings (PR #2138) Sure, I could update it after this PR's merged — Reply to this email directly, view it on GitHub<#2138 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AHJULO24BPI75PEY6PEHQLT2XXDE5AVCNFSM6AAAAAB2CABBH6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDONZXGIZTKNJXHE>. You are receiving this because you commented.Message ID: ***@***.***> [amaanq]amaanq left a comment (unicorn-engine/unicorn#2138)<#2138 (comment)> Sure, I could update it after this PR's merged — Reply to this email directly, view it on GitHub<#2138 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AHJULO24BPI75PEY6PEHQLT2XXDE5AVCNFSM6AAAAAB2CABBH6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDONZXGIZTKNJXHE>. You are receiving this because you commented.Message ID: ***@***.***>

[Evian-Zhang]

OK, got it. Thank you for your great work! Wow it uses LibAFL. But someone has recently make a unicorn mode into LibAFL (I think it is maybe AFLplusplus/LibAFL#1054), what is the relationship between these two codes?

[wtdcode]

I was migrating unicornafl to unicorn_engine::ffi solely. If this PR gets merged, it will rely on unicorn-engine-sys instead. libafl_unicorn instead still uses full unicorn_engine.

For functionalities, unicornafl provides a full forkserver compatible harness while libafl_unicorn just provides a few utilities if I understand it correctly. That said, I’m also planing to migrate a few internal functions of unicornafl to libafl_unicorn for code reuse.