Replace x86 module with Zydis

[Rot127]

We had the idea to exchange the current x86 module with the Zydis disassembler.

Mainly because it is unlikely we will be able to update x86, because it has such a unique place in the LLVM world. So we can't use our Auto-Sync updater for it currently (See: capstone-engine/llvm-capstone#13).

The details are already describe in #2503. See below

Copy of relevant messages

Rot127

Copy from my message from Rizin's Mattermost:

I would strongly advise against using LLVM for x86. The table generation for the decoders is a completely different tool. Also the scripts you mentioned there are massively outdated. We use the Auto-Sync updater now (see #2015). But x86 is time consuming to add and will probably have a lot of corner cases to fix.

For x86, I had the idea to use the Zydis disassembler in Capstone. Basically integrating it and write code to translate from their API to the Capstone one. Zydis is, to my knowledge, the gold standard for (open source) x86 disassemblers. It will be hard to get to their level I think. Because x86 is so so complicated.

I had no time yet to look into it. But if you have time I would very much welcome your effort! It also will be way easier faster and easier to do then the LLVM way I think. So you would get a very decent result relatively quickly.

The most important thing is, to check license compatibility. I think Zydis is MIT? It should be compatible with Capstones BSD-3.

After the license question is answered I think a route like this is sensible:

* Let the Zydis people know about it, ask for hints and advise.

* Implementation:
  
  * Check for conflicts between Zydis API and Capstone API (e.g. does zyids has the concept of a memory operand just as Capstone has).
  * I think certain API breaking is acceptable with such a big improvement. But all API changes to the x86  module should be justifiable. Meaning: "Why can't we do it this or that way", "is the advantage changing the API bigger then keeping the old one? Why?"
  * Add Zydis as an external projects in the cmake files.
  * Write a script which generates a Capstone header file from the Zydis header. And run from cmake.
  * Implement the binding code Capstone <-> Zydis.
  * Write a script which copies Zydis tests to Capstone tests. This is very important. Because Capstone should in the end be at least as correct as Zydis.

athre0z

Let the Zydis people know about it, ask for hints and advise.

Hello! @flobernd and I are both rather busy right now, but I suspect that we'd both be happy to assist in an advisory role by answering questions where they come up if you do decide to go that route. :)

One thing to keep in mind is that libraries with dependencies tend to be a PITA to deal with in C. I think currently Capstone only depends on libc, and your users may not appreciate if you add deps. We also learned this the hard way with Zycore. I'd love to see this happening, but it'd be dishonest to not point that out.

[Rot127]

@athre0z @flobernd This is really nice to hear!

Don't worry about assistance. Also I agree that dependencies are potentially a problem. Thanks for pointing this out again.

What were the main complaints from users about the dependencies, if I might ask?

Because there is neither time nor enough maintainers currently to do this anyways. I would let this idea sit here for a while. And get more feedback or someone who is motivated.

We have so many open issues about out dated x86, I think it would be worth the pain. Especially, since Zydis is faster and smaller than the x86 module (at least the one time I checked it casually). So users would get quite a lot for the annoyance of a dependency.

In our case users who don't need x86, can disable the module completely. And don't deal with it at all if they don't want to.

[athre0z]

What were the main complaints from users about the dependencies, if I might ask?

To this day there isn't really a single dominant package manager for C/C++. I know that a lot of our users, especially those that spin up a project quickly, just paste Zydis into their own project. Even projects like Firefox paste Zydis into their repo and flatten Zycore and Zydis into a single dep instead of pulling it from package manager. Having a separate submodule for Zycore is among the more commonly mentioned friction points with adopting Zydis. I don't think that it's prohibitive to many users, but it does cause some extra work.

[Rot127]

As a note: Additionally to the normal source archive, we could provide a source archive which contains a copy of the Zydis code. So people don't need to fetch the Zydis source when they build Capstone.
Something like: capstone-X.Y.Z.tar.xz and capstone-no-src-dep-X.Y.Z.tar.xz

[athre0z]

Yeah, that could be a decent way to approach this. Having both variants (one with and one without third-party deps) is probably the best option here: distro maintainers etc will not like bundled dependencies, but the Windows users will appreciate it. This way you make both of them happy.

We offer an amalgamated distribution of Zydis that you could easily wget and drop into your archive for this purpose.

[ZehMatt]

What benefit is there to have Zydis in Capstone for x86 when the user could just use Zydis? Capstone would also make things slower due to copying the data and most likely allocating memory, so that is a downside. I know it sounds nice to have all sorts of architectures in theory but in practice all those architectures typically don't have a lot in common and no one really needs all those architectures at the same time.

[Rot127]

There are projects which use a lot of the architecture modules. E.g. Rizin, Radare2, Qemu (can't say how many though) and probably way more. It is convenient, because you only need to manage a single dependency and the APIs of all modules are pretty similar.
It makes Capstone suitable for automate analysis of binary files or large scale disassembly.

The allocating memory step is indeed a downside of Capstone and takes away this specific advantage of Zydis. We would need to address this with the v2 API.
Though even with this, Zydis is still faster and smaller than the current x86 module.

Also, tools which already use Capstone don't need to refactor to use the Zydis API.

Dropping x86 all together was also in discussion once. Because it gets just more and more outdated and bugs stay unfixed because we focus on the other modules first.
@aquynh was specifically against it though and we kinda dropped the discussion at this point.

[Rot127]

Also, the basic idea of generating modules from LLVM, is by design made for this specific purpose. Supporting many different architectures in a single tool.

[matthew-olson-intel]

From a user perspective (https://github.com/intel/processwatch), it seems to me that there's not much advantage in Capstone simply calling Zydis for x86 instructions. If I want to call Zydis, I simply would! It's a very easy dependency to build and use; in fact, my project did use it as a submodule for quite some time before I wanted to support ARM, and since Capstone doesn't support later x86 instructions, I'll re-add it back to my repo (but obviously use Capstone for ARM and potentially other architectures).

The way I see it, Capstone calling Zydis would:

1. Add complexity. Figuring out exactly how to call Zydis from Capstone for each API call, making sure it returns the exact thing that Capstone normally would for other architectures, patching/contributing to Zydis to fix things that don't mesh well with Capstone, and then maintaining all of that separately from Zydis.
2. Not add much of an advantage. Both Capstone and Zydis are quite easy to just call! It's even easier because, if I want to support ARM, I can switch between Capstone/Zydis at compile time. No need to build/link both at the same time.
3. Narrow the choices that users have for x86-supporting disassemblers even further.

[disconnect3d]

Hi, we use Capstone in Pwndbg. I think we don't mind if Capstone switches to Zydis as long as the Capstone API stays the same. And by that, I also mean all the various detailed information that Capstone provides about instructions (instruction group, operands, read/write accesses etc) as we leverage that information heavily.

[nblog]

I agree, after all capstone is not going to put a lot of effort into x86, it should be left to the professional zydis, and we just need to tell people that it is generated by zydis, and when a more specialized use is needed, there is the option of linking directly to zydis, but most people are probably more likely to need more than one architecture and be assured that the APIs are the same, then capstone would be a better choice.