Dispatcher Manager
Jump to navigation
Jump to search
- Dispatcher Manager runs in Process 3.
- When SLL (Secure LPAR Loader) creates GamesOS LPAR and loads it, it also creates a VUART with port number 10 owned by GameOS using a service provided by Dispatcher Manager (0x18001 - Construct Service Port).
- Dispatcher Manager communicates with GameOS through this VUART. It opens the file /proc/partitions/<LPAR id>/vuart/10. When the file /proc/partitions/<LPAR id>/vuart/10 is opened by Dispatcher Manager, the Hypervisor creates a peer VUART which is connected to the GameOS's VUART 10.
- After that Dispatcher Manager reads requests from this VUART sent by GameOS and dispatches these requests to services (functions) provided by Hypervisor Processes through sockets. Through VUART and Dispatcher Manager, the GameOS LPAR has access to all services provided by Hypervisor Processes.
- However, the services provided by Hypervisor Processes are protected by Security Policy Manager (SPM). Before Dispatcher Manager routes the requests from GameOS to these services, it consults SPM (by using 0x11001 service of SPM) and checks if the GameOS has access rights to the requested service. If not then the request is not routed.
- DM overwrites the LAID sent in SS packet header with the LAID of the LPAR that sent the request. So, no matter what LAID you send in SS packet header, it will be always overwritten with the correct one by DM. That is the reason why e.g. USB Dongle Master Key cannot be decrypted by GameOS without patching DM. But with HV access rights, DM can be easily patched and access to SYSCON can be gained.
- Linux LPAR doesn't have a VUART communication link to Dispatcher Manager.
- I tested VUART 10 on GameOS with PSGroove and it's there.
- On GamesOS, _ss_multiplexer accesses DM (VUART 10)
0x18000 - DM (Dispatcher Manager)[edit | edit source]
| Packet ID | Description |
|---|---|
| 0x18001 | Construct Service Port |
| 0x18002 | Destruct Service Port |
| 0x18004 | Reply |
Dispatcher Manager Messages[edit | edit source]
Dispatcher Manager Header[edit | edit source]
- Payload follows after header
- Payload is a SS packet
struct dispmgr_header
{
uint32_t request_id;
uint32_t function_id;
uint32_t request_size; /* payload size of request */
uint32_t response_size; /* payload size of response */
}
Packet ID - SS ID Mapping[edit | edit source]
- Before DM routes a received request to a service provider (HV Process) it consults SPM
- DM sends a request to SPM
- Request contains SS ID and Subject ID (laid and paid)
- DM obtains SS ID by mapping Packet ID
Here is the mapping table i extracted from HV Process 3 where SPM and DM run:
| Packet ID | SS ID |
|---|---|
| 0x2001 | 0x34 |
| 0x2002 | 0x35 |
| 0x2003 | 0x36 |
| 0x2004 | 0x37 |
| 0x2005 | 0x38 |
| 0x2006 | 0x39 |
| 0x200A | 0x3D |
| 0x200B | 0x3E |
| 0x200C | 0x3F |
| 0x200D | 0x40 |
| 0x200E | 0x41 |
| 0x2012 | 0x7B |
| 0x2013 | 0x7C |
| 0x2014 | 0x7E |
| 0x2015 | 0x7F |
| 0x2016 | 0x7D |
| 0x2017 | 0x80 |
0x18004 - Reply[edit | edit source]
- Returns error code in payload
