Secure Modules: Difference between revisions
m (5 revisions imported) |
m (Yifan Lu moved page Private:Sm modules to Sm modules without leaving a redirect) |
(No difference)
|
Revision as of 21:57, 6 January 2019
sm common code
sm modules are loaded to 0x80B000, then code from that addr is executed.
There is a lot of common code shared between sm: entry, cmd handler, cmd setup, etc
Entry
This is the first code executed in sm. It's located at 0x80B000. It does the following:
- Get random value (stack cookie?)
- call_ctors()
- sm_main()
- call_dtors()
- syscall 1: Unload
- while(1) sleep()
call_ctors/call_dtors
These just call function pointers, basically libc_init_array.
sm_main
It has a memory pool allocated on stack. It's filled with structures for command handlers. Then, it calls main_loop.
main_loop
This uses syscall 4 (RegisterIrqHandler) to register a common handler for incoming commands (cmd_handler). Then it loops while sm is "active". Then it sets handler for commands = null pointer.
cmd_handler
This is the common handler for all incoming commands. It reads paddr from 0xE0000014 and ANDs it with 1 to check validity. It checks that size is valid (>= 0x40 and < 0x1000), copies command buffer into private f00d memory and executes an appropriate command handler.
is_addr_range_arm_NS(addr, size)
This is used by cmd_handler to check if the input address of command buffer is safe. The allowed address ranges are:
- Non-secure DRAM (starting at 0x40200000). Note: this is weird because if configuration (word at 0xE0062260) results in overflow, it does some crazy shit.
- ScePowerScratchPad32KiB
- SceVeneziaSpram