Is register 0x206140008 in the #iOSTriangulation PPL bypass the gfx-asc's l2c_err_sts?
https://securelist.com/operation-triangulation-the-last-hardware-mystery/111669/
When I read it, it matches the value I get for l2c_err_sts in the "GFX SError" panic log.

(Unfortunately, dma_ctrl_2 sets bit 60 in that register, which doesn't match any of the documented bits in m1n1 https://github.com/AsahiLinux/m1n1/blob/90eef7223e5da9bdc7ad7f823e7748326ba862d2/src/cpu_regs.h#L461, so no idea if it's really l2c_err_sts or not.)

@oct0xor @marcan
Operation Triangulation: The last (hardware) mystery

Recent iPhone models have additional hardware-based security protection for sensitive regions of the kernel memory. We discovered that to bypass this hardware-based security protection, the attackers used another hardware feature of Apple-designed SoCs.

Kaspersky
@zhuowei @[email protected] Based on what marcan found I think it actually might be. “l2c” could mean L2 cache.
@oct0xor @marcan It's definitely l2c_err_sts: if I write to 0x206140008 and wait for the GPU to panic with SError, the panic log shows "l2c_err_sts: <what I wrote>".

0x206140010 and 0x206140018 also matches l2c_err_adr and l2c_err_inf in the panic log.

I assume writing to that register turns off (or acknowledges?) the SError exceptions so that the GPU doesn't panic after the core resumes?

(The CPU equivalent register, L2C_ERR_STS_EL1, stands for "L2 Cache Error Status", according to https://github.com/AsahiLinux/m1n1/blob/90eef7223e5da9bdc7ad7f823e7748326ba862d2/tools/apple_regs.json#L118)

Now if we only know what 0x206140108 does...

Thank you so much for your response, and for your amazing research!
m1n1/tools/apple_regs.json at 90eef7223e5da9bdc7ad7f823e7748326ba862d2 · AsahiLinux/m1n1

A bootloader and experimentation playground for Apple Silicon - AsahiLinux/m1n1

GitHub