Difference between revisions of "IOS"

From WiiBrew
Jump to navigation Jump to search
m (→‎IPC: IPC link)
(46 intermediate revisions by 14 users not shown)
Line 1: Line 1:
 
{{TOCright}}
 
{{TOCright}}
 +
:''Not to be confused with Apple's iOS, which runs on the iPhone, which was released half a year after the Wii, or [https://wiiubrew.org/wiki/IOSU IOSU], which runs on the Wii U, sometimes referred to as IOS.''
  
'''IOS''' is the operating system that runs on the [[Starlet]] coprocessor inside the [[Hollywood]] package. It provides the services that are used by Wii code to access most of the system devices.
+
'''IOS''' (presumably an initialism for Independent Operating System) is the operating system that runs on the [[Hardware/Starlet|Starlet]] (IOP) coprocessor ([https://wiiubrew.org/wiki/Hardware/Starbuck Starbuck] on the [[vWii]]) inside the [[Hollywood]] package. It provides services that are used by Wii code to access many system devices: USB, networking, security, app management, NAND flash storage, SD card, optical disc, and also WiiConnect24 features.
  
IOS is a somewhat unique system in that many games use (and come with) their own version of the IOS, though many games use the same IOS versions. There is no "true" version of the operating system, instead there are many of what could be called "slots" for different versions of IOS to sit in. IOS versions are not aware of each other, and are not used or invoked at all unless software specifically requests to run using them. In this way it can be considered "safe" to install custom IOS modules, or to patch any IOS module so long as it is not used by the system menu, as if it becomes corrupt it can be deleted and replaced without damaging the system as a whole.
+
All software using the Wii SDK or [[libogc]] relies on a running IOS on the Starlet (with a few exceptions in the latter case - it is possible to shut down IOS services from libogc and work without it). Typically, the only times IOS is not in use is when running GameCube software (which uses [[MIOS]] instead - effectively a dummy IOS), or when [[BootMii]] and related software is in use (which uses [[mini]] instead).
  
It should be noted that the IOS does not act as a hypervisor, the "Home" menu you see when you press the Home button is part of the game, it is not provided by the running IOS or the System Menu. To put it simply, the games does not run "on top of" the system menu. When a game is launched the system menu is closed and the game is started, and when the game calls to return to the system menu, the game closes and the system menu is restarted. There can only be one IOS running at a time.
+
IOS is versioned in a somewhat unique way. Instead of there being a single canonical version of IOS, there are multiple branches, each typically corresponding to one or more versions of the Wii SDK. Each branch is apparently specified to have a completely frozen API, and old versions are only updated to patch bugs (often security bugs) - Nintendo at one point created an entirely new IOS branch that differed only in the default value for the TCP buffer size. A fully updated Wii contains one copy of the latest version of each branch of IOS. On a Wii, these are installed as separate titles, often called "IOS slots". Due to this design, it is generally considered safe to uninstall, reinstall, or patch an IOS or IOS module, as long as it is not the slot used by the System Menu - if anything goes wrong, the broken version can be safely uninstalled and a vanilla copy reinstalled. IOS slots have title IDs 1-3 through 1-255. Unused (high) IOS slots are often used to install patched versions of IOS or alternative Starlet software (e.g. [[BootMii]] as IOS is installed as IOS254, which when invoked will subsequently load armboot.bin from the SD card, typically [[mini]]). See [[IOS History]] for a comprehensive list of IOS slots and versions.
  
The only times an IOS is not running is during GameCube mode (during which time [[MIOS]] is running instead), or when [[BootMii]] is running (during which time [[mini]] is running instead).
+
IOS is not a "hypervisor", as it runs on a dedicated, separate CPU. However, IOS does isolate its memory from access by the main [[Hardware/Broadway|Broadway]] CPU, has the ability to reboot (and hence bootstrap) it, and is designed to be secure if the PowerPC side is compromised (although in practice many exploits have been found). In that sense, IOS is higher in the security hierarchy than code running on the PowerPC.
 +
 
 +
Since the IOS API is largely forwards-compatible, it is often possible (though not recommended) to run official software with an alternate IOS branch or slot. Homebrew software will often run under a relatively large range of IOS versions, sometimes constrained by requiring newer features (e.g. USB EHCI support).
 +
 
 +
When the Wii is in WiiConnect24 standby mode (yellow LED), the main PowerPC CPU is off, but IOS is still running.
  
 
== See Also ==
 
== See Also ==
Line 14: Line 19:
 
*[[IOS/Syscalls|IOS Syscalls]]
 
*[[IOS/Syscalls|IOS Syscalls]]
 
*[[IOS/Syscall IDAPython|Syscall IDAPython]]
 
*[[IOS/Syscall IDAPython|Syscall IDAPython]]
*[[IOS/struct iovec|Struct IOVEC]]
+
*[[IOS/Resource request|Resource request]]
 
*[[IOS/IoBuffer|IoBuffer]]
 
*[[IOS/IoBuffer|IoBuffer]]
*[[IOS/resource request|Resource request]]
+
*[[ARM Binaries]]
 +
*[[/vWii IOS List|vWii IOS List]]
 +
 
 +
== Architecture ==
 +
IOS is a Nintendo-proprietary, embedded operating system. It uses a microkernel architecture, where independent processes communicate using a standard file API (open/read/write/seek/ioctl/ioctlv/close) on resources identified by /dev/ entries in a virtual filesystem hierarchy. Real filesystems (chiefly the NAND filesystem) are also mounted this way (the NAND driver registers itself as the fallback handler for the root node, /).
  
== IPC ==
+
=== Kernel ===
 +
The kernel is the piece of code that is launched first; it consists of a small ELF-loader header followed by the ELF executable of the kernel proper. In addition to the core microkernel and the cryptography core, it contains the bare minimum set of processes/drivers necessary to load the rest of the modules from the NAND filesystem: FFS (Flash Filesystem), ES (E-Ticket Services), and IOSP (responsible for booting and managing the Broadway and its IPC interface). Older IOS versions (prior to [[IOS28]]) were monolithic and contained all modules inside the single main ELF kernel. [[boot2]] is essentially a standalone IOS kernel with no additional modules or drivers, whose sole purpose is to locate the [[System Menu]]'s IOS and launch it.
  
Communication with IOS from PPC code is done using an IPC mechanism. There are 7 calls that can be made using this system:
+
The IOS kernel is able to handle up to 100 threads.
 +
 
 +
=== IPC ===
 +
 
 +
Communication with IOS from PPC code is done using an [[Hardware/IPC|IPC]] mechanism. There are 7 calls that can be made using this system:
  
 
# open
 
# open
Line 29: Line 43:
 
# ioctl
 
# ioctl
 
# ioctlv
 
# ioctlv
 +
 +
There is one more cmd value (8) that is used for messages that are automatically sent to an IOS queue when an asynchronous syscall completes.
  
 
  ipc struct size = 0x40, aligned to 0x20
 
  ipc struct size = 0x40, aligned to 0x20
 
   
 
   
  00:    cmd    // 1=open 2=close 3=read 4=write 5=seek 6=ioctl 7=ioctlv
+
  00:    cmd    // 1=open 2=close 3=read 4=write 5=seek 6=ioctl 7=ioctlv 8=async response
 
  04:    ret
 
  04:    ret
  08:    fd
+
  08:    fd     // file handle returned by open that is passed to other calls
  0c:    arg[5]
+
  0c:    arg[5] // see below
 +
// IOS does not care about data beyond here
 
  20:    async1
 
  20:    async1
 
  24:    async2
 
  24:    async2
  28:    0
+
  28:    padding // all zeros
 
  3F:    relaunch, used for ioctlvreboot
 
  3F:    relaunch, used for ioctlvreboot
 
   
 
   
Line 65: Line 82:
 
         arg2: # out (or in-out)
 
         arg2: # out (or in-out)
 
         arg3: pointer to # in plus # out pairs of (addr, len)
 
         arg3: pointer to # in plus # out pairs of (addr, len)
 +
 +
async:  ret: result from asynchronous syscall
 +
        arg[0-5]: will be untouched from when the ipcmessage struct was passed to the syscall, so you can put whatever you like in them beforehand.
 +
 +
Most non-trivial operations are performed by opening one of the below resources, then calling ioctl or ioctlv on it.
 +
 +
The Starlet kernel hands these calls over to the individual drivers / processes within the Starlet. The processes register themselves to handle requests by creating one or more queues and assigning them to handle requests from a particular /dev device. The IPC interface is essentially identical to the internal microkernel inter-process communication system calls, and indeed maps directly: PPC requests are marshalled by IOSP and appear to come from its process ID to other IOS modules. Oversights in checking whether a request comes from another IOS module or the PowerPC have resulted in several exploitable bugs.
  
fd is a handle you get back from ios on "open", and that you should pass back to all other calls --segher
+
=== Modules ===
 +
IOS modules are ELF executables contained in separate title content entries within an IOS title. Modules roughly map to processes and drivers inside the kernel. The shared-content mechanism allows different IOS slots to reuse the same module binaries when they have not changed, to save space in the console's Flash memory.
  
Most non-trivial operations are performed by opening one of the below resources, then calling ioctl or ioctlv on it.
+
{|class="wikitable"
 +
|+ List of processes in IOS59
 +
|-
 +
! PID !! Name !! Notes
 +
|-
 +
| 0 || Kernel ||
 +
|-
 +
| 1 || ES || ES sets its own UID and GID to 0 on startup.
 +
|-
 +
| 2 || FS ||
 +
|-
 +
| 3 || DI ||
 +
|-
 +
| 4 || OH0 ||
 +
|-
 +
| 5 || OH1 ||
 +
|-
 +
| 6 || EHCI ||
 +
|-
 +
| 7 || SDI ||
 +
|-
 +
| 8 || USB Ethernet ||
 +
|-
 +
| 9 || Net ||
 +
|-
 +
| 10 || WD ||
 +
|-
 +
| 11 || WL ||
 +
|-
 +
| 12 || KD ||
 +
|-
 +
| 13 || NCD ||
 +
|-
 +
| 14 || STM ||
 +
|-
 +
| 15 || PPCBOOT || Requests from the PPC (via the IPC mechanism) appear to come from this process.
 +
|-
 +
| 16 || SSL ||
 +
|-
 +
| 17 || USB || Several internal USB modules check the UID to make sure their resource managers can only be opened from [[:/dev/usb/usb]].
 +
|-
 +
| 18 || P2P (?) ||
 +
|-
 +
| 19 || Unknown || Literally "unknown" in IOS. This PID is used by the WFS modules.
 +
|-
 +
|}
  
The Starlet kernel hands these calls over to the individual drivers / processes within the Starlet. The processes register themselves to handle requests by creating one or more queues and assigning them to handle requests from a particular /dev device.
+
Each process has an associated UID and GID, which can be only changed by the kernel or ES (PID <= 1). This is notably used to enforce filesystem permissions for requests coming from the PPC (PID 15), or to keep some resource managers and ioctls/ioctlvs internal to IOS itself.
  
== IOS Modules ==
+
Each process's UID and GID default to their PID.
IOS is a Nintendo-proprietary, embedded operating system. It uses a microkernel architecture, with several independent modules that talk to each other via "resources", which are organized as entries in the /dev tree.
 
  
=== Kernel ===
+
==== Kernel ====
The Kernel is the piece of code that is actually booted; it contains a small ELF-loader header at the beginning, and then is an ELF file. In addition to the core microkernel stuff, it contains the bare minimum drivers necessary to read the rest of the drivers from the NAND filesystem -- specifically, FFS (Flash Filesystem), ES (E-Ticket Services), and IOSP (Responsible for booting and managing Broadway?).
+
* [[:/dev/aes]]
 +
* [[:/dev/hmac]]
 +
* [[:/dev/sha]]
  
 
==== FFS ====
 
==== FFS ====
 +
Flash Filesystem
 +
 
* [[:/dev/boot2]]
 
* [[:/dev/boot2]]
 
* [[:/dev/flash]]
 
* [[:/dev/flash]]
Line 84: Line 157:
  
 
==== ES ====
 
==== ES ====
* [[:/dev/aes]]
+
ETicket Services (title installation/uninstallation and security)
 +
 
 
* [[:/dev/es]]
 
* [[:/dev/es]]
* [[:/dev/hmac]]
 
* [[:/dev/sha]]
 
  
=== DIP ===
+
==== DIP ====
 +
Disc Interface (optical drive I/O, including partition management and hashtree checks)
 +
 
 
* [[:/dev/di]]
 
* [[:/dev/di]]
  
=== ETH ===
+
==== ETH ====
 +
USB-Ethernet driver
 +
 
 
* [[:/dev/net/usbeth/top]]
 
* [[:/dev/net/usbeth/top]]
 +
* Uses one of the USB modules
 +
 +
==== KBD ====
 +
USB Keyboard driver
  
=== KBD ===
 
 
* [[:/dev/usb/kbd]]
 
* [[:/dev/usb/kbd]]
  
=== KD ===
+
==== KD ====
 +
WiiConnect24
 +
 
 
* [[:/dev/net/kd/request]]
 
* [[:/dev/net/kd/request]]
 
* [[:/dev/net/kd/time]]
 
* [[:/dev/net/kd/time]]
  
=== NCD ===
+
==== NCD ====
 +
Network interface management
 +
 
 
* [[:/dev/net/ncd/manage]]
 
* [[:/dev/net/ncd/manage]]
 
* [[:/dev/net/wd/top]] (Yes, this is actually created by NCD, not WD)
 
* [[:/dev/net/wd/top]] (Yes, this is actually created by NCD, not WD)
  
=== OH0/1 ===
+
==== OH0/1 ====
 +
USB OHCI (1.1) driver
 +
 
 +
* [[:/dev/usb/oh0]] for the external USB bus
 +
* [[:/dev/usb/oh1]] for the internal USB bus
 +
* IOS57, 58 and 59: the OH0 module is gone and replaced by the OHCI0 module, which seems to implement a different, internal interface, similar to [[:/dev/usb/ehc]]
 +
 
 +
==== EHCI ====
 +
Present in IOS58. This module seems to be internally used as USB 2.0 backend for /dev/usb/usb.
 +
 
 
* [[:/dev/usb/ehc]]
 
* [[:/dev/usb/ehc]]
* [[:/dev/usb]]
 
* [[:/dev/usb/oh0]]
 
* [[:/dev/usb/oh1]]
 
  
=== SDI ===
+
==== USB ====
 +
Present in IOS57, 58 and 59. This appears to be used internally by USB frontends (VEN, HID and MSC).
 +
 
 +
* [[:/dev/usb/usb]]
 +
* Uses [[:/dev/usb/ehc]]
 +
* Uses [[:/dev/usb/oh0]]
 +
 
 +
==== USB_VEN ====
 +
Present in IOS57, 58 and 59.
 +
 
 +
* [[:/dev/usb/ven]]
 +
* Uses [[:/dev/usb/usb]]
 +
 
 +
==== USB_HID ====
 +
There are two versions of this module: v4 and v5 (based on what the GETVERSION ioctl returns). v4 is in at least IOS37 and 60, while v5 is present in IOSes which have the USB module.
 +
 
 +
* [[:/dev/usb/hid]]
 +
* Uses [[:/dev/usb/usb]] in the v5 version
 +
 
 +
==== USB_HUB ====
 +
Present in IOS57, 58, 59. Its purpose is unknown.
 +
 
 +
* [[:/dev/usb/hub]]
 +
* Uses [[:/dev/usb/usb]]
 +
 
 +
==== USB_MSC ====
 +
Present in IOS57, 58, 59. It may be used for Mass Storage.
 +
 
 +
* [[:/dev/usb/msc]]
 +
* Uses [[:/dev/usb/usb]]
 +
 
 +
==== USB_SHARED ====
 +
Only present in IOS59. It is only used by the WFSI module.
 +
 
 +
* [[:/dev/usb/shared]]
 +
 
 +
==== WFSI ====
 +
Only present in IOS59. Used for installing WFS content (?)
 +
 
 +
* [[:/dev/wfsi]]
 +
* Uses [[:/dev/es]], likely for encryption
 +
* Uses [[:/dev/fs]]
 +
* Uses [[:/dev/usb/shared]]
 +
 
 +
==== WFSKRN ====
 +
Only present in IOS59. WFS kernel? It seems to implement some sort of filesystem and uses encryption.
 +
 
 +
* [[:/dev/usb/wfssrv]] - WFS service?
 +
* Uses [[:/dev/es]], likely for encryption
 +
* Uses [[:/dev/fs]]
 +
* Uses [[:/dev/usb/msc]] for Mass Storage
 +
 
 +
==== SDI ====
 +
SDHCI (SD card host) driver
 +
 
 
* [[:/dev/sdio/slot0]]
 
* [[:/dev/sdio/slot0]]
 
* [[:/dev/sdio/slot1]]
 
* [[:/dev/sdio/slot1]]
  
=== SO ===
+
==== SO ====
 +
TCP/IP stack (sockets)
 +
 
 
* [[:/dev/net/ip/top]] - TCP/IP [[Socket]] operations
 
* [[:/dev/net/ip/top]] - TCP/IP [[Socket]] operations
 
* [[:/dev/net/ip/bottom]]
 
* [[:/dev/net/ip/bottom]]
Line 122: Line 267:
 
* Opens [[:/dev/net/usbeth/top]]
 
* Opens [[:/dev/net/usbeth/top]]
  
=== SSL ===
+
==== SSL ====
 +
SSL sockets
 +
 
 
* [[:/dev/net/ssl]]
 
* [[:/dev/net/ssl]]
  
=== STM ===
+
==== STM ====
 +
Power and LED/etc management (State Transition Manager?)
 +
 
 
* [[:/dev/stm/eventhook]]
 
* [[:/dev/stm/eventhook]]
 
* [[:/dev/stm/immediate]]
 
* [[:/dev/stm/immediate]]
 +
* Opens [[:/dev/net/kd/request]]
 +
 +
==== WD ====
 +
High-level WLAN driver (includes Nintendo DS comms)
  
=== WD ===
 
 
* [[:/dev/net/wd/command]]
 
* [[:/dev/net/wd/command]]
 
* [[:/dev/listen]] ("Indication RM")
 
* [[:/dev/listen]] ("Indication RM")
Line 135: Line 287:
 
* Opens [[:/dev/stm/immediate]]
 
* Opens [[:/dev/stm/immediate]]
  
=== WL ===
+
==== WL ====
 +
Low-level WLAN driver
 +
 
 
* [[:/dev/wl0]]
 
* [[:/dev/wl0]]
 
* Opens [[:/dev/listen]]
 
* Opens [[:/dev/listen]]
  
===?===
+
==== ? ====
 
[[:/dev/printserver]]
 
[[:/dev/printserver]]
  
[[Category:Hardware]]
+
{{Navbox IOS|skipCat=yes}}
[[Category:Software]]
+
[[Category:IOS]]

Revision as of 22:31, 2 June 2021

Not to be confused with Apple's iOS, which runs on the iPhone, which was released half a year after the Wii, or IOSU, which runs on the Wii U, sometimes referred to as IOS.

IOS (presumably an initialism for Independent Operating System) is the operating system that runs on the Starlet (IOP) coprocessor (Starbuck on the vWii) inside the Hollywood package. It provides services that are used by Wii code to access many system devices: USB, networking, security, app management, NAND flash storage, SD card, optical disc, and also WiiConnect24 features.

All software using the Wii SDK or libogc relies on a running IOS on the Starlet (with a few exceptions in the latter case - it is possible to shut down IOS services from libogc and work without it). Typically, the only times IOS is not in use is when running GameCube software (which uses MIOS instead - effectively a dummy IOS), or when BootMii and related software is in use (which uses mini instead).

IOS is versioned in a somewhat unique way. Instead of there being a single canonical version of IOS, there are multiple branches, each typically corresponding to one or more versions of the Wii SDK. Each branch is apparently specified to have a completely frozen API, and old versions are only updated to patch bugs (often security bugs) - Nintendo at one point created an entirely new IOS branch that differed only in the default value for the TCP buffer size. A fully updated Wii contains one copy of the latest version of each branch of IOS. On a Wii, these are installed as separate titles, often called "IOS slots". Due to this design, it is generally considered safe to uninstall, reinstall, or patch an IOS or IOS module, as long as it is not the slot used by the System Menu - if anything goes wrong, the broken version can be safely uninstalled and a vanilla copy reinstalled. IOS slots have title IDs 1-3 through 1-255. Unused (high) IOS slots are often used to install patched versions of IOS or alternative Starlet software (e.g. BootMii as IOS is installed as IOS254, which when invoked will subsequently load armboot.bin from the SD card, typically mini). See IOS History for a comprehensive list of IOS slots and versions.

IOS is not a "hypervisor", as it runs on a dedicated, separate CPU. However, IOS does isolate its memory from access by the main Broadway CPU, has the ability to reboot (and hence bootstrap) it, and is designed to be secure if the PowerPC side is compromised (although in practice many exploits have been found). In that sense, IOS is higher in the security hierarchy than code running on the PowerPC.

Since the IOS API is largely forwards-compatible, it is often possible (though not recommended) to run official software with an alternate IOS branch or slot. Homebrew software will often run under a relatively large range of IOS versions, sometimes constrained by requiring newer features (e.g. USB EHCI support).

When the Wii is in WiiConnect24 standby mode (yellow LED), the main PowerPC CPU is off, but IOS is still running.

See Also

Architecture

IOS is a Nintendo-proprietary, embedded operating system. It uses a microkernel architecture, where independent processes communicate using a standard file API (open/read/write/seek/ioctl/ioctlv/close) on resources identified by /dev/ entries in a virtual filesystem hierarchy. Real filesystems (chiefly the NAND filesystem) are also mounted this way (the NAND driver registers itself as the fallback handler for the root node, /).

Kernel

The kernel is the piece of code that is launched first; it consists of a small ELF-loader header followed by the ELF executable of the kernel proper. In addition to the core microkernel and the cryptography core, it contains the bare minimum set of processes/drivers necessary to load the rest of the modules from the NAND filesystem: FFS (Flash Filesystem), ES (E-Ticket Services), and IOSP (responsible for booting and managing the Broadway and its IPC interface). Older IOS versions (prior to IOS28) were monolithic and contained all modules inside the single main ELF kernel. boot2 is essentially a standalone IOS kernel with no additional modules or drivers, whose sole purpose is to locate the System Menu's IOS and launch it.

The IOS kernel is able to handle up to 100 threads.

IPC

Communication with IOS from PPC code is done using an IPC mechanism. There are 7 calls that can be made using this system:

  1. open
  2. close
  3. read
  4. write
  5. seek
  6. ioctl
  7. ioctlv

There is one more cmd value (8) that is used for messages that are automatically sent to an IOS queue when an asynchronous syscall completes.

ipc struct size = 0x40, aligned to 0x20

00:     cmd     // 1=open 2=close 3=read 4=write 5=seek 6=ioctl 7=ioctlv 8=async response
04:     ret
08:     fd      // file handle returned by open that is passed to other calls
0c:     arg[5]  // see below
// IOS does not care about data beyond here
20:     async1
24:     async2
28:     padding // all zeros
3F:     relaunch, used for ioctlvreboot

open:   fd = 0
        arg0, arg1: name, mode (1=read 2=write)

close:  fd

read:   fd
        arg0, arg1: addr, len

write:  fd
        arg0, arg1: addr, len

seek:   fd
        arg0, arg1: where, whence

ioctl:  fd
        arg0: ioctl #
        arg1, arg2: addr, len
        arg3, arg4: addr, len

ioctlv: fd
        arg0: ioctl #
        arg1: # in
        arg2: # out (or in-out)
        arg3: pointer to # in plus # out pairs of (addr, len)

async:  ret: result from asynchronous syscall
        arg[0-5]: will be untouched from when the ipcmessage struct was passed to the syscall, so you can put whatever you like in them beforehand.

Most non-trivial operations are performed by opening one of the below resources, then calling ioctl or ioctlv on it.

The Starlet kernel hands these calls over to the individual drivers / processes within the Starlet. The processes register themselves to handle requests by creating one or more queues and assigning them to handle requests from a particular /dev device. The IPC interface is essentially identical to the internal microkernel inter-process communication system calls, and indeed maps directly: PPC requests are marshalled by IOSP and appear to come from its process ID to other IOS modules. Oversights in checking whether a request comes from another IOS module or the PowerPC have resulted in several exploitable bugs.

Modules

IOS modules are ELF executables contained in separate title content entries within an IOS title. Modules roughly map to processes and drivers inside the kernel. The shared-content mechanism allows different IOS slots to reuse the same module binaries when they have not changed, to save space in the console's Flash memory.

List of processes in IOS59
PID Name Notes
0 Kernel
1 ES ES sets its own UID and GID to 0 on startup.
2 FS
3 DI
4 OH0
5 OH1
6 EHCI
7 SDI
8 USB Ethernet
9 Net
10 WD
11 WL
12 KD
13 NCD
14 STM
15 PPCBOOT Requests from the PPC (via the IPC mechanism) appear to come from this process.
16 SSL
17 USB Several internal USB modules check the UID to make sure their resource managers can only be opened from /dev/usb/usb.
18 P2P (?)
19 Unknown Literally "unknown" in IOS. This PID is used by the WFS modules.

Each process has an associated UID and GID, which can be only changed by the kernel or ES (PID <= 1). This is notably used to enforce filesystem permissions for requests coming from the PPC (PID 15), or to keep some resource managers and ioctls/ioctlvs internal to IOS itself.

Each process's UID and GID default to their PID.

Kernel

FFS

Flash Filesystem

ES

ETicket Services (title installation/uninstallation and security)

DIP

Disc Interface (optical drive I/O, including partition management and hashtree checks)

ETH

USB-Ethernet driver

KBD

USB Keyboard driver

KD

WiiConnect24

NCD

Network interface management

OH0/1

USB OHCI (1.1) driver

  • /dev/usb/oh0 for the external USB bus
  • /dev/usb/oh1 for the internal USB bus
  • IOS57, 58 and 59: the OH0 module is gone and replaced by the OHCI0 module, which seems to implement a different, internal interface, similar to /dev/usb/ehc

EHCI

Present in IOS58. This module seems to be internally used as USB 2.0 backend for /dev/usb/usb.

USB

Present in IOS57, 58 and 59. This appears to be used internally by USB frontends (VEN, HID and MSC).

USB_VEN

Present in IOS57, 58 and 59.

USB_HID

There are two versions of this module: v4 and v5 (based on what the GETVERSION ioctl returns). v4 is in at least IOS37 and 60, while v5 is present in IOSes which have the USB module.

USB_HUB

Present in IOS57, 58, 59. Its purpose is unknown.

USB_MSC

Present in IOS57, 58, 59. It may be used for Mass Storage.

USB_SHARED

Only present in IOS59. It is only used by the WFSI module.

WFSI

Only present in IOS59. Used for installing WFS content (?)

WFSKRN

Only present in IOS59. WFS kernel? It seems to implement some sort of filesystem and uses encryption.

SDI

SDHCI (SD card host) driver

SO

TCP/IP stack (sockets)

SSL

SSL sockets

STM

Power and LED/etc management (State Transition Manager?)

WD

High-level WLAN driver (includes Nintendo DS comms)

WL

Low-level WLAN driver

?

/dev/printserver