Patent Application
20050257016
The present invention relates to systems and methods for protecting, from code or data copying or alteration, one or more segments of memory in a controller chip, such as a microcontroller, microprocessor, digital signal controller or digital signal processor and, more particularly, to systems and methods for inhibiting access to memory segments by programs running in insecure areas of memory.
Controllers, such as microcontrollers, microprocessors, digital signal controllers and digital signal processors conventionally are structured to be programmable to perform particular applications and functions within a system. Generally, these devices have been programmable without restriction by the customer or programmed during the manufacturing process with software provided by or specified by the customer. Thus, the code in controllers has conventionally been accessible, by design, by the customer with little if any security preventing access by the customer.
With the increasing density and storage capacity of controller devices, it has become desirable to provide the flexibility to store third party software and data in the program memory of controllers that are to be distributed to customers, together with any customer software programmed at the time of manufacture or at a later time. For this type of application, the customer is no longer a trusted party relative to the third party software. Accordingly, there is a need to protect the third party software and data from discovery by the customer. This is particularly true for software and data such as encryption algorithms and encryption keys. It is also true for third party software of other types, such as algorithms for performing digital signal processing functions that add value to chips but at the same time represent software protected by copyright and in some cases trade secret. It is also true for start up software such as boot programs, boot loaders and operating systems which in addition to being proprietary need access restrictions in order to ensure that they are executed as stored without alteration to ensure the security of the system in which the controller is operating.
Accordingly, there is a need for a controller design that allows the security of memory to be enhanced. There is a further need for a controller design that allows certain areas of memory to be more secure than other areas. There is still a further need for a controller design that monitors the program flow and prevents the controller for entering secure areas of memory under certain circumstances and that prevents the controller from reading and writing to secure areas of memory.
According to the present invention, a controller is provided that offers various security modes for protecting program code and data stored in memory and ensuring that the protection is effective during all normal operating conditions of the controller. The controller includes configuration settings that segment program memory into a boot segment, a secure segment and a general segment, each with a particular level of security including no enhanced protection. The boot code segment (BS) is the most secure and may be used to store a secure boot loader. The secure code segment (SS) is useful for storing proprietary algorithms from third parties, such as algorithms for separating ambient noise from speech in speech recognition applications. The general code segment (GS) has the least security.
The controller is configured to prevent program flow changes that would result in program code stored in the BS from being accessed by program code stored in the SS or GS. Similarly, the controller is configured to prevent program code stored in the SS from being accessed by program code stored in the GS. When a violation occurs, the controller executes a trap routine and may reset the processor or otherwise prevent the security breach from occurring. In addition to preventing program flow changes from lower security code to higher security code, the processor may be configured to have associated secure data portions of both program memory, such as flash memory, and random access memory (RAM) corresponding to the BS, SS and GS. Attempts to read data from or write data to the program memory or RAM associated with a higher security level from a lower security level are prevented from occurring. In this manner, secure program code and data associated with different segments of memory may be protected from discovery by users of the controller, while making the functionality of the secure program code available to the user.
The above described features and advantages of the present invention will be more fully appreciated with reference to the detailed description and appended figures in which:
According to the present invention, a controller is provided that offers various security modes for protecting program code and data stored in memory and ensuring that the protection is effective during all normal operating conditions of the controller. The controller includes configuration settings that segment program memory into a boot segment, a secure segment and a general segment, each with a particular level of security including no enhanced protection. The boot code segment (BS) is the most secure and may be used to store a secure boot loader. The secure code segment (SS) is useful for storing proprietary algorithms from third parties, such as algorithms for separating ambient noise from speech in speech recognition applications. The general code segment (GS) has the least security.
The controller is configured to prevent program flow changes that would result in program code stored in the BS from being accessed by program code stored in the SS or GS. Similarly, the controller is configured to prevent program code stored in the SS from being accessed by program code stored in the GS. When a violation occurs, the controller executes a trap routine and may reset the processor or otherwise prevent the security breach from occurring. In addition to preventing program flow changes from lower security code to higher security code, the processor may be configured to have associated secure data portions of both program memory, such as flash memory, and random access memory (RAM) corresponding to the BS, SS and GS. Attempts to read data from or write data to the program memory or RAM associated with a higher security level from a lower security level are prevented from occurring. In this manner, secure program code and data associated with different segments of memory may be protected from discovery by users of the controller, while making the functionality of the secure program code available to the user.
In order to describe embodiments of controllers incorporating security features according to the present invention, an overview of pertinent processor elements is first presented with reference to
Overview of Processor Elements
The processor 100 includes a program memory 105, an instruction fetch/decode unit 110, instruction execution units 115, data memory and registers 120, peripherals 125, data I/O 130, and a program counter and loop control unit 135. The bus 150, which may include one or more common buses, communicates data between the units as shown.
The program memory 105 stores software embodied in program instructions for execution by the processor 100. The program memory 105 may comprise any type of nonvolatile memory such as a read only memory (ROM), a programmable read only memory (PROM), an electrically programmable or an electrically programmable and erasable read only memory (EPROM or EEPROM) or flash memory. In addition, the program memory 105 may be supplemented with external nonvolatile memory 145 as shown to increase the complexity of software available to the processor 100. Alternatively, the program memory may be volatile memory which receives program instructions from, for example, an external non-volatile memory 145. When the program memory 105 is nonvolatile memory, the program memory may be programmed at the time of manufacturing the processor 100 or prior to or during implementation of the processor 100 within a system. In the latter scenario, the processor 100 may be programmed through a process called in-circuit serial programming.
The instruction fetch/decode unit 110 is coupled to the program memory 105, the instruction execution units 115 and the data memory 120. Coupled to the program memory 105 and the bus 150 is the program counter and loop control unit 135. The instruction fetch/decode unit 110 fetches the instructions from the program memory 105 specified by the address value contained in the program counter 135. The instruction fetch/decode unit 110 then decodes the fetched instructions and sends the decoded instructions to the appropriate execution unit 115. The instruction fetch/decode unit 110 may also send operand information including addresses of data to the data memory 120 and to functional elements that access the registers.
The program counter and loop control unit 135 includes a program counter register (not shown) which stores an address of the next instruction to be fetched. During normal instruction processing, the program counter register may be incremented to cause sequential instructions to be fetched. Alternatively, the program counter value may be altered by loading a new value into it via the bus 150. The new value may be derived based on decoding and executing a flow control instruction such as, for example, a branch instruction. In addition, the loop control portion of the program counter and loop control unit 135 may be used to provide repeat instruction processing and repeat loop control as further described below.
The instruction execution units 115 receive the decoded instructions from the instruction fetch/decode unit 110 and thereafter execute the decoded instructions. As part of this process, the execution units may retrieve one or two operands via the bus 150 and store the result into a register or memory location within the data memory 120. The execution units may include an arithmetic logic unit (ALU) such as those typically found in a microcontroller. The execution units may also include a digital signal processing engine, a floating point processor, an integer processor or any other convenient execution unit. A preferred embodiment of the execution units and their interaction with the bus 150, which may include one or more buses, is presented in more detail below with reference to
The data memory and registers 120 are volatile memory and are used to store data used and generated by the execution units. The data memory 120 and program memory 105 are preferably separate memories for storing data and program instructions respectively. This format is a known generally as a Harvard architecture. It is noted, however, that according to the present invention, the architecture may be a Von-Neuman architecture or a modified Harvard architecture which permits the use of some program space for data space. A dotted line is shown, for example, connecting the program memory 105 to the bus 150. This path may include logic for aligning data reads from program space such as, for example, during table reads from program space to data memory 120.
Referring again to
The data I/O unit 130 may include transceivers and other logic for interfacing with the external devices/systems 140. The data I/O unit 130 may further include functionality to permit in circuit serial programming of the Program memory through the data I/O unit 130.
The W registers 240 are general purpose address and/or data registers. The DSP engine 230 is coupled to both the X and Y memory buses and to the W registers 240. The DSP engine 230 may simultaneously fetch data from each the X and Y memory, execute instructions which operate on the simultaneously fetched data and write the result to an accumulator (not shown) and write a prior result to X or Y memory or to the W registers 240 within a single processor cycle.
In one embodiment, the ALU 270 may be coupled only to the X memory bus and may only fetch data from the X bus. However, the X and Y memories 210 and 220 may be addressed as a single memory space by the X address generator in order to make the data memory segregation transparent to the ALU 270. The memory locations within the X and Y memories may be addressed by values stored in the W registers 240.
Any processor clocking scheme may be implemented for fetching and executing instructions. A specific example follows, however, to illustrate an embodiment of the present invention. Each instruction cycle is comprised of four Q clock cycles Q1-Q4. The four phase Q cycles provide timing signals to coordinate the decode, read, process data and write data portions of each instruction cycle.
According to one embodiment of the processor 100, the processor 100 concurrently performs two operations—it fetches the next instruction and executes the present instruction. Accordingly, the two processes occur simultaneously. The following sequence of events may comprise, for example, the fetch instruction cycle:
The following sequence of events may comprise, for example, the execute instruction cycle for a single operand instruction:
The following sequence of events may comprise, for example, the execute instruction cycle for a dual operand instruction using a data pre-fetch mechanism. These instructions pre-fetch the dual operands simultaneously from the X and Y data memories and store them into registers specified in the instruction. They simultaneously allow instruction execution on the operands fetched during the previous cycle.
The vector area 300 may be configured to store program address vectors to interrupt service routines that are invoked when a security violation occurs. It may be located anywhere in the program memory, including in the first 128 instruction words of the program memory. The vector area 300 may be configured using a configuration bit to allow or to not allow writes when the controller is in a high security mode or to allow writes in lower security modes.
The boot segment 310 and boot segment access area 305 comprise the most secure segments within the program memory. Each stores program instructions which may comprise, for example, a boot loader program or an operating system depending on the size of the segments. The boot segment access area 305 may comprise a subset of the boot segment 310 and, in a high security mode, may comprise an address range into which program flow control changes are allowed from less secure segments of memory for executing subroutine calls to the boot segment, such as from the secure segment, general segment or external memory. In this manner, access to the boot segment can be further controlled and handled according to security procedures embodied in instructions stored in the boot segment access area. Reading and writing the contents of boot segments 305 and 310 may also be restricted depending on the security configuration of the controller. Program instructions for the boot segments 305 and 310 may be programmed into the program memory during manufacture of the chip or subsequent to manufacture. The configuration bits of the controller may also be programmed to prevent a user of the controller from discovering the program instruction in the boot segments, changing the program instructions in the boot segment or executing program instructions in the boot segments without invoking allowed boot segment subroutines or booting the controller.
The secure segment 320 and the secure segment access area comprise another secure segment within the program memory. Each stores program instructions which may comprise, for example, third party software such as useful library of functions or algorithms that may be called by users of the controller in general program code that that the controller is programmed to execute. The size of the secure segments 320 and 315 and their existence depend on the settings of the configuration bits. The secure segment access area 315 may comprise a subset of the secure segment 320 and, in a high security mode, may comprise an address range into which program flow control changes are allowed from less secure segments of memory for executing subroutine calls to the secure segment, such as from the general segment or external memory. In this manner, access to the secure segment can be further controlled and handled according to security procedures embodied in instructions stored in the secure segment access area. The boot segment may be configured to access the secure segments without restriction. Reading and writing the secure segments 315 and 320 may also be restricted depending on the security configuration of the controller. Program instructions for the secure segments 305 and 310 may be programmed into the program memory during manufacture of the chip or subsequent to manufacture. The configuration bits of the controller may also be programmed to prevent a user of the controller from discovering the program instruction in the secure segments, changing the program instructions in the boot segment or executing program instructions in the secure segments without invoking allowed secure segment subroutines or booting the controller. In this manner, program code provided by third parties and embodied in a controller may be protected from discovery by users of the controllers even as the users of the controllers use the functionality of the third party code embodied in the controller.
The general segment 325 may have a lower security level than the secure segments and the boot segments. The general segment may store program instructions that comprise, for example, user software such as system level programs and routines that cause the controller to operate within a larger system. The size of the general segments 325 and its existence depends on the settings of the configuration bits. The general segment 325 typically stores the majority of the program instructions. The boot segment and secure segment may be configured to access the general segment without restriction. Reading and writing the general segment 325 may also be restricted depending on the security configuration of the controller. Program instructions for the general segment 325 may be programmed into the program memory during manufacture of the chip or subsequent to manufacture. The configuration bits of the controller may also be programmed to prevent a user of the controller from discovering the program instruction in the general segment, changing the program instructions in the general segment or executing program instructions in the general segments. In this manner, program code provided in the general segment may be protected from discovery by users of the controllers.
The secure segment data section 355 may be configured to create a section of data required by one or more secure code segments 320. When present, the data in section 355 may be protected from being read from or written to by code stored in an unprotected or less protected area of memory such as the general segment 325 or the external segment 330. The data may be useful constants, coefficients, encryption keys or other useful data.
The boot segment data section 360 may be configured to create a section of data required by the boot code segments 310. When present, the data in section 360 may be protected from being read from or written to by code stored in an unprotected or less protected area of memory such as the secure segment 320, the general segment 325 or the external segment 330. The data may be useful constants, coefficients, encryption keys or other useful data.
The test code segment 365 may store code used to test the operation of the controller. The unit_ID section 370 may be used to store information pertaining to a particular controller, such as a part number, a lot number, a manufacturer number, a manufacturing parameters, a serial number or other unique identifier and any other useful information.
The configuration registers 375 may be used to store security settings for the controller that determine presence, size and level of security associated with each of the segments of memory.
Referring to
For the security segment:
The general segment may be configured in exactly the same manner as the secure segment and the boot segment. Alternatively, the general segment may be configured to comprise in size the remaining portion of the non-volatile program memory not occupied by the boot segment and the secure segment. In the latter case, the general segment security bits may be configured using two bits to define three modes:
The BWRP register 415 is a write enable/disable register. By setting this register to a one or a zero, the controller may be configured to disable all data writes into the boot segment such that the code in the boot segment may not be overwritten. The SWRP register 420 and the GWRP registers 425 are also a write enable/disable register. By setting these registers to a one or a zero, the controller may be configured to disable all data writes into the secure segment and the general segment respectively such that the code in the boot segment may not be overwritten.
The EBS and ESS registers, 430 and 435 respectively, store values that may correspond to the presence, size and location of the boot segment data and secure segment data within the data non-volatile memory of the controller. These areas generally will not be created unless corresponding boot segment and secure segments have been created in the program memory and are accessible only by those corresponding segments. The location of the data within the memory may be predetermined as part of the manufacturing of the data with specific bits to either allocate that predetermined portion of the memory to the boot segment or the security segment or to make it available for other uses. Once allocated, unauthorized read of a protected area of memory from an unauthorized segment will read as a zeros or ones or some other value that does not reflect the actual value of the data. An unauthorized write of a protected area of memory from an unauthorized segment will not initiate a programming sequence and will result in one or more no operation (NOP) cycles. Alternatively, a trap routine may be invoked.
The RBS and RSS registers, 440 and 445 respectively, store values that may correspond to the presence, size and location of the boot segment data and secure segment data within the random access memory of the controller. These areas generally will not be created unless corresponding boot segment and secure segments have been created in the program memory and may be accessible only by those corresponding segments. The location of the data within the memory may be predetermined as part of the manufacturing of the data with specific bits to either allocate that predetermined portion of the memory to the boot segment or the security segment or to make it available for other uses. Once allocated, unauthorized read of a protected area of memory from an unauthorized segment will read as a zeros or ones or some other value that does not reflect the actual value of the data. An unauthorized write of a protected area of memory from an unauthorized segment will not initiate a programming sequence and will result in one or more no operation (NOP) cycles. Alternatively, a trap routine may be invoked. Code stored in the boot segment and the secure segment may change the values in the RBS and RSS registers to release protected corresponding RAM segments when they are no longer needed.
Referring to
The flow control security logic generates a trap flag based on its inputs whenever a change in the program counter 500 results in the processor attempting to fetch and execute instructions corresponding within a segment having a higher level of security than the segment corresponding to the instruction stream that it is presently processing. Accordingly, the flow control security logic 520 compares the program memory address stored as the current value of the program counter 500 with registers 530-540 and the instructions being executed to determine the current level of security (i.e. boot, secure or general). The flow control security logic 520 also compares the program memory address stored as the next value of the program counter 500 with registers 530-540 and the instructions being executed to determine the level of security (i.e. boot, secure or general) of the next sequential program instruction for execution. Based on these comparisons, the flow control security logic generates a trap flag 525 whenever the program counter is changed to point into a higher security segment from a lower security segment.
An exception to this method of operation occurs when a general segment calls a subroutine within a segment having a higher level of security. This may occur, for example, when the general segment calls a subroutine, such as a third party algorithm, within the secure segment, or calls a subroutine such as an encryption subroutine within the boot segment. In these scenarios, the flow control security logic may allow the program flow change to occur based on the type of instruction, call instruction, and the value of the program counter address change being within a predetermined range, such as the program secure segment access area 315 or the boot segment access area 305.
When a trap flag 525 is generated, it results in the processor jumping to the corresponding trap routine. According to an embodiment of the present invention, the trap routine is a controller reset routine stored in the first 128 bits of the program memory. It will be understood, however, that this trap routine may be stored anywhere within the program memory.
Referring to
The instruction execution units and registers are coupled to the memory array(s) 615 via one or more addresses buses depending on the number of data buses and the number of memory arrays that may be accessed by the controller. The data bus(es) are coupled between the instruction execution units and registers 600 and a read/write access multiplexer. The read/write access multiplexer is used to read data from the array and put it on the appropriate data bus and to write data to the array from the appropriate data bus.
The access control security logic 610 is coupled between the configuration registers 400-445 and the read/write access multiplexer. When a read or a write of a memory array is attempted, the access control security logic 610 determines the security level corresponding to the instruction, which is generally be boot, secure or general according to an embodiment of the present invention although additional security designations may be included. The security level is determined based on the memory address of the instruction as specified by the instruction and corresponding security level of that location.
On an attempted read or write of the memory array, the access control security logic determines whether the read or write is associated with a memory location that (is not permitted to be written according to the BWRP, SWRP, GWRP registers or whether the read or write is associated with a memory location that is associated with a higher level of security than the security level of the read/write instruction. In either case, the access control security logic generates a signal to the read/write access multiplexer that prevents it from performing the read or write operation. Instead, the read/write access multiplexer blocks a write operation resulting in a NOP or forces known data, such as all zeros or all ones on the data bus for an unauthorized read.
While particular embodiments of the present invention have been illustrated and described, it will be understood by those having ordinary skill in the art that changes may be made to those embodiments without departing from the spirit and scope of the invention. For example, the present invention may be applied to a microprocessor, microcontroller, digital signal processor or a hybrid, such as a digital signal controller and to any segments of memory on such chips.
