Cmep: Difference between revisions

From Vita Development Wiki
Jump to navigation Jump to search
No edit summary
Line 2: Line 2:


More information can be found in Toshiba documentations. For example: https://toshiba.semicon-storage.com/info/docget.jsp?did=14997&prodName=TMPV7504XBG.
More information can be found in Toshiba documentations. For example: https://toshiba.semicon-storage.com/info/docget.jsp?did=14997&prodName=TMPV7504XBG.
You can find an open source F00D<->ARM TZ protocol implementation at https://github.com/xyzz/f00d.


== Communication ==
== Communication ==
Line 118: Line 116:
=== Command ID ===
=== Command ID ===


There are a total of 14 commands. Below are notes on different commands. Commands pass data through the 0x100 shared buffer (set up in command 0).
There are a total of 14 commands. Below are notes on different commands. Commands pass data through the 0x100 shared buffer that is setup in command 0.


==== 0x0 ====
==== 0x0 ====


This command is used to setup a shared buffer with F00D. First F00D will write in <code>0xE0000000</code> either 0x200 or 0x600 (and if an error happened, 0x400 ?). If the value 0x600 is written, it will first setup a buffer that contains the F00D secure_kernel.enp. First it will write 0x1 to <code>0xE0010000</code> and after that 0x0 to <code>0xE0010000</code>, next, it will wait <code>0xE0010000</code> return 0 and <code>0xE0010004</code> return a value <= 0x0. If everything goes alright, it will clear the low 2 bits of the F00D secure_kernel.enp address (normally at 0x1F850000) and OR it with 0x1 and then write it to <code>0xE0000010</code>. After it, the process is the same that the 0x200. If the value 0x200 is written, it will set the 0x100 sized shared buffer. First the physical address of the buffer is written to <code>0xE0000010</code> and then command 0x0 is written.  
This command is used to setup a shared buffer with F00D. Firstly F00D will write in <code>0xE0000000</code> either 0x200 or 0x600 (and if an error happened, 0x400 ?). If the value 0x600 is written, it will setup a buffer that contains the F00D secure_kernel.enp. It will write 0x1 to <code>0xE0010000</code> and after that 0x0 to <code>0xE0010000</code>, next, it will wait <code>0xE0010000</code> return 0 and <code>0xE0010004</code> return a value <= 0x0. If everything goes alright, it will clear the low 2 bits of the F00D secure_kernel.enp address (normally at 0x1F850000) and OR it with 0x1 and then write it to <code>0xE0000010</code>. After it, the process is the same that the 0x200. If the value 0x200 is written, it will set the 0x100 sized shared buffer. The physical address of the buffer is written to <code>0xE0000010</code> and then command 0x0 is written.  


==== 0x1 ====
==== 0x1 ====
Line 244: Line 242:


Set a 0x80 sized shared buffer.
Set a 0x80 sized shared buffer.
This seems like a SceKernelPARange.


