secure-mode.html 12.3 KB

Raw Blame History Permalink

<html>
<head>
<title>
	BB Secure Mode Specification
</title>
</head>
<body bgcolor="#ffffff" text="#000000"
  link="#004868" vlink="#986424" alink="#00ffff">

<table width="100%" cellpadding=2 cellspacing=0 border=0>
<tr>
<td bgcolor="#e0e0e0">
	BB Secure Mode Specification
</td>
<td align=right bgcolor="#f0c0c0" width="20%">
<font color=red>
	<b>Broad<i>On</i> confidential</b>
</font>
</td>
</tr>
</table>

<p>
<b> Overview </b>
<p>
	The existing hardware implements various modes and features for
	access control. For example, the kernel/user mode of the cpu limits
	execution privileges on the instruction level and the tlb deals with
	memory protection. One requirement of the BB design is to hand over
	the entire hardware to an application (game, browser, etc). This would
	allow access to all io registers, address spaces and devices. However,
	in a secure environment a mechanism must exist to protect keys and
	code needed for security services. Therefore, a secure and a non-secure
	mode is necessary. In secure mode, all hardware is accessible including
	the keys and security code. In non-secure mode, the keys and security
	code are not accessible. Applications running in non-secure mode must
	make the equivalent of a system call to enters secure mode for service
	of the request. Upon completion, the system returns to non-secure mode.
	One additional requirement is to enter the secure mode periodically to
	facilitate additional checks and to detect intrusions.
<p>
<b> Hardware Requirements </b>
<p>
	Security code and keys need physical memory for storage. In addition,
	writable memory is needed for runtime stack and other variables. It is
	pointless to store them in external components (such as flash) that can
	be accessed and modified easily. Moving these components on-chip raises
	the bar from the board level to the chip level. Hardware must ensure
	that none of the internal accesses are visible on pins, which implies
	that the processor running the security code must be on-chip as well.
	Debug interfaces such a JTAG, scan or dedicated debug signals must be
	disabled to deny access to chip registers and logic.
<p>
<b> Implementation </b>
<p>
	The specific implementation largely depends on the processor running the
	security code. The remainder of this document describes the architecture
	for the secure mode around an embedded MIPS processor. The goal was to
	not change any internals of a supplied processor core, but to put the
	desired functionality into a wrapper around the core. Please refer to a
	MIPS processor manual about the specific topics mentioned.
<p>
	The periodic entering of secure mode requires the use of hardware
	interrupts over which an application has no control. There are two areas
	that are critical in an interrupt environment: caches and pipeline to
	bus latency.
<p>
<b> Cache Side Effects </b>
<p>
	MIPS core starting with the R4000 series implement virtual indexed,
	physically tagged caches. This type of cache saves one clock of cache
	access latency by looking up the tlb and cache simultaneously. The
	disadvantage is that there can only be one mapping of each virtual cache
	line to physical memory. If this is violated, then the same physical
	block would map to two or more cache indices, coherency would be lost.
	The problem for a secure environment is that MIPS processors allow
	certain exception vectors to be cached. Below is a list of all the
	defined exception vector addresses and their behavior. The General
	exception vector is taken for all interrupts, the remaining tlb, all
	address errors, bus errors, traps and system calls.

