marcan changed the topic of #asahi-gpu to: Asahi Linux: porting Linux to Apple Silicon macs | GPU / 3D graphics stack black-box RE and development (NO binary reversing) | Keep things on topic | GitHub: https://alx.sh/g | Wiki: https://alx.sh/w | Logs: https://alx.sh/l/asahi-gpu
<segher>
opticron: "was", before it all burned to a crisp? :-)
<opticron>
heh
artemist has quit [Quit: artemist]
artemist has joined #asahi-gpu
phiologe has joined #asahi-gpu
PhilippvK has quit [Ping timeout: 265 seconds]
phiologe has quit [Ping timeout: 260 seconds]
phiologe has joined #asahi-gpu
<marcan>
azonenberg: bloom is doing the userspace side by blackboxing the userspace driver
<marcan>
and I'm writing a hypervisor so I can trace register accesses and blackbox the kernelspace driver right now
<marcan>
that, plus just random guesswork
<marcan>
I mean I figured out the memory compress/decompress instructions and others just by guessing
<marcan>
dynamic analysis is fair game
<marcan>
as in black-box
<marcan>
AIUI some FPGAs were done this way; feed the xilinx tools different constrained designs and diff bitstreams
<marcan>
same thing here
<marcan>
I'm pushing things a bit more in the kernel side than bloom is in userspace, because as of a few days ago I'm using a dev kernel build (which are available to anyone with an apple account, no need to pay anything or sign any NDAs) and I noticed it's rather eager to say interesting things in debug assertions
<marcan>
(like register names)
<marcan>
but I figure anything the kernel *tells* me as part of a debug message that actually gets executed and fires is fair game
<monochroma>
marcan: nice
<marcan>
(though right now I'm reading those messages off of RAM on debugger break... because it dies before serial is initialized :p)
<marcan>
(but it's already inside panic() at that point)
<marcan>
really the important thing is not to copy any code; that's a lot easier to prove if you're not looking at the code to begin with (other than incidental "it crashed and I got some context around the instruction pointer" stuff)
<marcan>
azonenberg: re poking randomly, I've done literal "try flipping every single register bit" on a PS4 GPU (radeon) and on some register spaces on wii u
<marcan>
never destroyed any hardware
<marcan>
just a few crashes
<marcan>
as long as you stay away from, like, regulator I²C spaces, it's very hard to actually blow modern hardware up
<marcan>
and at least in the case of the M1, I think power management that deep down is handled by other cores running firmware we don't care about
<marcan>
I also mentioned in my stream yesterday that there is a *specific* goof where Apple, when they tried to close up M1 bring-up code (for some reason, ARM lawyers almost certainly), the first release was libary blobs included in their open source kernel release, which by all available documentation makes them openly licensed with no anti-RE clause
<marcan>
so disassembling *those* blobs is perfecly kosher, which is cute
<marcan>
(they moved them elsewhere after that one botched release)
<azonenberg>
and i wasn't talking about breaking hardware
<azonenberg>
more like just causing lockups and panics by scribbling all over mmio regions
<marcan>
well, you quickly build up a blocklist of registers you shouldn't touch
<marcan>
:-)
<lain>
that's a nice goof
<marcan>
also my reboot-to-interactive-debug-shell cycle is ~8 seconds right now
<marcan>
let me time an actual hypervisor run to the current crash point...
<marcan>
26 seconds, a bunch of that is compression/checksumming that I want to speed up a bit
<marcan>
I spend a lot of time making my tools efficient; my register poking is remotely controlled from python scripts running on my PC, and most exceptions are caught and recovered from
<marcan>
only if I do something unforeseen to break execution, or actually crash the hardware, do I have to reboot
<marcan>
and then that's just 8 seconds
* monochroma
knows of some open source github repos where they goofed and left some internal debug features in, and deleted them from git, so they don't show up in the history, but obviously still in the repo if you know where to look
<marcan>
I now have the same thing for the hypervisor; exceptions break to the same shell, I can inspect processor context, and as of yesterday get backtraces (with resolved symbols etc), decode panics, etc
<azonenberg>
Nice
* JTL
remembers when doing remote kernel patching and debugging was hot shit