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.

[hainest]

I'm going to necro this thread because I think it's very important for Capstone to make substantial improvements to the x86 decoder that are huge obstacles to overcome using the current LLVM tablegen importer.

I am currently porting the instruction decoder for Dyninst to improve our support for x86 (it's internal decoder is already far behind what Capstone can do). Dyninst is used by RHEL's SystemTap utility, so it's installed on a few machines (/sarcasm). We are also a core component of several HPC performance analysis tools (e.g., HPCToolkit) which requires supporting a wide variety of architectures simultaneously. Currently, we support x86, x86_64, ARMv8, ARMv9, ppc64le, and AMDGPU. We are also one of only two teams working on binary instrumentation for AMD GPUs and are planning to upstream our decoder into Capstone. That would make Capstone the only AMD GPU decoder around outside of AMD's SDK. That's a huge win for FOSS since NVIDIA won't open-source their ISA and gtPIN (for Intel XE) isn't the easiest thing to use. Currently, we are also the only group working on binary instrumentation for RISC-V for which we use Capstone.

What does all of this chest-thumping mean? The Dyninst team doesn't have the ability to fix it's x86 decoder and still provide other features. This is exactly Capstone's situation. I'm not waxing philosophical here.

Interestingly, right about the time of this thread Wine announced they are now using Capstone for their decoding. That's huge, and really emphasizes the need for expanding x86 support.

---

My thoughts on the items discussed in this thread so far:

If you want x86, just use Zydis instead of Capstone.

I strongly considered using xed for x86 and Capstone for everything else in Dyninst. I chose xed because we could also use it to upgrade our x86 binary rewriting capabilities. I, like many others here, don't want to add more dependencies than are necessary, so I really don't want to do this. Are we honestly considering forcing users like Wine to switch to Zydis? I think that's a good way for Capstone to fade into uselessness.

Adding Zydis as a dependency to Capstone is too big a burden on users.

It was mentioned that C and C++ have no standardized ecosystem for package management. Indeed, there is a veritable zoo of package managers centered on C++ (but support many languages). I'm the maintainer of the Boost spack package, so I know how much work it can be to keep those recipes updated. That said, offering Capstone through PMs like conan and vcpkg drastically increases the surface area for new users and decreases the friction of getting them onboard. I definitely want to do this for Dyninst so users have an even easier time handling our dependencies.

I think pasting in Zydis via their amalgamated distribution and then doing separate Capstone tarballs with and without deps is a good balance for the reasons described here. If it works for the Firefox folks, I see no reason it shouldn't work well for Capstone. I think Capstone should also offer recipes for package managers like I discussed above.

Indirection through Zydis adds overhead to Capstone (ref).

I absolutely agree this is something we must be diligent about. Zydis does not dynamically allocate memory (ref), but Capstone's current implementation for x86 uses at least one. This could be seen as an improvement, so long as it could be measured.

Capstone uses a "two-phase" process in which it decodes in the backend and then copies data into the front end (e.g., X86_get_insn_id). I see no difference between this and copying the data from Zydis' data structures- assuming Zydis does not also do a two-phase process.

There is an impedance mismatch between Capstone and Zydis that will make development of Capstone harder (ref)

I want to address each of Ben's points in turn.

making sure it returns the exact thing that Capstone normally would for other architectures

Perhaps I've not fully understood the idea, but Capstone's current interface isn't uniform across all architectures, and I'm not sure how it could be made to be so. In fact, there need to be at least a few big changes to Capstone's current x86 interface. For example, there is no representation for implicit memory operands like those in x86 call instructions (I have an upcoming issue and PR about this). There also needs to be an ABI break in cs_x86 to correctly represent eflags and fpu flags (see #2680).

patching/contributing to Zydis to fix things that don't mesh well with Capstone, and then maintaining all of that separately from Zydis.

I will withold comment until such items have been shown to exist.

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.

As I noted above, I agree with many folks here that one dependency is better than N (N >= 2).

Narrow the choices that users have for x86-supporting disassemblers even further.

I am a massive fan of FOSS and having choices in what software I want to use. In this case, I will push back slightly because Dyninst can be used as an x86 disassembler, but no one should because it is very incomplete. I want to replace it with something better, thus reducing the number of decoders by one. I see the same with Capstone. Users still have large projects like xed, bddisasm, Ghidra, and IDA Pro. The ecosystem for other architectures is microscopic in relation to x86. For example, I'm only aware of four decoders for ppc64le: Dyninst, binutils, llvm-objdump, and Capstone. I intend to replace Dyninst's with Capstone's.

[Rot127]

We keep the discussion open for a little longer until the Beta is released (hopefully around November).

Then make an overview table of pro's and con's and ask the biggest Capstone projects for their vote.
Then make a decision. If we switch it would be included in the v6 Gold release.

[jxors]

What is the current status on this? I have some improvements to the x86 instruction decoding in mind, but it would not be worth working on if the module will soon be replaced.

[Rot127]

I don't think it will soon be replaced.
I am pretty busy currently, but my plan is (still) to apply for funding for Capstone. If we get some we can work on that one.
Although there are other things I would like to finance with this theoretical money as well.
Like a proper DIET build with picolibc. Or a bindings generator for more languages, better fuzzing, running Capstone on the stack only...
So in general I don't think this will be worked on for at least a year.