Editing Boot Order
Jump to navigation
Jump to search
The edit can be undone. Please check the comparison below to verify that this is what you want to do, and then publish the changes below to finish undoing the edit.
| Latest revision | Your text | ||
| Line 1: | Line 1: | ||
== Boot Sequence == | == Boot Sequence == | ||
Power on: syscon boots from | Power on : syscon boots from it's internal (non-encrypted / dual banked) ROM *1 *2 | ||
+ syscon powers up various power subsystems | + syscon powers up various power subsystems | ||
+ syscon powers up cell and checks status | + syscon powers up cell and checks status | ||
+ syscon sends Cell configuration ring to Cell | + syscon sends Cell configuration ring to Cell | ||
+ syscon pulls the reset of Cell high -> Cell INIT | + syscon pulls the reset of Cell high -> Cell INIT | ||
Cell INIT: CELL boots from | Cell INIT: CELL boots from it's internal ROM *2 | ||
+ fetches encrypted bootldr off NAND | + Initialises I/O | ||
+ fetches encrypted bootldr off NAND/NOR flash (at address 0xFC0000) | |||
+ | + Initialises RAM | ||
+ | + loads bootldr into Isolated SPU (SPE0) | ||
+ Runtime Secure Boot decrypts and verifies bootldr and executes | |||
+ bootldr decrypts lv0 which runs on PPU -> loaders INIT | + bootldr decrypts lv0 which runs on PPU -> loaders INIT | ||
loaders INIT: lv0 loads metldr (SPE2) | loaders INIT: lv0 loads metldr (SPE2) | ||
+ passes lv1ldr (which loads lv1) to metldr | + passes lv1ldr (which loads lv1) to metldr | ||
| Line 22: | Line 20: | ||
*1) Read/Writeable with undocumented / should also be read/writeable through serial port and possible to switch it to the backup bank1 with backup_mode pulled high | *1) Read/Writeable with undocumented / should also be read/writeable through serial port and possible to switch it to the backup bank1 with backup_mode pulled high | ||
*2) | *2) CEX/Retail consoles go to standby with red light. SEX/SHOP/SECH will not standby, but instead boot through without waiting for powerbutton. Also check is done on all models if update is flagged to set it into firmware updating procedure | ||
*3) Partialy Read/Writeable | *3) Partialy Read/Writeable | ||
about the disabled SPE: syscon reads it’s internal (non-encrypted) eeprom @ 0x48C30 which is value 0×06 on all | about the disabled SPE: syscon reads it’s internal (non-encrypted) eeprom @ 0x48C30 which is value 0×06 on all CEX/Retail consoles and will set the cell config ring accordingly for 7 SPE’s. SPE0 and SPE2 are reserved for bootldr and metldr for isolation respectively. Setting the value to a nonworking state (e.g. 0×00, 0xFF, enabling a defective SPE or disabling a needed SPE for proper boot) might brick the console, locking you out from restoring the correct value to the syscon eeprom. | ||
== Chain of Trust == | == Chain of Trust == | ||
| Line 50: | Line 36: | ||
! Exploited | ! Exploited | ||
|- | |- | ||
| Runtime | | Runtime Secure Boot | ||
| Hardware | | Hardware based | ||
| Cell | | Cell | ||
| Hardware | | Hardware Based | ||
| no | | no | ||
| no | | no | ||
| Line 60: | Line 46: | ||
|- | |- | ||
| bootldr (Boot Loader) | | bootldr (Boot Loader) | ||
| NAND/NOR (0xFC0000) | |||
| SPE(0) | | SPE(0) | ||
| Per | | Per Console Encrypted at factory | ||
| No | | No | ||
| No | |||
| Boot lv0 | |||
| No | | No | ||
|- | |- | ||
| lv0 (Level 0) | | lv0 (Level 0) | ||
| NAND/NOR (COREOS) | |||
| PPU | | PPU | ||
| Static | | Static Encryption / Signed | ||
| Yes | | Yes | ||
| No | | No | ||
| Setup Hardware | | Setup Hardware | ||
| | | No | ||
|- | |- | ||
| metldr ( | | metldr (Meta Loader) | ||
| NAND/NOR (asecure_loader) | |||
| SPE(2) | | SPE(2) | ||
| Per | | Per Console Encrypted at factory | ||
| No | | No | ||
| | | No | ||
| Run loaders | |||
| Yes | | Yes | ||
|- | |- | ||
| lv1ldr (Level 1 (Hypervisor) Loader) | | lv1ldr (Level 1 (Hypervisor) Loader) | ||
| NAND/NOR (COREOS) | |||
| SPE(2) | | SPE(2) | ||
| Static | | Static Encryption / Signed | ||
| Yes | | Yes | ||
| No | | No | ||
| Decrypt lv1 (Hypervisor) | | Decrypt lv1 (Hypervisor) | ||
| Yes | | Yes | ||
|- | |- | ||
| lv2ldr (Level 2 (GameOS) Loader) | | lv2ldr (Level 2 (GameOS) Loader) | ||
| NAND/NOR (COREOS) | |||
| SPE(2) | | SPE(2) | ||
| Static | | Static Encryption / Signed | ||
| Yes | | Yes | ||
| No | | No | ||
| Line 105: | Line 91: | ||
|- | |- | ||
| appldr (Application Loader) | | appldr (Application Loader) | ||
| NAND/NOR (COREOS) | |||
| SPE(2) | | SPE(2) | ||
| Static | | Static Encryption / Signed | ||
| Yes | | Yes | ||
| Yes | | Yes | ||
| Line 114: | Line 100: | ||
|- | |- | ||
| isoldr (Isolation Loader) | | isoldr (Isolation Loader) | ||
| NAND/NOR (COREOS) | |||
| SPE(2) | | SPE(2) | ||
| Static | | Static Encryption / Signed | ||
| Yes | | Yes | ||
| No | | No | ||
| Line 123: | Line 109: | ||
|- | |- | ||
| rvkldr (Revokation Loader) (Discarded after 0.8) | | rvkldr (Revokation Loader) (Discarded after 0.8) | ||
| NAND/NOR (COREOS) | |||
| SPE(2) | | SPE(2) | ||
| Static | | Static Encryption / Signed | ||
| Yes | | Yes | ||
| No | | No | ||
| | | decrypt revoke list | ||
| Yes | | Yes | ||
|} | |} | ||
== Chain of trust Diagram == | == Chain of trust Diagram == | ||
| Line 139: | Line 124: | ||
This runtime secure boot, in fact, is tightly coupled with an SPE entering isolation mode. An application must go through the hardware authentication step before it can execute on an isolated SPE. When isolation mode is requested, first, the previous thread is stopped and cancelled. Then, the hardware will automatically start fetching the application into the LS, and the hardware will verify the integrity of the application. If the integrity check fails, the application will not be executed. The check can fail for one of two reasons. The application might have been modified within memory or storage. Then, the assumption is that the functionality might have changed and it cannot be trusted anymore. Or, the writer of the application does not know the cryptographic secret that is needed for a successful authentication. Otherwise, if the authentication check is successful, the hardware will automatically kick-start the application's execution in isolation mode. Because the hardware controls all of these steps, the verification of the application's integrity cannot be skipped or manipulated and will happen consistently and correctly. | This runtime secure boot, in fact, is tightly coupled with an SPE entering isolation mode. An application must go through the hardware authentication step before it can execute on an isolated SPE. When isolation mode is requested, first, the previous thread is stopped and cancelled. Then, the hardware will automatically start fetching the application into the LS, and the hardware will verify the integrity of the application. If the integrity check fails, the application will not be executed. The check can fail for one of two reasons. The application might have been modified within memory or storage. Then, the assumption is that the functionality might have changed and it cannot be trusted anymore. Or, the writer of the application does not know the cryptographic secret that is needed for a successful authentication. Otherwise, if the authentication check is successful, the hardware will automatically kick-start the application's execution in isolation mode. Because the hardware controls all of these steps, the verification of the application's integrity cannot be skipped or manipulated and will happen consistently and correctly. | ||
http://www.ibm.com/developerworks/power/library/pa-cellsecurity/ | |||
== Changes in firmware 3.60 == | == Changes in firmware 3.60 == | ||
Lv0 has now been changed, LV0 now appears to encapsulate all of the loaders (lv1ldr, lv2ldr, appldr, isoldr). Now in order to break the chain of trust we need to be able to decrypt/exploit LV0 which at this time has not been done. | |||