librasan: Simplify assembly patches

[wfdewith]

Description

@domenukk as per your comment in #3176, I've simplified the assembly patches a bit to remove the Vec usage. The rustfmt::skip attributes are there to keep lines matching with the assembly code in the comments.

Checklist

• I have run ./scripts/precommit.sh and addressed all comments

[WorksButNotTested]

Nice. Let's land this.

[domenukk]

Random question @WorksButNotTested can't we also do dynasm here like we do in libafl_frida?

LibAFL/libafl_frida/src/cmplog_rt.rs

Line 198 in d3ddc8e

fn generate_instrumentation_blobs(&mut self) {

Would be more maintable than pasting random bytes, right?

[wfdewith]

That's pretty nice actually, but dynasm doesn't support ARMv7 and PowerPC. We can migrate the supported architectures if you'd like.

[WorksButNotTested]

Yeah. Nobody loves powerpc! Just went with it as it was the lowest common denominator. Happy if you want to port the others though.

[wfdewith]

I've added dynasm for the architectures that it supports.

[wfdewith]

Actually, scratch that, dynasm requires std, so we cannot use it, unfortunately.

[WorksButNotTested]

Oh weird. You'd think it would so all its work at compile time! Some crates only support nostd with the default features disabled, does that help at all?

[wfdewith]

Dynasm needs some synchronization primitives for the Assembler that also manages mmap-ing memory with the correct permissions etc, when you use it for building JIT compilers. In theory, it could have a no_std subset with the VecAssembler (which just assembles into a Vec) that this PR uses. However, even just VecAssembler would also need some alternative HashMap implementation for no_std environments. So no, at the moment there is no no_std feature, and it's not entirely trivial to add.

[WorksButNotTested]

BTreeMap is part of core and is a good substitute for HashMap for most usages. That could be an option?

[wfdewith]

There is an open PR already: CensoredUsername/dynasm-rs#105.

[domenukk]

It's been idle for quite a while though, sadly. Let's see if they react to the latest comments :)

[WorksButNotTested]

There's no alternative crates we can use are there?

[wfdewith]

There's no alternative crates we can use are there?

In my opinion, if that nostd PR in dynasm doesn't land soon, we should just revert to using the raw bytes, because I expect very little churn in these assembly trampolines. I don't expect dynasm to start supporting new architectures anytime soon, considering the fair amount of complexity in a full fledged assembler, so we need a fallback anyway.

[domenukk]

Yes let's ignore the move to dynasm for now and maybe keep an eye on their no_std support.
It'll be more maintainable going forward, but there is no reason it should block our PR right now

[domenukk]

We could hack together something that emits the right bytes at compile time (build.rs or our own proc macro) and uses a different assembler (or even dynasm) if we wanted

[wfdewith]

We could hack together something that emits the right bytes at compile time (build.rs or our own proc macro) and uses a different assembler (or even dynasm) if we wanted

We could, 'easiest' way would probably to use the correct as and objcopy for each architecture. Unfortunately, the cc crate only exposes the C/C++ compilers and ar and ranlib, but not as and objcopy. Detecting the correct version to use is not easy to solve.

I still feel that this would be enormous overkill for quite literally 8 to 16 bytes of assembly per target architecture.

[WorksButNotTested]

I think the C compiler should detect a .S file as assembly and compile accordingly? As you say though, could be overkill.

[wfdewith]

I think the C compiler should detect a .S file as assembly and compile accordingly? As you say though, could be overkill.

True, but that still leaves objcopy.