PDX has been nice enough to share hints with us on how they found this "exploit" and yet everyone keeps beating around the bush and looking for other ways to produce the same thing. Why don't we start discussing the information they shared in the nfos and expand on it.Sponsored Links
We suggest why not have a look in multiple SPEs? Since they use shared memory for tasks! couldn't there be a bug in that part? and what about LS size limitation? Enough for now!
and a quick scan through the BE Handbook brings this to my attention:
The SPU fetches instructions from its unified (instructions and data) 256-KB local store (LS), and it loads and stores data between its LS and its single register file for all data types, which has 128 registers, each 128 bits wide. The SPU has four execution units, a DMA interface, and a channel interface for communicating with its MFC, the PPE and other devices (including other SPEs). Each SPU is an independent processor element with its own program counter, optimized to run SPU programs. The SPU fills its LS by requesting DMA transfers from its MFC, which implements the DMA transfers using its DMA controller. Then, the SPU fetches and executes instructions from its LS, and it loads and stores data to and from its LS.
And: The Local Store (LS) is a 256-KB, ECC-protected, single-ported, noncaching memory. It stores all instructions and data used by the SPU. It supports one access per cycle from either SPE software or DMA transfers. SPU instruction prefetches are 128 bytes per cycle. SPU data-access bandwidth is 16 bytes per cycle, quadword aligned. DMA-access bandwidth is 128 bytes per cycle. DMA transfers perform a read-modify-write of LS for writes less than a quadword.
Rather then complaining and waiting for an ISO loader why doesn't everyone do something about it. Even if your not a programmer you can research and gather information, then when someone stops in a reads this stuff they might think of something and with our help find a hole.