Difference between revisions of "Services"
| Line 3: | Line 3: | ||
When a service is registered, [[SVC|svcCreatePort]] is used without a port-name. This means that the port is inaccessible via the port SVCs outside of sm-module. See below for getting a session handle for sending commands to services. | When a service is registered, [[SVC|svcCreatePort]] is used without a port-name. This means that the port is inaccessible via the port SVCs outside of sm-module. See below for getting a session handle for sending commands to services. | ||
| − | Processes with PID less than or equal to the number of NATIVE_FIRM built-in modules (fs, sm, pm, pxi, ldr) have access to all services. This value is obtained from [[SVC|svcGetSystemInfo]]. | + | Processes with PID less than or equal to the number of NATIVE_FIRM built-in modules (fs, sm, pm, pxi, ldr) have access to all services. This value is obtained from [[SVC|svcGetSystemInfo]]. Other processes are limited to access services listed in their [[NCCH/Extended_Header#ARM11_Local_System_Capabilities|service access control list]], as passed to [[SRVPM:RegisterProcess]]. |
Attempting to use [[SRV:GetServiceSession|GetServiceSession]] with a service that the process has access to when that service isn't registered, results in [[SVC|svcSendSyncRequest]] never returning(the exact cause is unknown). | Attempting to use [[SRV:GetServiceSession|GetServiceSession]] with a service that the process has access to when that service isn't registered, results in [[SVC|svcSendSyncRequest]] never returning(the exact cause is unknown). | ||
Revision as of 18:16, 29 April 2016
Services are an abstraction of ports and are the commonly used way of inter-process communication outside of the kernel. While handles of regular ports are retrieved from svcConnectToPort, service handles are retrieved through the port srv: ("service manager").
When a service is registered, svcCreatePort is used without a port-name. This means that the port is inaccessible via the port SVCs outside of sm-module. See below for getting a session handle for sending commands to services.
Processes with PID less than or equal to the number of NATIVE_FIRM built-in modules (fs, sm, pm, pxi, ldr) have access to all services. This value is obtained from svcGetSystemInfo. Other processes are limited to access services listed in their service access control list, as passed to SRVPM:RegisterProcess.
Attempting to use GetServiceSession with a service that the process has access to when that service isn't registered, results in svcSendSyncRequest never returning(the exact cause is unknown).
Service Manager Port "srv:"
| Command Header | Description |
|---|---|
| 0x00010002 | RegisterClient |
| 0x00020000 | EnableNotification |
| 0x00030100 | RegisterService |
| 0x000400C0 | UnregisterService |
| 0x00050100 | GetServiceHandle |
| 0x000600C2 | RegisterPort |
| 0x000700C0 | UnregisterPort |
| 0x00080100 | GetPort |
| 0x00090040 | Subscribe |
| 0x000A0040 | Unsubscribe |
| 0x000B0000 | ReceiveNotification |
| 0x000C0080 | PublishToSubscriber |
| 0x000D0040 | PublishAndGetSubscriber |
| 0x000E00C0 | IsServiceRegistered |
Service Manager Process-Manager Port/Service "srv:pm"
| Command Header (port), prior to 7.0.0-13 | Command Header (service), post 7.0.0-13 | Description |
|---|---|---|
| 0x04010042 | 0x00010042 | PublishToProcess |
| 0x04020040 | 0x00020040 | PublishToAll |
| 0x04030082 | 0x00030082 | RegisterProcess |
| 0x04040040 | 0x00040040 | UnregisterProcess |
Prior to to 7.0.0-13, the commands listed for "srv:" were also accessible under this port with the same command-headers. Starting with 7.0.0-13, the "srv:pm" port was changed to a service. With this change, commandIDs for these commands were changed. "srv:pm" was originally vulnerable, this was fixed with 7.0.0-13, see here. Originally any process could use "srv:pm", however starting with 7.0.0-13 only the built-in NATIVE_FIRM sysmodules have access to it. The only system title which uses "srv:pm" is the Process Manager.
Notifications
| ID | Description |
|---|---|
| 0x100 | This indicates that all processes must terminate: power-off, reboot, or FIRM-launch. |
| 0x104 | This indicates that the system is entering sleep mode. (PTM:NotifySleepPreparationComplete needed for this and the following?) |
| 0x105 | This indicates that the system has exited sleep mode. |
| 0x107 | Unknown. Subscribed to by CECD module. |
| 0x108 | error at boot? |
| 0x109 | ? (Subscribed to by GSP) |
| 0x10C | Unknown. |
| 0x110-0x11F | Unknown. See PM launch flags. |
| 0x179 | Unknown. |
| 0x202 | POWER button pressed |
| 0x203 | POWER button held long |
| 0x204 | HOME button pressed |
| 0x205 | HOME button released |
| 0x206 | This is signaled by NWMEXT:ControlWirelessEnabled and when the physical Wi-Fi slider is enabled |
| 0x207 | SD card inserted |
| 0x208 | Game cartridge inserted |
| 0x209 | SD card removed |
| 0x20A | Game cartridge removed |
| 0x20B | Game cartridge inserted or removed |
| 0x20C | mcu-module publishes this on a (fatal) hardware condition?, ptm throws fatal error F960D407 in receipt of this |
| 0x20D | ? (Subscribed to by GSP) |
| 0x20E | ? (Subscribed to by GSP) |
| 0x213 | ? (Subscribed to by GSP) |
| 0x214 | ? (Subscribed to by GSP) |
| 0x302 | Unknown. Signaled by nwm module. |
| 0x303 | Unknown. Subscribed to by CECD module. |
| 0x304 | Unknown. Subscribed to by CECD module. |