Security

The red box is secure world ARM. The green box is non-secure kernel mode ARM. The blue box is non-secure user mode ARM. The yellow is F00D processor. Black arrows indicate trust (A -> B means B trusts A). Green arrows means decryption request (A -> B means A requests decryption from B). Red arrow means executable decryption (A -> B means A decrypts B). THIS IS WRONG AND NEEDS TO BE UPDATED

Root Chain of Trust

ROMs are trusted implicitly. second_loader and secure_kernel are, at update time, additoinally encrypted (likely with per-console keys). If that is the case, it is likely that the F00D bootrom has the ability to decrypt those two files. It is also predicted that secure_kernel is run on F00D as does second_loader in order to decrypt kernel_boot_loader.self to start the ARM code .

Decryption Request

If something needs to be decrypted from a user/system application (PVF or PUP for example), first the request is passed to the kernel. The kernel does some checks (mostly integrity checks) and makes a request to the secure kernel to load a new F00D SELF (to have the right keys and the right program to parse the format). Next the kernel passes the data to the secure kernel to decrypt and the secure kernel passes it to F00D. F00D does the real checks (integrity, signature, format, etc) and decrypts the data directly into the shared DRAM. After clearing the cache, the non-secure kernel has access to the data. F00D will not decrypt if anything fails in its checks.

Security

The two bootroms are physically burned into the SoC and cannot be changed. The Cortex A9 bootrom loads the first level bootloader and the F00D bootrom is unknown. Every other component can be changed and most can be revoked. Below, we discuss potential outcomes if there is a hack at each level.

Usermode

If a game/application/system application is hacked, Sony can easily send a firmware update to block the hack. They can also send a game update and depending on the game that is hacked, they could enforce an update and therefore stop the exploit from triggering.

Non-secure Kernel

A hack at this level would allow for running unsigned code and also pirated games. Decryption must be done through the secure kernel & F00D, so attempts at decrypting SELFs from past and future firmwares will not work. To counter piracy, Sony can encrypt new games with new keys and prevent them from running on old compromised firmwares. They can also revoke vulnerable kernel versions to prevent downgrades by updating the revoke list in F00D.

Secure Kernel

Same level of access and same results as non-secure kernel. Direct access to F00D interrupts could allow for an attack though.

Secure/non-secure bootloader

Will allow for "non-tethered" hacks. Can be used to load unsigned kernel at an early stage. Could potentially control F00D revoking by initializing with an older/newer FW, but this is untested. Can be revoked to prevent downgrades by preventing F00D from re-encrypting the (vulnerable) bootloader upon update. If there are additional hardware for this, it could also prevent replay attacks from an older, dumped bootloader.

F00D applications

All keys are stored as F00D SELFs, which are validated and decrypted just like ARM SELFs. If compromised, keys can be extracted to decrypt updates, bootloader, kernel SELFs, application SELFs, and more. It is unknown whether Sony can revoke keys because it may be possible to just decrypt the update containing new keys.