Boot Order: Difference between revisions

From PS3 Developer wiki
Jump to navigation Jump to search
Line 191: Line 191:
| sdk_version || {{Yes}} || {{Yes}} || {{Yes}} || {{Yes}} || {{Yes}} || {{Yes}} || {{Yes}} || - || - || textfile noting version
| sdk_version || {{Yes}} || {{Yes}} || {{Yes}} || {{Yes}} || {{Yes}} || {{Yes}} || {{Yes}} || - || - || textfile noting version
|-
|-
| spp_verifier.self || {{Yes}} || {{Yes}} || {{Yes}} || {{Yes}} || {{Yes}} || {{Yes}} || {{Yes}} || || ||  
| spp_verifier.self || {{Yes}} || {{Yes}} || {{Yes}} || {{Yes}} || {{Yes}} || {{Yes}} || {{Yes}} || isoldr || default.spp ||  
|-
|-
| spu_pkg_rvk_verifier.self || {{Yes}} || {{Yes}} || {{Yes}} || {{Yes}} || {{Yes}} || {{Yes}} || {{Yes}} || || ||  
| spu_pkg_rvk_verifier.self || {{Yes}} || {{Yes}} || {{Yes}} || {{Yes}} || {{Yes}} || {{Yes}} || {{Yes}} || || ||  

Revision as of 03:33, 30 November 2011

Boot Sequence

Power on : syscon boots from it's internal (non-encrypted / dual banked) ROM *1 *2

+ syscon powers up various power subsystems
+ syscon powers up cell and checks status
+ syscon sends Cell configuration ring to Cell
+ syscon pulls the reset of Cell high -> Cell INIT

Cell INIT: CELL boots from it's internal ROM *2

+ 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

loaders INIT: lv0 loads metldr (SPE2)

+ passes lv1ldr (which loads lv1) to metldr
+ passes lv2ldr (which loads lv2) to metldr
+ passes appldr (which loads vsh) to metldr
+ passes isoldr (which loads *.iso_spu_module) to metldr
+ passes rvkldr (which loads rvkprg / rvklist) to metldr
  • 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) 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

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.

References

Chain of Trust

Name Location Processor Encryption Updateable Revokable Usage Exploited
Runtime Secure Boot Hardware based Cell Hardware Based no no Verification of images loaded into isolated SPE no
bootldr (Boot Loader) NAND/NOR (0xFC0000) SPE(0) Per Console Encrypted at factory No * No Boot lv0 No
lv0 (Level 0) NAND/NOR (COREOS) PPU Static Encryption / Signed Yes No Setup Hardware No
metldr (Meta Loader) NAND/NOR (asecure_loader) SPE(2) Per Console Encrypted at factory No * No Run loaders Yes
lv1ldr (Level 1 (Hypervisor) Loader) NAND/NOR (COREOS) SPE(2) Static Encryption / Signed Yes No Decrypt lv1 (Hypervisor) Yes
lv2ldr (Level 2 (GameOS) Loader) NAND/NOR (COREOS) SPE(2) Static Encryption / Signed Yes No Decrypt lv2 (GameOS) Yes
appldr (Application Loader) NAND/NOR (COREOS) SPE(2) Static Encryption / Signed Yes Yes Decrypt games Yes
isoldr (Isolation Loader) NAND/NOR (COREOS) SPE(2) Static Encryption / Signed Yes No Decrypt modules Yes
rvkldr (Revokation Loader) (Discarded after 0.8) NAND/NOR (COREOS) SPE(2) Static Encryption / Signed Yes No decrypt revoke list Yes

* : ofcourse with new hardware revisions, it is updated in factory. See Flash#new_metldr.2

Chain of trust Diagram

Ps3-cryptochain.png

Runtime Secure

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.

Changes in firmware 3.60

Lv0 has now been changed, LV0 now appears to encapsulate all of the loaders (appldr, isoldr, lv1ldr, lv2ldr). Now in order to break the chain of trust we need to be able to decrypt/exploit LV0 (or bootldr which loads LV0).