<p>
<center>
<table width="90%" cellspacing=1 cellpadding=1 border=1>
<th colspan=6> MIPS exception vectors </th>
<tr>
<td> Exception </td>
<td> Priority </td>
<td> Cause Reg </td>
<td> BEV bit in SR </td>
<td> Vector </td>
<td> Type </td>
</tr>
<tr>
<td> Cold Reset </td>
<td> 0 </td>
<td> - </td>
<td> set to 1 </td>
<td> 0xbfc00000 </td>
<td> always uncached </td>
</tr>
<tr>
<td> Warm Reset </td>
<td> 1 </td>
<td> - </td>
<td> set to 1 </td>
<td> 0xbfc00000 </td>
<td> always uncached </td>
</tr>
<tr>
<td> NMI </td>
<td> 2 </td>
<td> - </td>
<td> set to 1 </td>
<td> 0xbfc00000 </td>
<td> always uncached </td>
</tr>
<tr>
<td> TLB miss </td>
<td> 4i,11d </td>
<td> - </td>
<td> 1 </td>
<td> 0xbfc00200 + 0x000 </td>
<td> uncached </td>
</tr>
<tr>
<td> TLB miss </td>
<td> 4i,11d </td>
<td> - </td>
<td> 0 </td>
<td> 0x80000000 + 0x000 </td>
<td> cached </td>
</tr>
<tr>
<td> XTLB miss </td>
<td> 4i,11d </td>
<td> - </td>
<td> 1 </td>
<td> 0xbfc00200 + 0x080 </td>
<td> uncached </td>
</tr>
<tr>
<td> XTLB miss </td>
<td> 4i,11d </td>
<td> - </td>
<td> 0 </td>
<td> 0x80000000 + 0x080 </td>
<td> cached </td>
</tr>
<tr>
<td> Cache error </td>
<td> 6 </td>
<td> - </td>
<td> 1 </td>
<td> 0xbfc00200 + 0x100 </td>
<td> uncached </td>
</tr>
<tr>
<td> Cache error </td>
<td> 6 </td>
<td> - </td>
<td> 0 </td>
<td> 0xa0000000 + 0x100 </td>
<td> uncached </td>
</tr>
<tr>
<td> General </td>
<td> all others </td>
<td> 0..31 </td>
<td> 1 </td>
<td> 0xbfc00200 + 0x180 </td>
<td> uncached </td>
</tr>
<tr>
<td> General </td>
<td> all others </td>
<td> 0..31 </td>
<td> 0 </td>
<td> 0x80000000 + 0x180 </td>
<td> cached </td>
</tr>
</table>
</center>

<p>
	All exceptions that can be taken in cached mode violate a secure
	environment due to the cache aliasing of an virtual index physically
	tagged cache. An attacker could set up the cache by forcing a second
	mapping at the exception vector with malicious code. The processor
	would see the required line in the cache and use it to service the
	exception, in effect executing the malicious code. For this reason,
	the only exception usable for entering a secure environment is the
	NMI exception. Like the reset exceptions it always fetches from uncached
	unmapped space and results in read requests on the bus interface for
	uncached code fetches.
<p>
<b> Bus Interface Effects </b>
<p>
	MIPS processors implement a write buffer that can buffer up to four
	address/data pairs to reduce pipeline stalls due to external bus activity.
	The write buffer is flushed on reads to guarantee data consistency. There
	is no write buffer hit detection to bypass loads which miss in the write
	buffer. The write buffer is of particular concern when asynchonous events
	such as interrupts are involved. The trigger to entering secure mode
	can not solely be based on an interrupt signal as below code outlines.
	The trick is to use stores to an uncached io port to keep the bus interface
	busy, hoping the interrupt happens in between so that the load from the
	protected space can succeed. The entire secure area could be read by looping
	through a large number of interrupts.
<pre>
	cpu pipe		write buffer		bus interface

		:			:			:
	la r1,0xbfc00000		:			:
	la r2,kseg1addr		:			:
	sw $0,0(r2)		kseg1addr+0/0		write kseg1addr+0
	sw $0,8(r2)		kseg1addr+8/0			:
	sw $0,16(r2)		kseg1addr+16/0			:
	sw $0,24(r2)		kseg1addr+24/0			:
	lw r3,0(r1)			:		write kseg1addr+8
		:			:			:
		:			:			:
		:			:			:
		:			:		write kseg1addr+16
int -->		:			:			:
secure on	:			:			:
  |		:			:			:
  |		:			:		write kseg1addr+24
  |		:			:			:
  |		:			:			:
  |		:			:			:
  |		:			:		read 0xbfc00000 would succeed
  |	save r3				:			:
  |	(int exception taken)		:		fetch exception vector
  |		:			:		execute secure environment
  |		:			:			:
</pre>

<p>
<b> Solution </b>
<p>
	The cache problem has been solved by using the NMI exception. The
	write buffer problem can be prevented by making the issuance of the
	NMI dependend on an uncached load. The application sets up arguments
	to the secure services and execute an uncached load from a reserved
	io port, the Secure Mode Register. The uncached load flushes the write
	buffer, sets a temporary flag and issues an NMI. The secure mode is
	only entered when the temporary flag is set, the NMI signal is active
	and a fetch from the boot exception vector at 0x1fc00000 (physical
	address) is seen on the bus interface. The same mechanism works for
	periodic entry into the secure mode by a separate hardware timer.

