It’s an amazing accomplishment, but if anybody is wondering why it’s not flat-out impossible, she very likely was snooping on how it was controlled by existing drivers, either by looking at the software side, which honestly, I’m less familiar with, or by using something like a logic analyzer, which can be used to record signals being sent to the hardware directly. So, if she did it that way, she didn’t reuse the code of the existing driver, but analyzed the output. I’ve had to debug some drivers in the past with a logic analyzer, and just that was a lot of work.
If she did it without existing drivers, then it would have been an absolute slog, I think bordering on impossible. You’d have to guess every signal. GPUs may be more specialized than CPUs, meaning that their instruction set will be smaller, but that would be insane.
lol I randomly searched for a page from collabora about how they reverse engineer GPU drivers (since I’ve seen that they’ve done that for other GPUs) and the very first page I went to was written by this person. Apparently this was a side project while she did fairly similar work on Mali GPUs at Collabora.
Anyways, here’s what she said about the process:
Typically, for Linux or Android driver reverse-engineering, a small wrap library will be written to inject into a test application via LD_PRELOAD that hooks key system calls like ioctl and mmap in order to analyze user-kernel interactions. Once the “submit command buffer” call is issued, the library can dump all (mapped) shared memory for offline analysis…
it took some elbow grease to identify the three critical calls: memory allocation, command buffer creation, and command buffer submission…
With those obstacles cleared, we can finally get to the shader binaries, black boxes in themselves. However, the process from here on out is standard: start with the simplest fragment or compute shader possible, make a small change in the input source code, and compare the output binaries. Iterating on this process is tedious but will quickly reveal key structures, including opcode numbers.
It’s an amazing accomplishment, but if anybody is wondering why it’s not flat-out impossible, she very likely was snooping on how it was controlled by existing drivers, either by looking at the software side, which honestly, I’m less familiar with, or by using something like a logic analyzer, which can be used to record signals being sent to the hardware directly. So, if she did it that way, she didn’t reuse the code of the existing driver, but analyzed the output. I’ve had to debug some drivers in the past with a logic analyzer, and just that was a lot of work.
If she did it without existing drivers, then it would have been an absolute slog, I think bordering on impossible. You’d have to guess every signal. GPUs may be more specialized than CPUs, meaning that their instruction set will be smaller, but that would be insane.
lol I randomly searched for a page from collabora about how they reverse engineer GPU drivers (since I’ve seen that they’ve done that for other GPUs) and the very first page I went to was written by this person. Apparently this was a side project while she did fairly similar work on Mali GPUs at Collabora.
Anyways, here’s what she said about the process:
From https://alyssarosenzweig.ca/blog/asahi-gpu-part-1.html , there’s a lot more details about the subsequent parts of the process in the next articles but they’re harder to summarize