SceExcpmgr

SceExcpmgr is a kernel module that sets up exception handling. A version exists in both non-secure and secure worlds. In non-secure world, after the kernel is booted up, the exception handlers pointed to by VBAR all jump into code in this module.

Module
This module exists in both non-secure and secure world. The non-secure world SELF can be found in.

Libraries
This module only exports kernel libraries.

Non-exported functions
The following table contains offsets (from the base of /segment 0) to non-exported functions whose name is known:

sceKernelRegisterExceptionHandlerForKernel
Temp name was sceExcpmgrRegisterHandlerForKernel.

Installs an exception handler. The exception handler can be ARM code or Thumb code. Allowed  values are from 0 (most important) to 7 (least important), including them. Specifying priority 0 will install the handler directly in VBAR, which means its code will run directly when an exception raises (and as such it needs to build the exception context itself). must be set if the handler function is Thumb code.

The syscall handler in FW 1.50 is SceExcpmgr_func_0x81000E40.

sceKernelRegisterDefaultExceptionHandlerForKernel
Installs an exception handler for all exceptions. If no exception handler is already installed for an exception, the handler will be installed in the VBAR. must be the same parameter that would be passed to sceKernelRegisterExceptionHandlerForKernel.

sceKernelReleaseExceptionHandlerForKernel
Uninstalls an exception handler.

Pass the same arguments as provided to sceKernelRegisterExceptionHandlerForKernel.

sceKernelInitialHandlerDebugUndefCfuncForKernel
Logs some information about the CPU state and backtrace then returns. Freezes with an infinite loop if currentHandlerIndex is superior to 1.

sceKernelInitialHandlerDebugPabtCfuncForKernel
Logs some information about the CPU state and backtrace then returns. Freezes with an infinite loop if currentHandlerIndex is superior to 1.

sceKernelInitialHandlerDebugDabtCfuncForKernel
Logs some information about the CPU state and backtrace then returns. Freezes with an infinite loop if currentHandlerIndex is superior to 1.

SceExcpmgrForKernel_A90AC525
Returns a pointer to the handler previously registered by sceKernelRegisterDefaultExceptionHandlerForKernel.

sceKernelGetExcpStackBottomForKernel
Returns the exception stack bottom for specified CPU core. The stack bottom is the highest address of the stack.

Reimplementation code:

sceKernelGetExcpDataForKernel
This is a guessed name. Temp name was sceExcpmgrGetDataForKernel.

Get exception data pointer (for use by handlers).

SceExcpmgrForKernel_3AE9AEE1
Sets a callback function ran by the default UNDEF exception handler before calling the next handler in the chain.

SceExcpmgrForKernel_4FF90618
Sets whether or not watchpoint control debug registers (DBGWCR0-DBGWCR4) should be left untouched by the UNDEF/DABT/PABT handlers. Registers are otherwise zero'ed out.

SceExcpmgrForKernel_7ADF11DB
Sets a callback function ran by the default DABT exception handler before calling the next handler in the chain.

SceExcpmgrForKernel_8D223205
Sets a callback function ran by the default PABT exception handler before calling the next handler in the chain.

SceExcpmgrForKernel_A66DDFA3
Sets whether or not breakpoint control debug registers (DBGBCR0-DBGBCR5) should be left untouched by the UNDEF/DABT/PABT handlers. Registers are otherwise zero'ed out.

SceExcpmgrForKernel_C45C0D3D
Set the "memory access error range". If a DABT exception occurs and PC is located in the range (inclusive) provided by this function, a subroutine of the default DABT handler will return  which in turn makes the handler return to the instruction right after the faulting one.

SceExcpmgrForKernel_D464A9A7
Returns the current nested exception count, or 0 if current TPIDRPRW is non-NULL.

SVC
SVC (Supervisor Call), more commonly called Syscalls (system calls), is what allows to interact with non-secure kernel from usermode.

The SVC interface is defined in non-secure kernel as:

On return, R1-R3 and R12 are cleared to 0x0 or 0xDEADBEEF to prevent any data leaks. All user pointers passed to syscalls are accessed with ARM instructions LDRT and STRT for hardware forced permission checks. Syscalls 0x0 - 0xFF are likely a "fastcall" interface that do not mask interrupts or set the DACR, however currently are no such fastcalls defined. Syscalls 0x100 - 0xFFF are made with IRQ interrupts masked and DACR set to 0xFFFF0000 (to prevent access to certain memory domains). Any other syscall numbers are invalid.

System calls are handled in "system" mode defined in ARMv7 (mode 0b11111).

User exported functions loaded by SceKernelModulemgr are exported as syscalls. The number assigned to the syscall are randomized with respect to each library but not within a library. That means, for example, two functions exported by a library will always be some syscall number apart even though that number will change on each boot.

There is no SVC in secure world because all code in secure world is running as kernel.

SMC
SMC (Secure Monitor Call) is what allows to interact with ARM TrustZone from non-secure kernel.

The SMC interface for making a non-secure kernel call to secure kernel is:

The SMC interface is very similar to the SVC interface. The SMC handler and MVBAR is set up in Secure World by SceExcpmgrForTZS.

0x0 - 0xFF are fast service calls. 0x100 - 0xFFF are normal service calls ran with IRQs masked.

Secure services are ran in ARM system processor mode (0b11111) in the Secure World.

SMC calls are registered by SceIntrmgrForTZS functions.

Aborts
On development units, data and prefetch aborts can handle  instruction for software breakpoints. SceDebug uses this to handle usermode breakpoints. There is no built-in support for  in kernel code.

SceSysmem uses data aborts with the  and   instructions to implement user pointer checking. When LDRT/STRT throws a MMU data exception because of an invalid access and the exception came from SceSysmem or SceSysmem or related functions, the data abort handler will resume execution.

IRQ
IRQs are only handled in non-secure world. An IRQ in secure world is fatal. See SceKernelIntrMgr.

FIQ
FIQs are only handled in secure world because of the bit set in the SCR. Because of this, it is likely that secure devices such as the F00D Processor use FIQs to communicate with the Cortex A9 cores. See SceKernelIntrMgr.