Kernel Boot Loader: Difference between revisions

From Vita Development Wiki
Jump to navigation Jump to search
No edit summary
No edit summary
 
(2 intermediate revisions by one other user not shown)
Line 1: Line 1:
The Kernel Boot Loader is (likely) the third stage bootloader of the PS Vita system. It is <code>kernel_boot_loader.self</code> in the [[Boot Sequence#Boot Partition|Boot Partition]]. It initializes ARM [[Secure World]] (ARM Secure kernel) through [[SKBL]] and ARM Non-secure kernel through [[NSKBL]].
The Kernel Boot Loader is (likely) the third stage bootloader of the PS Vita system. It is <code>kernel_boot_loader.self</code> in the [[Boot Sequence#Boot Partition|Boot Partition]]. It initializes ARM [[TrustZone]] (ARM Secure kernel) through [[SKBL]] and ARM Non-secure kernel through [[NSKBL]].


= Structure =
= Structure =
Line 11: Line 11:
== SKBL Segment 0 ==
== SKBL Segment 0 ==


This is SKBL executable code followed by Tzs modules.
This is SKBL executable code followed by [[TrustZone|Tzs]] modules.


=== FW 3.60 ===
=== FW 3.60 ===
Line 72: Line 72:


It contains at least:
It contains at least:
* two corelock context
* two corelock contexts
* SKBL initial stack cookie
* initial SKBL stack cookie
* SKBL some pointer
* some pointers to SKBL area
* device register base
* device register base
* zeroed data
* zeroed data
Line 86: Line 86:
== ARM Kernel BootLoader ==
== ARM Kernel BootLoader ==


It is speculated that the first stage of the secure boot process is the [[Boot ROM]] in [[Cmep]] which decrypts kernel_boot_loader.self into DRAM and resets the ARM CPU. The stage at this point would have set up DRAM and the [[eMMC]] driver. There is no Virtual Memory Addressing at this point. A couple of things are loaded into memory. <code>kprx_auth_sm.self</code> from the [[SLB2]] [[eMMC]] partition is located at <code>0x40000500</code> (as-is/encrypted). Similarly <code>prog_rvk.srvk</code> is located at <code>0x40008B00</code>. The VBAR is likely set to <code>0x40000000</code>, where most handlers point to unhandled exception error code. The [[SKBL]] segments are loaded to <code>0x40020000</code> (where the reset vector points to) and are in three main parts. The first part is the [[SKBL]] code which includes stripped down versions of [[SceSysmem]], [[SceKernelModulemgr]], and initialization code (reset vector points to code in this range). The second part is the [[Secure Kernel]] stored as a series of either plaintext ELFs or [[ARZL]] compressed ELF. On FW 1.69, only [[SceSysmem]] is [[ARZL]] compressed whilst the other [[Secure Kernel]] modules are plaintext ELFs. Additionally, some initialization data is passed in <code>0x4005A000</code>, <code>0x0</code>, and <code>0x100</code>.
It is speculated that the first stage of the secure boot process is the [[Boot ROM]] in [[CMeP]] which decrypts kernel_boot_loader.self into DRAM and resets the ARM CPU. The stage at this point would have set up DRAM and the [[eMMC]] driver. There is no Virtual Memory Addressing at this point. A couple of things are loaded into memory. <code>kprx_auth_sm.self</code> from the [[SLB2]] [[eMMC]] partition is located at <code>0x40000500</code> (as-is/encrypted). Similarly <code>prog_rvk.srvk</code> is located at <code>0x40008B00</code>. The VBAR is likely set to <code>0x40000000</code>, where most handlers point to unhandled exception error code. The [[SKBL]] segments are loaded to <code>0x40020000</code> (where the reset vector points to) and are in three main parts. The first part is the [[SKBL]] code which includes stripped down versions of [[SceSysmem]], [[SceKernelModulemgr]], and initialization code (reset vector points to code in this range). The second part is the [[TrustZone]] stored as a series of either plaintext ELFs or [[ARZL]] compressed ELF. On FW 1.69, only [[SceSysmem]] is [[ARZL]] compressed whilst the other [[TrustZone]] modules are plaintext ELFs. Additionally, some initialization data is passed in <code>0x4005A000</code>, <code>0x0</code>, and <code>0x100</code>.


== Secure Kernel BootLoader - reset ==
== Secure Kernel BootLoader - reset ==
Line 94: Line 94:
== Secure Kernel BootLoader - TrustZone loading ==
== Secure Kernel BootLoader - TrustZone loading ==


Next the ARM Secure Kernel is loaded with the stripped down module manager (equivalent to [[SceKernelModulemgr]]) inside the kernel boot loader. First [[SceSysmem]], which on newer FWs is [[ARZL]] compressed, is decompressed to scratch space at <code>0x1C000000</code>. Then the ELF loader loads it and the system memory manager's initialization function is called which setups the memory in [[Secure World]]. This also setups [[KBL Param]] in [[Secure World]]. Data from physical address <code>0x100</code> is copied to the buffer allocated at offset 0x6C0 (?[[KBL Param]]?) (in FW 1.69 this is 0x46C0). The other ELFs are not compressed and just loaded as-is by the module manager. [[SceExcpmgr]] is loaded next and its initialization function replaces the vectors pointed to by VBAR and MVBAR. The MVBAR determines how [[SMC]] calls are handled and is the entry point to secure world. Other modules' initialization functions invoke [[SceExcpmgr]] functions to register [[SMC]] handlers. When [[SceSblSmsched]] is initialized, it initialized the security processor with <code>kprx_auth_sm.self</code> and <code>prog_rvk.srvk</code> found in memory. After this point is likely when signature revocation would take effect. The [[Libraries#Secure Kernel|other Tzs modules]] are loaded, then the [[TrustZone]] DRAM region (0x40000000-0x40300000 on FW 1.69, 0x40200000 on later firmwares ?which?) are set up in hardware, and after that, the [[Secure World]] is completely loaded.
Next the ARM Secure Kernel is loaded with the stripped down module manager (equivalent to [[SceKernelModulemgr]]) inside the kernel boot loader. First [[SceSysmem]], which on newer FWs is [[ARZL]] compressed, is decompressed to scratch space at <code>0x1C000000</code>. Then the ELF loader loads it and the system memory manager's initialization function is called which setups the memory in [[TrustZone]]. This also setups [[KBL Param]] in [[TrustZone]]. Data from physical address <code>0x100</code> is copied to the buffer allocated at offset 0x6C0 (?[[KBL Param]]?) (in FW 1.69 this is 0x46C0). The other ELFs are not compressed and just loaded as-is by the module manager. [[SceExcpmgr]] is loaded next and its initialization function replaces the vectors pointed to by VBAR and MVBAR. The MVBAR determines how [[SMC]] calls are handled and is the entry point to [[TrustZone]]. Other modules' initialization functions invoke [[SceExcpmgr]] functions to register [[SMC]] handlers. When [[SceSblSmsched]] is initialized, it initialized the security processor with <code>kprx_auth_sm.self</code> and <code>prog_rvk.srvk</code> found in memory. After this point is likely when signature revocation would take effect. The other TrustZone modules are loaded, then the [[TrustZone]] DRAM region (0x40000000-0x40300000 on FW 1.69, 0x40200000 on later firmwares ?which?) are set up in hardware, and after that, the [[TrustZone]] is completely loaded.


== Non-Secure Kernel BootLoader ==
== Non-Secure Kernel BootLoader ==

Latest revision as of 04:43, 1 May 2023

The Kernel Boot Loader is (likely) the third stage bootloader of the PS Vita system. It is kernel_boot_loader.self in the Boot Partition. It initializes ARM TrustZone (ARM Secure kernel) through SKBL and ARM Non-secure kernel through NSKBL.

Structure

Kernel Boot Loader ELF consists of 4 segments: SKBL reset vector, SKBL segment 0, SKBL segment 1, NSKBL.

SKBL reset vector

SKBL Reset vector is copied ?by SKBL Segment 0 or by second_loader? from file to physical address 0x40000000.

SKBL Segment 0

This is SKBL executable code followed by Tzs modules.

FW 3.60

Start offset End offset Size Comments
0x0 ?0x1AA3F? ?0x1AA40? SKBL executable code
?0x1AA40? ?0x8EC? 0x1B32C some SKBL data
0x1B32C 0x273C3 0xC098? SceSysmem.elf (ARZL compressed)
0x273C4 0x297EB 0x2428 SceExcpmgr.elf
0x297EC 0x2B507 0x1D1C SceKernelIntrMgr.elf
0x2B508 0x2CD27 0x1820 SceKernelBusError.elf
0x2CD28 0x3094F 0x3C28 SceSblSmsched.elf
0x30950 0x3438F 0x3A40 SceDriverTzs.elf
0x34390 0x370C7 0x2D38 some SKBL data

SKBL Segment 1

This seems to be SKBL data segment.

It contains at least:

  • two corelock contexts
  • initial SKBL stack cookie
  • some pointers to SKBL area
  • device register base
  • zeroed data

NSKBL

See NSKBL.

Boot steps

ARM Kernel BootLoader

It is speculated that the first stage of the secure boot process is the Boot ROM in CMeP which decrypts kernel_boot_loader.self into DRAM and resets the ARM CPU. The stage at this point would have set up DRAM and the eMMC driver. There is no Virtual Memory Addressing at this point. A couple of things are loaded into memory. kprx_auth_sm.self from the SLB2 eMMC partition is located at 0x40000500 (as-is/encrypted). Similarly prog_rvk.srvk is located at 0x40008B00. The VBAR is likely set to 0x40000000, where most handlers point to unhandled exception error code. The SKBL segments are loaded to 0x40020000 (where the reset vector points to) and are in three main parts. The first part is the SKBL code which includes stripped down versions of SceSysmem, SceKernelModulemgr, and initialization code (reset vector points to code in this range). The second part is the TrustZone stored as a series of either plaintext ELFs or ARZL compressed ELF. On FW 1.69, only SceSysmem is ARZL compressed whilst the other TrustZone modules are plaintext ELFs. Additionally, some initialization data is passed in 0x4005A000, 0x0, and 0x100.

Secure Kernel BootLoader - reset

The reset function cleans the cache and resets many CP15 registers. Next it does some more device initialization and prints out the debug string Starting PSP2 Kernel Boot Loader. Core 0 then creates some initialization data from parameters passed in from the previous stage as well as with params hard coded. This includes the VMA for the VBAR, MVBAR, TTBR0, TTBR1, and other configurations. It then turns on virtual memory and maps the defined regions for everything defined above. Other cores wait for this to complete and then just use the initialization data created by core 0. The L2 cache is also setup at this point. After this point, the low-level system is finished initializing.

Secure Kernel BootLoader - TrustZone loading

Next the ARM Secure Kernel is loaded with the stripped down module manager (equivalent to SceKernelModulemgr) inside the kernel boot loader. First SceSysmem, which on newer FWs is ARZL compressed, is decompressed to scratch space at 0x1C000000. Then the ELF loader loads it and the system memory manager's initialization function is called which setups the memory in TrustZone. This also setups KBL Param in TrustZone. Data from physical address 0x100 is copied to the buffer allocated at offset 0x6C0 (?KBL Param?) (in FW 1.69 this is 0x46C0). The other ELFs are not compressed and just loaded as-is by the module manager. SceExcpmgr is loaded next and its initialization function replaces the vectors pointed to by VBAR and MVBAR. The MVBAR determines how SMC calls are handled and is the entry point to TrustZone. Other modules' initialization functions invoke SceExcpmgr functions to register SMC handlers. When SceSblSmsched is initialized, it initialized the security processor with kprx_auth_sm.self and prog_rvk.srvk found in memory. After this point is likely when signature revocation would take effect. The other TrustZone modules are loaded, then the TrustZone DRAM region (0x40000000-0x40300000 on FW 1.69, 0x40200000 on later firmwares ?which?) are set up in hardware, and after that, the TrustZone is completely loaded.

Non-Secure Kernel BootLoader

The NSKBL is stored as an ARZL compressed binary at physical address 0x50000000. The NSKBL is uncompressed to physical address 0x51000000. The reset vector for NSKBL is also found at 0x51000000. The initialization data initially found at 0x100 is copied to 0x40200100 (0x40300100 before FW 3.50) so that non-secure world can access it. SKBL then switches to non-secure world by writing NS to SCR and does a return-from-exception to the non-secure reset vector. The NSKBL has to setup everything (including VMA) again in the non-secure world. The initialization of the non-secure KBL is almost exactly the same as the secure KBL one.

Non-secure Kernel

TODO: Talk about os0:psp2bootconfig.skprx loading and stuff.