Comment by supriyo-biswas

More evidence for an ECC, obtained by looking at how the 10 output bits of the function depend on its 256 input bits:

Each of the 10 parity bits output by the function is the xor of exactly 104 of the 256 input bits.

Each of the 256 input bits contributes to (= is xor-ed into) either 3 or 5 of the 10 parity bits.

This is in line with the SEC-DED (single error correction, double error detection) ECC construction from the following paper:

https://people.eecs.berkeley.edu/~culler/cs252-s02/papers/hs...

Translating the above observations about the function into properties of the H matrix in the paper:

Each row of the matrix contains an identical number of ones (104).

Each column of the matrix contains an odd number of ones (3 or 5).

Very interesting, thanks. Summarizing that thread:

- The "hash" is probably an error correcting code fed into GPU cache debug registers which will be stored in the cacheline itself, you're expected to compute the ECC because it's so low level. That is, the goal isn't to protect the DMA interface. (but this isn't 100% certain, it's just an educated guess)

- The "sbox" is similar to but not the same as a regular ECC as commonly used in hardware.

- Martin argues that the existence of such registers and the code table could have been guessed or brute forced, even though a compromise or info leak from Apple seems more likely. Or possibly even from the old PowerVR days. But if it's the NSA then who knows, maybe they are literally fuzzing hidden MMIO ranges to discover these interfaces.

- This is possible because the GPU has full DMA access without an IOMMU for performance reasons, so it's fertile ground for such exploits. Probably more will be discovered.

So that's all reassuring.

Why do you need error-correction code for a debugging feature though? I would not protect debug registers with a hash.