Drk notes
Varius notes, mostly related to nulldc's development and whatnot. Might be useful for someone wanting to port smth/write dynamic code !
Intro stuff
My assembly pseudo-code will most likely use intel-x86-like syntax, as i find it more descritpive than the cryptic ppc opcode names. Sorry if that makes you unhappy :|
This page will need some formating love soon, i'l get to it...
PPC64 Emitter
PPC 64 emitter and Emitter Helper. This is the complete ppc64 opcode set as found on pem_64bit_v3.0.2005jul15.pdf, generated by my ppc emitter generator. This hasn't been tested, but the wii ppc emitters i did were built the same way, and they did work .. more or less :). The emitter helper doesn't really help much and needs to be worked on.
This might be useful for runtime patches/stuff, and well dynarecs ! If someone wants a runtime disassembler/etc the emitter generator can be modified to generate that -- just drop me a message ....
TODO: ppe emitter with the extra opcodes, add in opcode info/etc, and see about spe !
Getting runtime generated code to run
We cannot run code from the heap (malloc, seems like mmu protection)
We cannot run code from .bss (static array, seems like mmu protection)
Here's what happens when i try to execute code:
lv2(2): # Interrupt(exception) Info.
lv2(2): # Type : Instruction Storage
lv2(2): # SRR0 : 0x0000000000020a2c //Code fetch address
lv2(2): # SRR1 : 0x800000001000c032
lv2(2): # DSISR: 0x0000000002200000
lv2(2): # DAR : 0x000000003000000c
lv2(2): # TB : 0x000000003a7db9b6
We cannot modify existing code (seems like mmu protection)
So for user mode W^X seems to be implemented properly. More tests pending on this.
Also, there are probably calls on lv2 to disable W^X usermode can't generate dynamic code, lv2 seems to be enforcing this, and there are surely lv1 calls for that.
We can run code off the lv2 heap.
Misc ABI notes
ABI seems to be 32 bit more for ppc64
in 32 bit mode, 64 bit registers are visible, and 64 bit opcodes are avaiable. However, only the lower 32 bits are used for memory access (top bits ingored). This all needs to be verfied, all i really know is that sizeof(void*)==4.
Register usage (based off my wii dynarec docs -- might not be 100% correct -- still need to read up the abi docs properly):
Registers: 32 64-bit gprs r0 volatile, temp r1 stack pointer, grows down r2 TOC (what ?) Pointer (who cares) r3:10 voalitle, first 8 params.r3 is also return value r11 volatile (used as 'enviroment' pointers for calls by ptr .. what?) r12 volatie (sed for ming & magic as well as linking) r13:31 preserved (19 of em) 32 64-bit fprs (f32/f64, stored in f64 format always) f0 volatile, scratch f1:4 volatile, params, return f5:13 volatile, params f14:31 preserved (18 of em) 32 128-bit vprs (s/u 8/16/32, f32) LR Link (preserved) XER (exception register,preserved?) VSCR VRSAVE FPSCR CR (CR0:1;CR5:7 volatile, CR2:4 preserved) CTR When calling: Call stack: Return is stored on the link register and its saved at a specific location on function entry lr is stored on sp+4 stack grows towards zero
Function pointers:
Function pointers are actually pointers to a 'function descriptor'. The descriptor holds the address of the function, as well as the rtoc. When a call is made it goes like
struct fnptr_t { void* fun; void* rtoc; };
....
fnptr_t ptr;
.....
mov %rtoc,ptr.rtoc; //set the callee rtoc
call/jump ptr.fun; //call to it, have seen it use btctrl and blrl for this
mov %rtoc,whatever backup; //restore this function's rtoc
Quick PS3 structure intro
(Just my notes on my understanding so far)
lv1: Hypervisor
lv2: "kernel"
usermode : our normal code runs here exploit shellcode runs on lv2, via a heap overflow
lv1
Manages page table delegates decryption to an isolated spe pretty much all security passes through this
lv2
Processes, threads, stuff Interfaces usermode with lv1 for stuff like page mappings etc
Many restrictions are placed here (i believe W^X, among other things) accesses lv1 via ????
-> lv1 access is via hvsc / .long 0x44000022
lv2 has direct access to slb, but not to tlb/htab. It can set/modify htab entries via syscalls
usermode
accesses lv2 via syscalls (sc opcode)
actual app logic, stuff has limited hardware access via lv2
Interesting: seems to have fairly low level access to rsx (direct FIFO), probably syscalls are used to setup registers and stuff
Interesting Links
http://www.linux-kvm.org/page/PowerPC_Hypercall_ABI
http://wiki.ps2dev.org/ps3:hypervisor
Retrieved from "http://ps3wiki.lan.st/index.php/Drk_notes"