In memory of Ben “bushing” Byer, who passed away on Monday, February 8th, 2016.

Difference between revisions of "IOS"

From WiiUBrew
Jump to navigation Jump to search
(Added IOSU kernel error codes)
Line 311: Line 311:
 
*0xEFF00000 - 0xEFF08000 '''Unknown'''
 
*0xEFF00000 - 0xEFF08000 '''Unknown'''
 
*0xFFFF0000 - 0xFFFFFFFF '''Kernel SRAM'''
 
*0xFFFF0000 - 0xFFFFFFFF '''Kernel SRAM'''
 +
 +
 +
 +
The Starbuck MMU itself only has R/W permissions for data/instruction memory access, no XN. However, there is XN implemented via separate hardware registers at 0x0d8b0XXX. The register relative-offset is calculated with the physaddr of the memory being protected. Each u32 register corresponds to a different block of physical memory. Among other things, this controls whether the ARM is allowed to access the memory for instruction-access, and in what ARM-mode(userland/privileged) the instruction-access is permitted.
 +
 +
Hence, userland .text is ''only'' executable from userland. From userland, the ''only'' executable memory is the process .text. In privileged-mode, the ''only'' executable memory is the main kernel .text(0x08120000) and 0xffff0000(the latter is also RWX).
 +
 +
==Exception Handling==
 +
The data-abort and prefetch-abort exception handlers will first check whether a certain flag is clear(flagsfield & (1<<PID)). When that bit is clear and the PID is <=13(highest IOSU PID value that exists), it will just return from the function then do a context-switch. Otherwise, iosPanic() is called.

Revision as of 06:30, 13 December 2015

IOSU is the operating system running on the ARM in Wii U mode. It is the Wii U equivalent of IOS on the Wii, and similar in some regards, but it is a complete rewrite with many changes. IOSU implements the Wii U's security policy, which includes titles and hardware access. One of its primary responsibilities is enforcing code signing, verifying all titles before installation and launch. Another one of its jobs is managing access to most hardware, such as storage, network, USB, and the Gamepad. The PowerPC can talk to IOSU through an IPC interface, and make security and hardware requests.

See Also

Architecture

IOSU is an embedded operating system written by Nintendo, with a microkernel architecture. It contains a simple kernel that implements memory management and process and thread management. Device drivers and security handlers run as processes in the ARM user mode. These processes, called resource managers (RMs), can register as request handlers for resources, which are represented as nodes under /dev in a virtual filesystem. They communicate with each other through the kernel, using standard Unix file operations (open/close/read/write/seek/ioctl/ioctlv).

IPC

PowerPC code is able to call IOSU drivers through an IPC interface. It uses the same call interface as IOSU does internally. Userspace code submits IOSU requests with the IPCKDriver_SubmitRequest() syscall in the Cafe OS kernel. The kernel includes information to identify which Cafe OS process sent the request, allowing IOSU to check permissions on a per-app basis. Requests are contained in a struct, sent through a hardware interface, and marshalled by the IOSU kernel to a target process. 

IPC request struct (size = 0x48, align = 0x20)

0x00: CMD (1=open, 2=close, 3=read, 4=write, 5=seek, 6=ioctl, 7=ioctlv)
0x04: Reply to client
0x08: Client FD
0x0C: Flags (always 0)
0x10: Client CPU (0=ARM internal, 1-3=PPC cores 0-2)
0x14: Client PID (PFID in older versions, RAMPID more recently?)
0x18: Client group ID (Title ID, upper)
0x1C: Client group ID (Title ID, lower)
0x20: Server handle (written by IOSU)
0x24: Arg0
0x28: Arg1
0x2C: Arg2
0x30: Arg3
0x34: Arg4
0x38: CMD (previous)
0x3C: Client FD (previous)
0x40: Virt0 (PPC virtual addresses to be translated)
0x44: Virt1 (PPC virtual addresses to be translated)

IPC commands