{| class='wikitable'
{| class='wikitable'
Line 253: Line 253:
| 0x0
| 0x0
| 0x4
| 0x4
| paddr
| PA
|-
|-
| 0x4
| 0x4
Line 298: Line 298:
* <code>cry2arm123</code>: handles interrupts 201, 202, 203. This interrupt is sent once an sm command has finished processing (see below).
* <code>cry2arm123</code>: handles interrupts 201, 202, 203. This interrupt is sent once an sm command has finished processing (see below).


=== Executing sm commands ===
=== Executing SM commands ===
 
When a SM is loaded, you can execute a [[F00D_Commands|command it provides]] by writing into registers 0xE0000014, 0xE0000018, 0xE000001C paddr to the command buffer OR'd with 1.


Command buffer structure (as seen on FWs 3.60-3.73):
You can find an open source ARM TZ<->F00D protocol implementation at https://github.com/xyzz/f00d. It allows calling SM commands with a maximum of control over the sent data, received data and timing.
 
{| class='wikitable'
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x4
| Size of header + data
|-
| 0x4
| 0x4
| Command ID
|-
| 0x8
| 0x4
| Command return value is written here by the SM
|-
| 0xC
| 0x4
| unk2
|-
| 0x10
| 0x30
| padding
|-
| 0x40
| variable, chosen by NS Kernel, max=0x1000-0x40
| data buffer
|}


On FW 0.931, and maybe in later prototype FWs, the data buffer is located at offset 0x10 instead of 0x40. Thus we can ask why they added the 0x30 bytes padding.
When a [[SM]] is loaded, you can execute a [[F00D_Commands|command it provides]] by writing into registers 0xE0000014, 0xE0000018, 0xE000001C paddr to the [[F00D_Commands#Request_Buffer|request buffer]] OR'd with 1.


Once result is available, ARM will get an interrupt 201-203. Read status code from 0xE0000004 (or 0xE0000008, 0xE000000C) and confirm you received it by writing it back to the same register.
Once result is available, ARM will get an interrupt 201-203. Read status code from 0xE0000004 (or 0xE0000008, 0xE000000C) and confirm you received it by writing it back to the same register.
Line 348: Line 315:
== Memory ==
== Memory ==


F00D has its own private 128KB memory from <code>0x00800000</code> to <code>0x00820000</code>. Secure Modules are typically loaded to <code>0x0080B000</code>. secure_kernel is loaded to <code>0x00800000</code>.
F00D has its own private 128kB memory from <code>0x00800000</code> to <code>0x00820000</code>. Secure Modules are typically loaded to <code>0x0080B000</code>. secure_kernel is loaded to <code>0x00800000</code>.


== Task states ==
== SM Task states ==


ARM Trust Zone implements a scheduler for sm tasks. Normally, only one task can run on F00D at a time. The external scheduler running on ARM allows to have multiple tasks at once. The following provides an explanation of various states the task can be in.
ARM [[TrustZone]] implements a scheduler for [[SM]] tasks. Normally, only one task can run on F00D at a time. The external SM scheduler running on ARM allows to have multiple tasks at once. The following provides an explanation of various states the task can be in.


{| class='wikitable'
{| class='wikitable'

Revision as of 01:56, 6 June 2020

The F00D processor performs most of the PSVita cryptography tasks including storing and handing of the most secure keys. There is little information about it though. It was named after the e_machine field of the ELF headers, but its official name is CMeP (Control MeP). CMEP is a Toshiba MeP-c5 core.

More information can be found in Toshiba documentations. For example: https://toshiba.semicon-storage.com/info/docget.jsp?did=14997&prodName=TMPV7504XBG.

Communication

Communication seems to go through some sort of FIFO register.

Write

To write, put the double word into 0xE0000010. Next read 0xE0000010 until it returns 0, which indicates the data was read by the F00D processor.

Read

To read, get a double word from 0xE0000000. If it returns 0, no data is available. Otherwise, acknowledge that the data has been read by putting the same data into 0xE0000000.

Extra ports

In addition to the 0xE0000000 and 0xE0000010, the communication with F00D seems to happen with other ports too.

Port Read Write Used by
0xE0000004 YES ? SMC 0x12d, 0x136, 0x137, 0x13B Interrupt 0xC8
0xE0000008 YES ? SMC 0x12d, 0x136, 0x137, 0x13B Interrupt 0xC8
0xE000000C YES ? SMC 0x12d, 0x136, 0x137, 0x13B Interrupt 0xC8
0xE0000014 YES YES Used to send commands to f00d secure module, see Executing sm commands
0xE0000018 YES YES Used to send commands to f00d secure module, see Executing sm commands
0xE000001C YES YES Used to send commands to f00d secure module, see Executing sm commands
0xE0000054 ? YES SMC 0x12d, 0x135, 0x13B, Interrupt 0xC8
0xE0000058 ? YES SMC 0x12d, 0x135, 0x13B, Interrupt 0xC8
0xE000005C ? YES SMC 0x12d, 0x135, 0x13B, Interrupt 0xC8
0xE0010000 YES YES Used by F00D Command 0 to prepare F00D to receive an address that contains the secure_kernel.enp.
0xE0010004 YES ? Used by F00D Command 0 to check if the value written in 0xE0010000 is okay (it should return a value <= 0).

Protocol

A 32-bit command buffer is defined below. The command is sent to the F00D processor with the method listed above.

Bit End Bit Start Name Description
31 16 Size Size of the command buffer
18 13 - Always 0
12 8 ID Command ID
7 1 - Always 0
0 0 Valid Set to 1

Command ID

There are a total of 14 commands. Below are notes on different commands. Commands pass data through the 0x100 shared buffer that is setup in command 0.

0x0

This command is used to setup a shared buffer with F00D. Firstly F00D will write in 0xE0000000 either 0x200 or 0x600 (and if an error happened, 0x400 ?). If the value 0x600 is written, it will setup a buffer that contains the F00D secure_kernel.enp. It will write 0x1 to 0xE0010000 and after that 0x0 to 0xE0010000, next, it will wait 0xE0010000 return 0 and 0xE0010004 return a value <= 0x0. If everything goes alright, it will clear the low 2 bits of the F00D secure_kernel.enp address (normally at 0x1F850000) and OR it with 0x1 and then write it to 0xE0000010. After it, the process is the same that the 0x200. If the value 0x200 is written, it will set the 0x100 sized shared buffer. The physical address of the buffer is written to 0xE0000010 and then command 0x0 is written.

0x1

This command is called by a subroutine of SceSblSmsched#sceSblSmSchedStopForTZS or SceSblSmsched module_start (if an error happened while SceSblSmsched was initializing). This command seems to be used to ask F00D to remove all resource allocated (like shared memory address, secure module loaded, etc), and probably power off or reset it.

0x2

Load a sm.

Offset Size Description
0x0 0x4 num_paddrs
0x4 0x4 paddr_list for sm elf
0x8 0x4 buf_0x40: some 0x40 buffer
0xC 0x4 ctx_0x4
0x10 0x4 ctx_0x8
0x14 0x4 ctx_0xC
0x1C 0x4 field_60: system version (2)
0x20 0x4 partition ID

0x3

Load previously suspended sm.

Offset Size Description
0x0 0x4 num_paddrs
0x4 0x4 paddr_list for suspend buffer
0x8 0x4 buf_0x40: some 0x40 buffer
0xC 0x4 delayed_cmd

0x4

Suspend current sm.

Offset Size Description
0x0 0x4 num_paddrs
0x4 0x4 paddr_list for suspend buffer
0x8 0x4 buf_0x40: some 0x40 buffer
0xC 0x4 delayed_cmd

0x5

Kill current sm.

0x6

Force stop? Called from sceSblSmSchedDeleteAll.

0x7

Unused.

0x8

Unused.

0x9

Set a 0x80 sized shared buffer.

This seems like a SceKernelPARange.

Offset Size Description
0x0 0x4 PA
0x4 0x4 length

0xA

Set the encrypted signed revoke list.

Offset Size Description
0x0 0x4 num_paddrs
0x4 0x4 paddr_list for signed revoke list

0xB

0xC

0xD

0xE

0xF

0x10

Interrupts

There are 4 interrupts that F00D sends. There are only two interrupt handles, however.

  • cry2arm0: handles interrupt 200. This is notifications about current sm status changes (loaded, unloaded, suspended, etc)
  • cry2arm123: handles interrupts 201, 202, 203. This interrupt is sent once an sm command has finished processing (see below).

Executing SM commands

You can find an open source ARM TZ<->F00D protocol implementation at https://github.com/xyzz/f00d. It allows calling SM commands with a maximum of control over the sent data, received data and timing.

When a SM is loaded, you can execute a command it provides by writing into registers 0xE0000014, 0xE0000018, 0xE000001C paddr to the request buffer OR'd with 1.

Once result is available, ARM will get an interrupt 201-203. Read status code from 0xE0000004 (or 0xE0000008, 0xE000000C) and confirm you received it by writing it back to the same register.

Possible results:

  • 1: command executed successfully
  • 3: invalid command ID
  • 5: invalid command buffer paddr (e.g. trying to pass secure memory)
  • 9: SCE_SBL_ERROR_COMMON_EIO

Memory

F00D has its own private 128kB memory from 0x00800000 to 0x00820000. Secure Modules are typically loaded to 0x0080B000. secure_kernel is loaded to 0x00800000.

SM Task states

ARM TrustZone implements a scheduler for SM tasks. Normally, only one task can run on F00D at a time. The external SM scheduler running on ARM allows to have multiple tasks at once. The following provides an explanation of various states the task can be in.

ID Description
1 Created / Suspended (Unloaded)
2 Running
3 Errored (Unloaded)
4 ? (Unloaded)
5 ? (Unloaded)
6 Start/resume requested
7 Suspending
8 ?
9 ?
10 ?
11 Suspend requested
12 ?