<p>
<b> The Secure Mode Register and Secure Timer Register </b>
<p>
	The Secure Mode Register is an io port with different access rights in
	secure and non-secure mode. In non-secure mode, reading the register will
	trigger the secure system call. The bus request is terminated with a bus
	error. All writes to the register are dropped without notification. In
	secure mode, software has full read/write access. Writing of the SECM bit
	prepares the system for leaving secure mode. Hardware has to ensure that
	overlapping events are not lost, such as a application call followed by
	a secure timer event.
<p>
<center>
<table cellpadding=1 cellspacing=1 border=1>
<th colspan=4> Secure Mode Register (in secure mode) </th>
<tr>
<td> Bit </td>
<td> Menmonic </td>
<td> Read </td>
<td> Write </td>
</tr>
<tr>
<td> 0 </td>
<td> SECM </td>
<td> 0=non-secure, 1=secure mode </td>
<td> 0 clears secure mode, deasserts NMI </td>
</tr>
<tr>
<td> 1 </td>
<td> RESET </td>
<td> 1 cpu RESET was active </td>
<td> 0 clears RESET status </td>
</tr>
<tr>
<td> 2 </td>
<td> NMI </td>
<td> 1 NMI was active </td>
<td> 0 clears NMI status </td>
</tr>
<tr>
<td> 3 </td>
<td> SAPP </td>
<td> 1 application triggered </td>
<td> 0 clears SAPP status </td>
</tr>
<tr>
<td> 4 </td>
<td> STIM </td>
<td> 1 secure timer triggered </td>
<td> 0 clears STIM status </td>
</tr>
<tr>
<td> 5 </td>
<td> STEN </td>
<td> 1 secure timer enabled </td>
<td> 1 enable secure timer </td>
</tr>
<tr>
<td> 31..6 </td>
<td> undefined </td>
<td> X </td>
<td> X </td>
</tr>
</table>
</center>

<p>
	The Secure Timer Register can only be accessed in secure mode. The value
	of this register is compared to a hardware counter which increments at a
	TBD frequency. When the counter is equal to the Secure Timer Register,
	the temporary secure flag is set and an NMI issued in order to enter secure
	mode.

<p>
<center>
<table cellpadding=1 cellspacing=1 border=1>
<th colspan=4> Secure Timer Register </th>
<tr>
<td> Bit </td>
<td> Menmonic </td>
<td> Read </td>
<td> Write </td>
</tr>
<tr>
<td> N..0 </td>
<td> SCMP </td>
<td> current value of counter </td>
<td> timer interval, TBD </td>
</tr>
</table>
</center>

<p>
<b> Entering secure mode </b>
<p>
	The state change into secure mode happens upon either the execution of
	the uncached load from the Secure Mode Register or the Secure Timer. The
	NMI exception forces the processor into uncached and unmapped execution.
	The secure kernel may want to switch to cached mode for faster execution.
	The NMI exception sets the BEV bit in the status register, forcing all
	other exceptions and interrupts through the vectors in the internal flash.
	The secure kernel must deal with the servicing of these events as they
	could open up secure mode to exception or interrupt handlers in application
	space. The content of the internal SRAM (isram) must be saved to main memory,
	because it must hold sensitive temporary state of the secure kernel.
	Either the cpu or the pi dma can be used for that purpose.
<p>
	A description of the secure services is beyond the scope of this document.
	However, the secure kernel software should implement additional exception
	handling to detect breach attempts. Radiation, voltage and clock variations
	are one example of an attack that may corrupt data in caches or registers
	to make the processor execute something else to make it leave the secure
	environment or address spaces.

<p>
<b> Leaving secure mode </b>
<p>
	Secure mode must be exited from cached space, because instructions must
	be executed after the secure mode has been turned off in hardware. The
	content of the isram must be restored from main memory. The dcache and
	icache must be cleaned before the store to the Secure Mode Register which
	turns off access to the internal flash. The ERET instruction must be in
	the icache because future fetches from iflash would return 0s. This method
	exposes on or more icache lines to the application. Software ensures that
	knowledge of these instructions is not important from a security point
	of view.
<pre>
		:
	restore isram
	clean dcache
	clean icache
		:
	restore cpu state
		:
	sw $0,SecureModeReg	| these two must be in icache
	eret			|
</pre>
<p>
	The store to the Secure Mode Register deasserts NMI and re-arms the
	temporary flag for further secure requests.


<hr>
<font size="-1">
	Problems and comments to
<a href="mailto:berndt@broadon.com">
	berndt@broadon.com
</a>
</font>
</body>
</html>