I learned everything I know from the IBM pages written by the engineers, and the QS20 cell blade files. I also looked at all the push buffer research code and hypervisor calls.

The otheros.bld loaded code can only make the lvl1 NAND based code library calls- this level of security is implemented in NAND code which is reinforced by the CBE hardware security. This means even if you found a stack overflow, heap overflow, or any other variant of vulnerability- it'd at most lock down the system because of local stores. You couldn't really overwrite a pointer for NAND based code because of the lockout procedure of SPE and how data from the hard disk is loaded into the public BUS part of the 256KB.

I'm mainly interested in how the CBE acts when it loads it's first code from NAND, because that's where the trusted processing starts, and the part all vendors leave less detailed in literature.

Also IBM says the binaries are only encrypted in the part of the ELF that does key exchanges with the processor when loaded, and supposedly they all have this part. My theory is the IBM/Sony/Toshiba crypto library is compiled into each ELF, and the entry point of the ELF calls the library to modify that part on the stack using root key, and then the code itself uses polymorphism using it's own key in a RSA PKP sheme.

It's all security through obscurity still. They give almost no detail on secure boot, and the QS20 uses the same NAND-CBE relationship just minus Sony and Nvidia code.

EDIT: This info with links where posted over at ps2dev, and they basically shunned it. I guess the account was new, and the info was valid, so the convenient route was to ignore it instead of nay saying the actual designers of the system. I notice the same effect with the other post made with the same account asking for the makefile of a demo. This seems to be a behavior that only occurs in the general population of the Internet, or outside special interest academic and research communities.

Last edited by 0m1kr0n (2008-07-16 16:53:24)