0x00 -> IOS_COMMAND_INVALID
0x01 -> IOS_OPEN
0x02 -> IOS_CLOSE
0x03 -> IOS_READ
0x04 -> IOS_WRITE
0x05 -> IOS_SEEK
0x06 -> IOS_IOCTL
0x07 -> IOS_IOCTLV
0x08 -> IOS_REPLY (internal to IOSU)
0x09 -> IOS_IPC_MSG0 (internal to IOSU)
0x0A -> IOS_IPC_MSG1 (internal to IOSU)
0x0B -> IOS_IPC_MSG2 (internal to IOSU)
0x0C -> IOS_SUSPEND (internal to IOSU)
0x0D -> IOS_RESUME (internal to IOSU)
0x0E -> IOS_SVCMSG (internal to IOSU)

IPC client PIDs

On older versions of IOSU, it seems to match the PFID list. More recently, it appears to use the RAMPID. See the Cafe OS PID tables.

IPC arguments

Open CMD:   Client FD == 0
            Arg0 = name
            Arg1 = name_size
            Arg2 = mode (0 = none, 1 = read, 2 = write)

Close CMD:  Client FD != 0

Read CMD:   Client FD != 0
            Arg0 = outPtr
            Arg1 = outLen

Write CMD:  Client FD != 0
            Arg0 = inPtr
            Arg1 = inLen

Seek CMD:   Client FD != 0
            Arg0 = where
            Arg1 = whence

IOCtl CMD:  Client FD != 0
            Arg0 = cmd
            Arg1 = inPtr
            Arg2 = inLen
            Arg3 = outPtr
            Arg4 = outLen

IOCtlv CMD: Client FD != 0
            Arg0 = cmd
            Arg1 = readCount
            Arg2 = writeCount
            Arg3 = vector

Error codes

Kernel errors

0x00000000 -> IOS_ERROR_OK
0xFFFFFFFF -> IOS_ERROR_ACCESS
0xFFFFFFFE -> IOS_ERROR_EXISTS
0xFFFFFFFD -> IOS_ERROR_INTR
0xFFFFFFFC -> IOS_ERROR_INVALID
0xFFFFFFFB -> IOS_ERROR_MAX
0xFFFFFFFA -> IOS_ERROR_NOEXISTS
0xFFFFFFF9 -> IOS_ERROR_QEMPTY
0xFFFFFFF8 -> IOS_ERROR_QFULL
0xFFFFFFF7 -> IOS_ERROR_UNKNOWN
0xFFFFFFF6 -> IOS_ERROR_NOTREADY
0xFFFFFFF5 -> IOS_ERROR_ECC
0xFFFFFFF4 -> IOS_ERROR_ECC_CRIT
0xFFFFFFF3 -> IOS_ERROR_BADBLOCK
0xFFFFFFF2 -> IOS_ERROR_INVALID_OBJTYPE
0xFFFFFFF1 -> IOS_ERROR_INVALID_RNG
0xFFFFFFF0 -> IOS_ERROR_INVALID_FLAG
0xFFFFFFEF -> IOS_ERROR_INVALID_FORMAT
0xFFFFFFEE -> IOS_ERROR_INVALID_VERSION
0xFFFFFFED -> IOS_ERROR_INVALID_SIGNER
0xFFFFFFEC -> IOS_ERROR_FAIL_CHECKVALUE
0xFFFFFFEB -> IOS_ERROR_FAIL_INTERNAL
0xFFFFFFEA -> IOS_ERROR_FAIL_ALLOC
0xFFFFFFE9 -> IOS_ERROR_INVALID_SIZE
0xFFFFFFE8 -> IOS_ERROR_NO_LINK
0xFFFFFFE7 -> IOS_ERROR_AN_FAILED
0xFFFFFFE6 -> IOS_ERROR_MAX_SEM_COUNT
0xFFFFFFE5 -> IOS_ERROR_SEM_UNAVAILABLE
0xFFFFFFE4 -> IOS_ERROR_INVALID_HANDLE
0xFFFFFFE3 -> IOS_ERROR_INVALID_ARG
0xFFFFFFE2 -> IOS_ERROR_NO_RESOURCE
0xFFFFFFE1 -> IOS_ERROR_BUSY
0xFFFFFFE0 -> IOS_ERROR_TIMEOUT
0xFFFFFFDF -> IOS_ERROR_ALIGNMENT
0xFFFFFFDE -> IOS_ERROR_BSP
0xFFFFFFDD -> IOS_ERROR_DATA_PENDING
0xFFFFFFDC -> IOS_ERROR_EXPIRED
0xFFFFFFDB -> IOS_ERROR_NO_R_ACCESS
0xFFFFFFDA -> IOS_ERROR_NO_W_ACCESS
0xFFFFFFD9 -> IOS_ERROR_NO_RW_ACCESS
0xFFFFFFD8 -> IOS_ERROR_CLIENT_TXN_LIMIT
0xFFFFFFD7 -> IOS_ERROR_STALE_HANDLE
0xFFFFFFD6 -> IOS_ERROR_UNKNOWN_VALUE

