Editing Boot Order

Jump to navigation Jump to search
Warning: You are not logged in. Your IP address will be publicly visible if you make any edits. If you log in or create an account, your edits will be attributed to your username, along with other benefits.

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 its internal (non-encrypted / dual banked) ROM *1 *2
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. It is either sent during or before bootldr. The config ring is checked within bootldr (ch67).
  + syscon sends Cell configuration ring to Cell
  + syscon pulls the reset of Cell high -> Cell INIT (Partially).
  + syscon pulls the reset of Cell high -> Cell INIT
Cell INIT: CELL boots from its internal ROM *2
Cell INIT: CELL boots from it's internal ROM *2
  + fetches encrypted bootldr off NAND (at address 0x000000) /NOR flash (at address 0xFC0000) and boots in isolated SPU.
+ Initialises I/O
Bootldr Running: (Which SPU?)
  + fetches encrypted bootldr off NAND/NOR flash (at address 0xF00000)
  + Initialises I/O (IOIF0/IOIF1)
+ Initialises RAM
  + Initialises XDR (And verifies with memtest elf - On SPU 0 - It's hardcoded to load there).
  + 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
  NEW consoles only: metadata lv0.2 (signed with nonrandomfail key) is used to check lv0 integrity
LV0 Running:
+ LV0 boots frequency to 3GHz and does more HW 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) {{CEX}} (+DEX?) consoles go to standby with red light. {{SHOP}} consoles 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
*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 {{CEX}} 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. Config ring is checked against the known one in bootldr. If you were to modify syscon and the config ring, it still wouldn't boot and would panic as the config ring does not match the expected one.
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 ===
* [http://ip.com/patapp/US20090055637 Secure power-on reset engine]
** [https://patentimages.storage.googleapis.com/f1/41/35/ebbd57077c21f9/US7895426.pdf US7895426.pdf]
** [https://web.archive.org/web/*/http://ps3devwiki.com/files/documents/US20090055637.pdf US20090055637.pdf]
* [https://web.archive.org/web/*/http://ps3devwiki.com/files/documents/-%20Cell%20BE/CellBE_Handbook_v1.12_3Apr09_pub.pdf CellBE_Handbook_v1.12_3Apr09_pub.pdf]
* [https://web.archive.org/web/*/http://ps3devwiki.com/files/documents/-%20Cell%20BE/Cell_Broadband_Engine_processor_vault_security_architecture.pdf Cell_Broadband_Engine_processor_vault_security_architecture.pdf]
* [http://www.multiupload.com/7STWIQ8PBF CellBEBootprocess.pdf (177.69 KB)]) (Mirror: [http://git.gitbrew.org/openclit/documentation/CellBEBootprocess.pdf GitBrew]) //
* [https://web.archive.org/web/*/http://ps3devwiki.com/files/documents/-%20CELL%20SDK%20Documentation/lib/CBE_Secure_SDK_Guide_v3.0.pdf CBE_Secure_SDK_Guide_v3.0.pdf]
* [https://web.archive.org/web/*/http://ps3devwiki.com/files/documents/-%20Cell%20BE/CellBE_HIG_65nm_v1.01_8Jun2007.pdf CellBE_HIG_65nm_v1.01_8Jun2007.pdf)]
* [https://web.archive.org/web/*/http://ps3devwiki.com/files/documents/-%20Cell%20BE/CellBE_HIG_90nm_v1.5_30Nov2007_pub.pdf CellBE_HIG_90nm_v1.5_30Nov2007_pub.pdf])
* [https://web.archive.org/web/*/http://ps3devwiki.com/files/documents/BE_Hardwar_Init_Guide_v1.3_31March2006.pdf BE_Hardwar_Init_Guide_v1.3_31March2006.pdf]


== Chain of Trust ==
== Chain of Trust ==
Line 50: Line 36:
! Exploited
! Exploited
|-
|-
| Runtime Secure Boot
| Runtime Secure Boot
| Hardware based
| Hardware based
| Cell
| Cell
| Hardware Based
| Hardware Based
| no
| no
| no
| no
Line 60: Line 46:
|-
|-
| bootldr (Boot Loader)
| bootldr (Boot Loader)
| [[Flash|NAND (0x000000) / NOR (0xFC0000)]]
| NAND/NOR (asecure_loader)
| SPE(0)
| SPE(0)
| Per Console Encrypted at factory
| Per Console Encrypted at factory
| No <span style="color:red!important;">*</span>
| No
| No
| Boot lv0
| No
| No
| Setup Primary Hardware + load lv0
| Yes
|-
|-
| lv0 (Level 0)
| lv0 (Level 0)
| [[Flash|NAND/NOR (COREOS)]]
| NAND/NOR (COREOS)
| PPU
| PPU
| Static&nbsp;Encryption / Signed
| Static Encryption / Signed
| Yes
| Yes
| No
| No
| Setup Hardware
| Setup Hardware
| Yes
| No
|-
|-
| metldr (asecure_loader)
| metldr (Meta Loader)
| [[Flash|NAND&nbsp;(0x0040810) / NOR&nbsp;(0x000810)]]
| NAND/NOR (asecure_loader)
| SPE(2)
| SPE(2)
| Per&nbsp;Console&nbsp;Encrypted at&nbsp;factory
| Per Console Encrypted at factory
| No <span style="color:red!important;">*</span>
| No
| No
| No
| Load loaders (Meta Loader)
| Run loaders
| Yes
| Yes
|-
|-
| lv1ldr (Level 1 (Hypervisor) Loader)
| lv1ldr (Level 1 (Hypervisor) Loader)
| [[Flash|NAND/NOR (COREOS)]]
| NAND/NOR (COREOS)
| SPE(2)
| SPE(2)
| Static&nbsp;Encryption / Signed
| Static Encryption / Signed
| Yes
| Yes
| No
| No
| Decrypt lv1 (Hypervisor) + Initialize ATA/ENCDEC
| Decrypt lv1 (Hypervisor)
| Yes
| Yes
|-
|-
| lv2ldr (Level 2 (GameOS) Loader)
| lv2ldr (Level 2 (GameOS) Loader)
| [[Flash|NAND/NOR (COREOS)]]
| NAND/NOR (COREOS)
| SPE(2)
| SPE(2)
| Static&nbsp;Encryption / Signed
| Static Encryption / Signed
| Yes
| Yes
| No
| No
Line 105: Line 91:
|-
|-
| appldr (Application Loader)
| appldr (Application Loader)
| [[Flash|NAND/NOR (COREOS)]]
| NAND/NOR (COREOS)
| SPE(2)
| SPE(2)
| Static&nbsp;Encryption / Signed
| Static Encryption / Signed
| Yes
| Yes
| Yes
| Yes
Line 114: Line 100:
|-
|-
| isoldr (Isolation Loader)
| isoldr (Isolation Loader)
| [[Flash|NAND/NOR (COREOS)]]
| NAND/NOR (COREOS)
| SPE(2)
| SPE(2)
| Static&nbsp;Encryption / Signed
| 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)
| [[Flash|NAND/NOR (COREOS)]]
| NAND/NOR (COREOS)
| SPE(2)
| SPE(2)
| Static&nbsp;Encryption / Signed
| Static Encryption / Signed
| Yes
| Yes
| No
| No
| Decrypt revoke list
| decrypt revoke list
| Yes
| Yes
|}
|}
<span style="color:red!important;">*</span> : ofcourse with new hardware revisions, it is updated in factory. See [[Flash#new_metldr.2]]


== Chain of trust Diagram ==
== Chain of trust Diagram ==
[[File:Ps3-cryptochain.png]]
[[File:Ps3-cryptochain.png]]


== Runtime Secure ==
== Cell BE Configuration Ring ==
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/
This [http://www.ps3devforum.com/viewtopic.php?p=31#p31 data was captured] from the SPI bus connecting CELL to SYSCON and parsed as per the [https://www-01.ibm.com/chips/techlib/techlib.nsf/techdocs/BD3F1F4C3DB32C7487257142006131BC/$file/CellBE_HIG_90nm_v1.5_30Nov2007_pub.pdf Cell BE 90nm HIG]. See the full SPI dump for more boot-time communication over SPI.


== Changes in firmware 3.56 ==
{| class="wikitable"
[[spkg_hdr.tar]] and [[ps3swu2.self]] in [[Playstation Update Package (PUP)]] root added
! Offset
! Length
! PS3 Value
! Description


== 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) and reverse the obfuscation in the loaders -> done! see http://www.psdevwiki.com/ps3/Keys#Key_Scrambling
! colspan="4" style="center" | Pervasive Logic (PRV) Bits
|-
| 0000 || 002 || 0b00 || reserved
|-
! colspan="4" style="center" | SPE_1 Bits
|-
| 0002 || 009 || 0b000000000 || reserved
|-
| 0011 || 015 || 0b000000000000000 || SPE1 MC_BASE
|-
| 0026 || 015 || 0b100000000000000 || SPE1 MC_COMP_EN
|-
| 0041 || 010 || 0b1110000000 || SPE1 IOIF1_COMP_EN
|-
| 0051 || 032 || 0x80000000 || reserved
|-
| 0083 || 040 || 0x2401fc00000 || SPE1 SReset???
|-
| 0123 || 064 || 0x0000000000000802 || reserved
|-
| 0187 || 019 || 0b1000000000000000000 || SPE1 BE_MMIO_Base
|-
| 0206 || 004 || 0x0 || SPE1 unit Cell BE node ID
|-
| 0210 || 003 || 0b001 || SPE1 SPE ID
|-
| 0213 || 011 || 0b00110110000 || reserved
|-
! colspan="4" style="center" | SPE_3 Bits
|-
| 0224 || 009 || 0b000000000 || reserved
|-
| 0233 || 015 || 0b000000000000000 || SPE3 MC_BASE
|-
| 0248 || 015 || 0b100000000000000 || SPE3 MC_COMP_EN
|-
| 0263 || 010 || 0b1110000000 || SPE3 IOIF1_COMP_EN
|-
| 0273 || 032 || 0x80000000 || reserved
|-
| 0305 || 040 || 0x2401fc00000 || SPE3 SReset???
|-
| 0345 || 064 || 0x0000000000000802 || reserved
|-
| 0409 || 019 || 0b1000000000000000000 || SPE3 BE_MMIO_Base
|-
| 0428 || 004 || 0x0 || SPE3 unit Cell BE node ID
|-
| 0432 || 003 || 0b011 || SPE3 SPE ID
|-
| 0435 || 011 || 0b00110110000 || reserved
|-
! colspan="4" style="center" | SPE_5 Bits
|-
| 0446 || 009 || 0b000000000 || reserved
|-
| 0455 || 015 || 0b000000000000000 || SPE5 MC_BASE
|-
| 0470 || 015 || 0b100000000000000 || SPE5 MC_COMP_EN
|-
| 0485 || 010 || 0b1110000000 || SPE5 IOIF1_COMP_EN
|-
| 0495 || 032 || 0x80000000 || reserved
|-
| 0527 || 040 || 0x2401fc00000 || SPE5 SReset???
|-
| 0567 || 064 || 0x0000000000000802 || reserved
|-
| 0631 || 019 || 0b1000000000000000000 || SPE5 BE_MMIO_Base
|-
| 0650 || 004 || 0x0 || SPE5 unit Cell BE node ID
|-
| 0654 || 003 || 0b101 || SPE5 SPE ID
|-
| 0657 || 011 || 0b00110110000 || reserved
|-
! colspan="4" style="center" | SPE_7 Bits
|-
| 0668 || 009 || 0b000000000 || reserved
|-
| 0677 || 015 || 0b000000000000000 || SPE7 MC_BASE
|-
| 0692 || 015 || 0b100000000000000 || SPE7 MC_COMP_EN
|-
| 0707 || 010 || 0b1110000000 || SPE7 IOIF1_COMP_EN
|-
| 0717 || 032 || 0x80000000 || reserved
|-
| 0749 || 040 || 0x2401fc00000 || SPE7 SReset???
|-
| 0789 || 064 || 0x0000000000000802 || reserved
|-
| 0853 || 019 || 0b1000000000000000000 || SPE7 BE_MMIO_Base
|-
| 0872 || 004 || 0x0 || SPE7 unit Cell BE node ID
|-
| 0876 || 003 || 0b111 || SPE7 SPE ID
|-
| 0879 || 011 || 0b00110110000 || reserved
|-
! colspan="4" style="center" | Cell Broadband Engine Interface (BEI) Unit Bits
|-
| 0890 || 002 || 0b00 || reserved
|-
| 0892 || 004 || 0x0 || BIF unit Cell BE node ID
|-
| 0896 || 022 || 0b1000000000000000000101 || BEI BE_MMIO_Base
|-
| 0918 || 003 || 0b110 || reserved
|-
| 0921 || 003 || 0b011 || reserved
|-
| 0924 || 012 || 0xf80 || IOIF1 base address mask
|-
| 0936 || 022 || 0b1001000000000000000000 || IOIF1 base address and replacement
|-
| 0958 || 012 || 0xf80 || IOIF0 base address mask
|-
| 0970 || 022 || 0b1010000000000000000000 || IOIF0 base address and replacement
|-
| 0992 || 002 || 0b00 || reserved
|-
| 0994 || 002 || 0b10 || AC0 configuration
|-
| 0996 || 005 || 0b00100 || BIF/IOIF0 receive (RX) configuration
|-
| 1001 || 006 || 0b000100 || BIF/IOIF0 transmit (TX) configuration
|-
| 1007 || 006 || 0b000000 || reserved
|-
| 1013 || 001 || 0b1 || BIF/IOIF0 coherency mode
|-
| 1014 || 003 || 0b000 || reserved
|-
| 1017 || 003 || 0b100 || BIF/IOIF0 I/O reorder mode for transmit
|-
| 1020 || 016 || 0x0000 || reserved
|-
| 1036 || 003 || 0b100 || IOIF1 I/O reorder mode for transmit
|-
| 1039 || 001 || 0b1 || reserved
|-
| 1040 || 002 || 0b10 || IOIF1 RX configuration
|-
| 1042 || 002 || 0b10 || IOIF1 TX configuration
|-
| 1044 || 032 || 0x00000200 || FlexIO PLL configuration
|-
| 1076 || 002 || 0b00 || reserved
|-
! colspan="4" style="center" | EIB Unit Bits
|-
| 1078 || 002 || 0b00 || reserved
|-
| 1080 || 001 || 0b0 || AC0 livelock response control
|-
| 1081 || 004 || 0x0 || EIB unit Cell BE node ID
|-
| 1085 || 001 || 0b0 || AC1 configuration
|-
| 1086 || 001 || 0b1 || AC0 configuration
|-
| 1087 || 004 || 0x2 || AC0 command credits
|-
| 1091 || 022 || 0b1000000000000000000000 || LBAR0_cfg
|-
| 1113 || 022 || 0b1111111111111111111000 || LBAMR0_cfg
|-
| 1135 || 003 || 0b011 || reserved
|-
| 1138 || 001 || 0b0 || AC1 livelock response control
|-
| 1139 || 002 || 0b00 || reserved
|-
! colspan="4" style="center" | SPE_6 Bits
|-
| 1141 || 009 || 0b000000000 || reserved
|-
| 1150 || 015 || 0b000000000000000 || SPE6 MC_BASE
|-
| 1165 || 015 || 0b100000000000000 || SPE6 MC_COMP_EN
|-
| 1180 || 010 || 0b1110000000 || SPE6 IOIF1_COMP_EN
|-
| 1190 || 032 || 0x80000000 || reserved
|-
| 1222 || 040 || 0x2401fc00000 || SPE6 SReset???
|-
| 1262 || 064 || 0x0000000000000802 || reserved
|-
| 1326 || 019 || 0b1000000000000000000 || SPE6 BE_MMIO_Base
|-
| 1345 || 004 || 0x0 || SPE6 unit Cell BE node ID
|-
| 1349 || 003 || 0b110 || SPE6 SPE ID
|-
| 1352 || 011 || 0b00110110000 || reserved
|-
! colspan="4" style="center" | SPE_4 Bits
|-
| 1363 || 009 || 0b000000000 || reserved
|-
| 1372 || 015 || 0b000000000000000 || SPE4 MC_BASE
|-
| 1387 || 015 || 0b100000000000000 || SPE4 MC_COMP_EN
|-
| 1402 || 010 || 0b1110000000 || SPE4 IOIF1_COMP_EN
|-
| 1412 || 032 || 0x80000000 || reserved
|-
| 1444 || 040 || 0x2401fc00000 || SPE4 SReset???
|-
| 1484 || 064 || 0x0000000000000802 || reserved
|-
| 1548 || 019 || 0b1000000000000000000 || SPE4 BE_MMIO_Base
|-
| 1567 || 004 || 0x0 || SPE4 unit Cell BE node ID
|-
| 1571 || 003 || 0b100 || SPE4 SPE ID
|-
| 1574 || 011 || 0b00110110000 || reserved
|-
! colspan="4" style="center" | SPE_2 Bits
|-
| 1585 || 009 || 0b000000000 || reserved
|-
| 1594 || 015 || 0b000000000000000 || SPE2 MC_BASE
|-
| 1609 || 015 || 0b100000000000000 || SPE2 MC_COMP_EN
|-
| 1624 || 010 || 0b1110000000 || SPE2 IOIF1_COMP_EN
|-
| 1634 || 032 || 0x80000000 || reserved
|-
| 1666 || 040 || 0x2401fc00000 || SPE2 SReset???
|-
| 1706 || 064 || 0x0000000000000802 || reserved
|-
| 1770 || 019 || 0b1000000000000000000 || SPE2 BE_MMIO_Base
|-
| 1789 || 004 || 0x0 || SPE2 unit Cell BE node ID
|-
| 1793 || 003 || 0b010 || SPE2 SPE ID
|-
| 1796 || 011 || 0b00110110000 || reserved
|-
! colspan="4" style="center" | SPE_0 Bits
|-
| 1807 || 009 || 0b000000000 || reserved
|-
| 1816 || 015 || 0b000000000000000 || SPE0 MC_BASE
|-
| 1831 || 015 || 0b100000000000000 || SPE0 MC_COMP_EN
|-
| 1846 || 010 || 0b1110000000 || SPE0 IOIF1_COMP_EN
|-
| 1856 || 032 || 0x80000000 || reserved
|-
| 1888 || 040 || 0x2401fc00000 || SPE0 SReset???
|-
| 1928 || 064 || 0x0000000000000802 || reserved
|-
| 1992 || 019 || 0b1000000000000000000 || SPE0 BE_MMIO_Base
|-
| 2011 || 004 || 0x0 || SPE0 unit Cell BE node ID
|-
| 2015 || 003 || 0b000 || SPE0 SPE ID
|-
| 2018 || 011 || 0b00110110000 || reserved
|-
! colspan="4" style="center" | MIC Bus Logic Bits
|-
| 2029 || 004 || 0x8 || reserved
|-
| 2033 || 016 || 0x0000 || MIC address space start
|-
| 2049 || 016 || 0xfffc || MIC address space end
|-
| 2065 || 030 || 0b100000000000000000010100001001 || PRV BE_MMIO_Base
|-
| 2095 || 030 || 0b100000000000000000010100001010 || MIC BE_MMIO_Base
|-
| 2125 || 004 || 0x3 || reserved
|-
| 2129 || 004 || 0x0 || MIC unit Cell BE node ID
|-
| 2133 || 002 || 0b00 || reserved
|-
! colspan="4" style="center" | PowerPC Processor Unit Bits
|-
| 2135 || 009 || 0b000000000 || reserved
|-
| 2144 || 008 || 0x00 || PIR_defn
|-
| 2152 || 013 || 0b0000000000000 || reserved
|-
| 2165 || 040 || 0x2401fc00000 || PPE SReset Vector
|-
| 2205 || 224 || 0x000000000000000000000000008000000000000000000000000003c0 || reserved
|-
! colspan="4" style="center" | PowerPC Processor Storage Subsystem (PPSS) Bits
|-
| 2429 || 061 || 0x008000000000400, 0b0 || reserved
|-
| 2490 || 001 || 0b1 || L2 livelock
|-
| 2491 || 044 || 0x000000f8000 || reserved
|-
| 2535 || 004 || 0x0 || PPE unit Cell BE node ID
|-
| 2539 || 009 || 0b011011000 || reserved
|-
| 2548 || 030 || 0b100000000000000000010100000000 || PPE BE_MMIO_Base
|-
| 2578 || 007 || 0b1000111 || reserved
|-
| 2585 || 001 || 0b1 || NCU 2 token decode
|-
| 2586 || 016 || 0x0000 || reserved
|-
| 2602 || 001 || 0b1 || NCU livelock
|-
| 2603 || 001 || 0b1 || PPE livelock
|-
| 2604 || 002 || 0b00 || reserved
|-
! colspan="4" style="center" | MIC Bits
|-
| 2606 || 016 || 0x0000 || XIO PLL LO
|-
| 2622 || 016 || 0x9cfc || XIO PLL HI
|-
| 2638 || 004 || 0x0 || reserved
|-
! colspan="4" style="center" | PRV Bits
|-
| 2642 || 006 || 0b011111 || Thermal overload temperature
|-
| 2648 || 027 || 0b000001010001000000000011000 || reserved
|-
| 2675 || 001 || 0b1 || Pervasive logic livelock
|-
| 2676 || 010 || 0b0000000000 || reserved
|-
| 2686 || 008 || 0x08 || SPE disable
|-
| 2694 || 003 || 0b011 || reserved
|}


=== Chain of trust Diagram 3.60++ ===
== Runtime Secure ==
<table width="100%" align="left"><tr><td align="left">[[File:Ps3-cryptochain-360.png|800px|thumb|left|LV0 with encapsulated loaders (appldr, isoldr, lv1ldr, lv2ldr).)]]</tr></table>
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.
not in this diagram: the added .2 metadata<br />


== PPU Boot Order ==
http://www.ibm.com/developerworks/power/library/pa-cellsecurity/


lv0 -> lv1.self -> lv2_kernel.self -> sys_init_osd.self -> vsh.self
== Changes in firmware 3.60 ==


{{Reverse engineering}}<noinclude>[[Category:Main]]</noinclude>
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.
Please note that all contributions to PS3 Developer wiki are considered to be released under the GNU Free Documentation License 1.2 (see PS3 Developer wiki:Copyrights for details). If you do not want your writing to be edited mercilessly and redistributed at will, then do not submit it here.
You are also promising us that you wrote this yourself, or copied it from a public domain or similar free resource. Do not submit copyrighted work without permission!

To protect the wiki against automated edit spam, we kindly ask you to solve the following hCaptcha:

Cancel Editing help (opens in new window)