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.

Provided handlers' behaviour
SceExcpmgr is mostly responsible for providing a facility that allows installing exception handlers to other modules. However, it also installs some exception handlers from itself.

SceExcpmgr registers an infinite loop as the default exception handler in. For RESET, SVC, RESERVED and IRQ, another infinite loop handler will be installed at priority 7.

SceExcpmgr also installs a priority 7 handler for PABT, DABT and UNDEF. As specified in the Types section, those handlers will panic the kernel if they receive either  or   as their handling code parameter, infinite loop if nested exception count is greater than 1, and call sceKernelSysrootReturnFromExcpToThreadForKernel otherwise.

In addition to this, SceExcpmgr installs a priority 0 handler for PABT, DABT and UNDEF. Those three have a common behaviour: building the, incrementing the nested exception count, clearing some CP14 control registers if needed, loading the   provided by SceSysrootForKernel_118657C6, setting DACR to 0x15450000 (not done in 0.990), zero'ing out   and  , and calling a per-handler callback. The CP14 registers that get zero'ed out are the breakpoint control registers ( - ) if a non-NULL pointer has been provided to SceExcpmgrForKernel_A66DDFA3, and the watchpoint control registers ( - ) if a non-NULL pointer has been provided to SceExcpmgrForKernel_4FF90618.

The PABT handler will then proceed to call the next handler in chain. (In 0.990, the UNDEF handler also does this)

The UNDEF handler will check if the instruction that caused the exception to be raised is a, and replace it with a   then resume execution at the faulting instruction (which is now a  ). Otherwise, the next handler in chain is called. According to the ARM Cortex-A9 TRM, this MCRR instruction is used to program the Preload Engine channels.

The DABT handler will check if the CPU was in Thumb mode (check not done in 0.990), then act according to the following logic:
 * if the faulting instruction resides between  (included) and   (excluded) provided by SceCpuForKernel_9A3281C0, and is either ,  ,  ,  ,  ,  ,   or  ), then execution is resumed at the address located in  . This is used by functions like SceSysmem.
 * if the previous check fails, and the faulting instruction resides between  (included) and   provided to SceExcpmgrForKernel_C45C0D3D,   is copied into   and execution is resumed at the instruction right after the faulting one (3 instructions after the faulting one in old firmwares). This mechanism seems to be unused in 3.65.
 * otherwise, the next handler in chain is called.

Note that, in the situation where the ranges provided by SceCpuForKernel_9A3281C0 and SceExcpmgrForKernel_C45C0D3D overlap, the former takes priority. This means that exceptions raised from code residing in the overlap will be handled as if it only belonged in the first range.

If the DABT or UNDEF handlers return, CP14 registers are restored from either the global variables set previously by SceExcpmgrForKernel_4FF90618 and SceExcpmgrForKernel_A66DDFA3, or interrupted thread's TPIDRPRW->0x18->0xC if the TPIDRPRW is non-NULL. If no breakpoint restore structure has been provided to SceExcpmgrForKernel_A66DDFA3, then watchpoints will not be restored regardless of whether something was provided to SceExcpmgrForKernel_4FF90618 or not.

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.

The syscall handler in FW 3.65 is located at offset 0xF40 in SceKernelIntrMgr's  segment.

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.

sceKernelPanicHandlerReturnFromNestedExceptionCfuncForKernel
This name is probably incorrect.

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
Called by SceProcessmgr during.

Sets the structure CP14 watchpoint registers will be restored from if TPIDRPRW of thread that raised an exception is NULL (Kernel process). See SceExcpmgr for more information.

SceExcpmgrForKernel_A66DDFA3
Called by SceProcessmgr during.

Sets the structure CP14 breakpoint registers will be restored from if TPIDRPRW of thread that raised an exception is NULL (Kernel process). See SceExcpmgr for more information.

SceExcpmgrForKernel_7ADF11DB
Sets a callback function ran by the default DABT exception handler before trying to handle the exception.

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

SceExcpmgrForKernel_C45C0D3D
Sets the "memory access error area" range. See SceExcpmgr for more information.

In older firmwares (0.990), this range is acquired during the call to SceCpuForKernel_9A3281C0 in SceExcpmgr  instead.

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.