Modules

Similarly to the Wii, IOS modules roughly map to processes and drivers inside the kernel.

IOS-CRYPTO

Cryptography services.

IOS-MCP

Master title operations such as title launching and cafe2wii booting.

IOS-USB

USB controllers and devices.

IOS-FS

File system services.

IOS-PAD

Gamepad controllers and devices.

IOS-NET

Network services.

IOS-ACP

User level application management.

IOS-NSEC

Network security services.

IOS-NIM-BOSS

Nintendo's proprietary online services such as update installations.

  • /dev/nim - Nintendo installation manager? (installs updates)
  • /dev/boss - BOSS service

IOS-FPD

Nintendo's proprietary friend system.

IOS-TEST

Debugging and testing services.

IOS-AUXIL

Auxiliary services.

IOS-BSP

Hardware.

  • /dev/bsp - Board support package? (hardware interface)

Others

These are not real /dev nodes. Instead, they represent internal mappings of system volumes.

Virtual Memory Map

  • 0x04000000 - 0x04030000 IOS-CRYPTO
  • 0x05000000 - 0x050C0000 IOS-MCP
  • 0x05100000 - 0x05120000 IOS-MCP (debug and recovery mode)
  • 0x08120000 - 0x081C0000 IOS-KERNEL
  • 0x10000000 - 0x10100000 Unknown
  • 0x10100000 - 0x104D0000 IOS-USB
  • 0x10800000 - 0x11EE0000 IOS-FS
  • 0x11F00000 - 0x12160000 IOS-PAD
  • 0x12300000 - 0x12890000 IOS-NET
  • 0x1D000000 - 0x1FB00000 Global heap
  • 0x1FB00000 - 0x1FE00000 Global IOB (input/output block)
  • 0x1FE00000 - 0x1FE20000 Unknown
  • 0x1FE40000 - 0x20000000 Unknown
  • 0x20000000 - 0x28000000 Unknown
  • 0xE0000000 - 0xE0270000 IOS-ACP
  • 0xE1000000 - 0xE12F0000 IOS-NSEC
  • 0xE2000000 - 0xE26D0000 IOS-NIM-BOSS
  • 0xE3000000 - 0xE3300000 IOS-FPD
  • 0xE4000000 - 0xE4160000 IOS-TEST
  • 0xE5000000 - 0xE5070000 IOS-AUXIL
  • 0xE6000000 - 0xE6050000 IOS-BSP
  • 0xE7000000 - 0xE7001000 Unknown
  • 0xEFF00000 - 0xEFF08000 Unknown
  • 0xFFFF0000 - 0xFFFFFFFF Kernel SRAM


The Starbuck MMU itself only has R/W permissions for data/instruction memory access, no XN. However, there is XN implemented via separate hardware registers at 0x0d8b0XXX. The register relative-offset is calculated with the physaddr of the memory being protected. Each u32 register corresponds to a different block of physical memory. Among other things, this controls whether the ARM is allowed to access the memory for instruction-access, and in what ARM-mode(userland/privileged) the instruction-access is permitted.

Hence, userland .text is only executable from userland. From userland, the only executable memory is the process .text. In privileged-mode, the only executable memory is the main kernel .text(0x08120000) and 0xffff0000(the latter is also RWX).

Exception Handling

The data-abort and prefetch-abort exception handlers will first check whether a certain flag is clear(flagsfield & (1<<PID)). When that bit is clear and the PID is <=13(highest IOSU PID value that exists), it will just return from the function then do a context-switch. Otherwise, iosPanic() is called.

Retrieved from "https://wiiubrew.org/w/index.php?title=IOS&oldid=1510"