Chain of trust Diagram 3.60++

LV0 with encapsulated loaders (appldr, isoldr, lv1ldr, lv2ldr).)


CoreOS PKG Filelisting

File  1.00-1.94   2.00-2.36   2.40-3.01   3.10-3.42   3.50-3.55   3.56   3.60-3.74  Loaded by
(upper chain of trust)
Loads
(lower chain of trust)
notes
aim_spu_module.self Yes Yes Yes Yes Yes Yes Yes
appldr Yes Yes Yes Yes Yes Yes No metldr/lv0 vsh.self Application Loader (userlevel)
creserved_0 Yes Yes Yes Yes Yes Yes Yes FF-filled file
default.spp Yes Yes Yes Yes Yes Yes Yes spp_verifier.self profiles for LPARs
emer_init.self No Yes Yes Yes Yes Yes Yes lv2.self ? recovery menu
eurus_fw.bin No Yes Yes Yes Yes Yes Yes
hdd_copy.self No No No Yes Yes Yes Yes
isoldr Yes Yes Yes Yes Yes Yes No metldr/lv0 manu_info_spu_module.self, mc_iso_spu_module.self, me_iso_for_ps2emu.self, me_iso_spu_module.self, sb_iso_spu_module.self, sc_iso.self, sv_iso_for_ps2emu.self. sv_iso_spu_module.self Isolation Loader (securelevel)
lv0 Yes Yes Yes Yes Yes Yes Yes bootldr {appldr, isoldr, lv1ldr, lv2ldr} (parsed through metldr?)
lv0.2 No No No No No No Yes lv0
lv1.self Yes Yes Yes Yes Yes Yes Yes lv1ldr Hypervisor
lv1ldr Yes Yes Yes Yes Yes Yes No metldr/lv0 lv1.self Hypervisor Loader
lv2_kernel.self Yes Yes Yes Yes Yes Yes Yes lv2ldr Supervisor Kernel
lv2ldr Yes Yes Yes Yes Yes Yes No metldr/lv0 lv2_kernel.self Supervisor Loader (kernellevel)
manu_info_spu_module.self No No No No Yes Yes Yes
mc_iso_spu_module.self Yes Yes Yes Yes Yes Yes Yes isoldr ss_iso_dma_data, spulib_spu
me_iso_for_ps2emu.self No No No No No No Yes isoldr ps2_emu.self, ps2_gxemu.self, ps2_softemu.self ss_iso_dma_data, spulib_spu
me_iso_spu_module.self Yes Yes Yes Yes Yes Yes Yes isoldr ss_iso_dma_data, spulib_spu
pkg.srvk No No No No No Yes Yes spu_pkg_rvk_verifier.self ? signed revokelist
prog.srvk No No No No No Yes Yes spu_pkg_rvk_verifier.self ? signed revokelist
sb_iso_spu_module.self Yes Yes Yes Yes Yes Yes Yes isoldr ss_iso_dma_data, spulib_spu
sc_iso.self Yes Yes Yes Yes Yes Yes Yes isoldr ?
sdk_version Yes Yes Yes Yes Yes Yes Yes - - textfile noting version
spp_verifier.self Yes Yes Yes Yes Yes Yes Yes isoldr default.spp
spu_pkg_rvk_verifier.self Yes Yes Yes Yes Yes Yes Yes
spu_token_processor.self Yes Yes Yes Yes Yes Yes Yes
spu_utoken_processor.self No No Yes Yes Yes Yes Yes
sv_iso_for_ps2emu.self No No No No No No Yes isoldr ps2_emu.self, ps2_gxemu.self, ps2_softemu.self ss_iso_dma_data, spulib_spu
sv_iso_spu_module.self Yes Yes Yes Yes Yes Yes Yes isoldr ss_iso_dma_data, spulib_spu