Dispatcher Manager

From PS3 Developer wiki
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)

Packet ID Description
0x18001 Construct Service Port
0x18002 Destruct Service Port
0x18004 Reply

Dispatcher Manager Messages

Dispatcher Manager Header

  • 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

  • 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

  • Returns error code in payload