Abstract:
Systems, methods and computer-readable mediums are disclosed for providing secure access in a microcontroller system. In some implementations, a microcontroller system comprises a system bus and a secure central processing unit (CPU) coupled to the system bus. The secure CPU is configured to provide secure access to the system bus. A non-secure CPU is also coupled to the system bus and is configured to provide non-secure access to the system bus. A non-secure memory is coupled to the system bus and is configured to allow the secure CPU and the non-secure CPU to exchange data and communicate with each other. A peripheral access controller (PAC) is coupled to the system bus and configured to enable secure access to a peripheral by the secure CPU while disabling non-secure access to the peripheral based upon a non-secure state of the non-secure CPU.

Description:
TECHNICAL FIELD 
       [0001]    This disclosure relates to secure information processing. 
       BACKGROUND 
       [0002]    When designing products with microcontroller systems it may be desirable to program code into secure memory so that a customer can execute the code but not copy or modify the code. Additionally, it may be desirable to partition an application into secure and non-secure domains, where the secure domain allows critical information (e.g., cryptographic keys) to be processed by code stored in secure memory with full system access, while the non-secure domain does not have access to the secure memory. This split domain architecture improves security robustness by preventing software errors from accidentally leaking information from the secure domain into the non-secure domain. Microcontroller systems with split domain architectures are designed with a single central processing unit (CPU) that is designed to operate in secure and non-secure modes to ensure a safe transition between secure and non-secure operations. 
       SUMMARY 
       [0003]    Systems, methods and computer-readable mediums are disclosed for providing secure access in a microcontroller system. In some implementations, a microcontroller system comprises a system bus and a secure central processing unit (CPU) coupled to the system bus. The secure CPU is configured to provide secure access to the system bus. A non-secure CPU is also coupled to the system bus and is configured to provide non-secure access to the system bus. A non-secure memory is coupled to the system bus and is configured to allow the secure CPU and the non-secure CPU to exchange data and communicate with each other. A peripheral access controller (PAC) is coupled to the system bus and configured to enable secure access to a peripheral by the secure CPU while disabling non-secure access to the peripheral based upon a non-secure state of the non-secure CPU. 
         [0004]    In some implementations, a method comprises: detecting, by a microcontroller system, a system event; and responsive to the system event: configuring a first CPU of the microcontroller system to operate in secure mode, where secure mode allows secure access to a system bus of the microcontroller system and execution of secure code on the first CPU; configuring a second CPU to operate in non-secure mode, where non-secure mode allows non-secure access to the system bus and to execute non-secure code on the second CPU; configuring the first CPU and the second CPU to exchange data and communicate with each other using non-secure shared memory; and configuring a peripheral access controller (PAC) coupled to the system bus to allow secure communication between the PAC and a peripheral coupled to the PAC. 
         [0005]    In some implementations, a non-transitory, computer-readable storage medium has instructions stored thereon, which, when executed by two or more central processing units of a microcontroller system, causes the two or more central processing units of the microcontroller system to perform operations comprising: detecting a system event; and responsive to the system event: configuring a first CPU to operate in secure mode, where secure mode allows secure access to a system bus of the microcontroller system and to execute secure code on the first CPU; configuring a second CPU to operate in non-secure mode, where non-secure mode allows non-secure access to the system bus and to execute non-secure code on the second CPU; configuring the first CPU and the second CPU to exchange data and communicate with each other using non-secure shared memory; and configuring a peripheral access controller (PAC) coupled to the system bus, the PAC allowing secure communication between the PAC and a peripheral coupled to the PAC. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0006]      FIG. 1  is a conceptual block diagram of a microcontroller system with secure information processing extensions, according to some implementations. 
           [0007]      FIG. 2  is a flow diagram of an example process performed by a microcontroller system with secure information processing extensions, according to some implementations. 
       
    
    
     DETAILED DESCRIPTION 
     Example System Architecture 
       [0008]      FIG. 1  is a conceptual block diagram of a microcontroller system  100  with secure information processing extensions, according to some implementations. Microcontroller system  100  can include debug master module  101 , central processing unit (CPU)  102 , CPU  103 , direct memory access (DMA) controller  104 , memory  106  (e.g., Flash),  107  (e.g., RAM), slave controller  108 , bridges  109 ,  113 , slave modules  110 ,  111  and peripheral access controller (PAC)  114 . The masters and slave modules  110 ,  111 ,  112  and PAC  114  are coupled directly or indirectly (e.g., through bridges  109 ,  113 ) to system bus  115  (e.g., a bus matrix). The system bus is configurable to route secure access requests from secure CPU  102 . In some implementations, the secure access request can be associated with a signal indicating the request was initiated by secure CPU  102 . In some implementations, slave module  110  is a cryptographic slave module for implementing an Integrity Check Monitor (ICM) capable of executing cryptographic hash algorithms, and slave module  111  is a cryptographic slave module for implementing an Advanced Encryption Standard (AES) algorithm. In some implementations, slave modules  110 ,  111  receive secure signals  122   a ,  122   b  from PAC  114 . When secure signals  122   a ,  122   b  are high (or low), only secure bus accesses are permitted. In some implementations, slave modules  110 ,  111  can include software wrapper layers for receiving secure signals  122   a ,  122   b . Microcontroller system  100  can include other master modules  105  and other slave modules  112  in addition to, or in place of, the master and slave modules shown in  FIG. 1 . Other slave modules  112 , if configured as secure slave modules, can be configured to receive secure signals from PAC  114  to allow only secure bus accesses. 
         [0009]    To assist the reader,  FIG. 1  includes a Legend that associates block fill patterns with secure (forward slash fill pattern) and optionally secure (backward slash fill pattern) master and slave modules in microcontroller system  100 . The Legend also shows that blocks with a cross hatch fill pattern indicate fuses  119   a - 119   d  (e.g., write protected pseudo fuses). In some implementations, fuses  119   a - 119   d  can be real fuses latched in memory (e.g., memory  106 ) at system reset or pseudo fuses read from memory (e.g., non-volatile memory) and latched in a memory controller (not shown) at system reset. Microcontroller system  100  can be extended to include additional CPUs, where each additional CPU can be configured to be secure or non-secure and each secure CPU can share the same secure memory resources. 
         [0010]    In response to a system event (e.g., a system reset), CPU  102  can be configured as a secure CPU and CPU  103  can be configured as a non-secure CPU. Secure CPU  102  runs secure code and provides secure access to system bus  115 , while non-secure CPU  103  runs non-secure code and provides non-secure access to system bus  115 . The security configuration can be static (e.g., hardwired in the design) or programmable by pseudo fuses  119   a  (FV; FlashVault Enable),  119   b  (FVDE; FlashVault Debug Enable),  119   c  (FVFLSZ; FlashVault Flash Size) and  119   d  (FVRAMSZ; FlashVault RAM Size) (e.g., write protected pseudo fuses). The pseudo fuses can be loaded at system reset to configure microcontroller system  100  before any client application code executes. 
         [0011]    The security configuration described above allows secure code to execute on secure CPU  102 , while data exchange and communication between secure CPU  102  and non-secure CPU  103  takes place in non-secure portions of memories  106 ,  107 . In some implementations, secure CPU  102  can configure itself (e.g., by means of internal control register  116 ) to temporarily provide non-secure access to system bus  115 . This can improve robustness if non-secure and secure code need to execute on the same CPU. Secure bus accesses can be disabled before executing the non-secure code, then re-enabled when executing further secure code. This prevents software errors in the non-secure code from accidently reading data from secure memory. 
         [0012]    Slave modules  110 ,  111 ,  112  (e.g., peripherals) in microcontroller system  100  can be accessed by secure CPU  102  or non-secure CPU  103 . When secure software depends on secure interaction with a peripheral (e.g., cryptographic modules  110 ,  111 ), access to the peripheral should be limited to secure access. In some implementations, secure access can be centralized in microcontroller system  100  by PAC  114 , which can be configured to distribute one or more signals to each slave module or peripheral of system  100  to command each slave module or peripheral to only accept secure accesses provided by secure CPU  102 . The one or more signals can be switched on by one or more bits being written to control register  117  in PAC  114 . Control register  117  can be written by a secure access provided by secure CPU  102 . Control register  117  enables secure CPU  102  to enable secure access to critical peripherals for as long as needed and disable secure access when the secure operation is complete, thus allowing the peripheral to be controlled by non-secure CPU  103 . 
         [0013]    In some implementations, secure CPU  102  can be secure by setting fuse FV. Secure CPU  102  can optionally switch off secure bus access by setting one or more bits in control register  116 , which can be external or internal to secure CPU  102  (shown as internal to secure CPU  102  in  FIG. 1 ). Secure CPU  102  can be controlled and debugged by bus mapped control registers (not shown). When FV is set, the bus mapped control registers can be modified by secure access provided by secure CPU  102 . In some implementations, secure CPU  102  can boot from boot code  118  stored in a secure portion of non-volatile (NV) memory  106  (e.g., Flash memory). The upper portions of NVM  106  and volatile memory  107  (e.g., RAM) can be reserved for secure operations. These secure portions of memory can be set up by size fuses FVFLSZ (NVM  106 ) and FVRAMSZ (RAM  107 ). The NVM and RAM controllers (e.g., DMA  104 ) will provide secure access to the secure memory regions and secure or non-secure access to non-secure memory regions. 
         [0014]    In some implementations, PAC  114  includes control register  117  where a user can write a peripheral identifier indicating which peripheral to target for access and a KEY value to enable or disable secure access to the peripheral. The KEY value can be written/programmed by secure CPU  102  as a secure write operation. Control register  117  can also be used to write protect the peripheral using different KEY values, which can be written to control register  117  by non-secure access. 
         [0015]    In some implementations, debug master module  101  is controlled by an external debugger (external to microcontroller system  100 ) and grants access to internal resources for programming and debugging. By default, debug master module  101  can be non-secure and can provide non-secure access to non-secure memory and peripherals. To aid development of secure code, debug master module  101  can be made temporarily secure by setting the FVDE fuse. When FVDE is set, debug master module  101  is secure and can access all memories and peripherals in microcontroller system  100 , including control registers in secure CPU  102  and PAC  114 . In some implementations, a user can erase the FVDE fuse before deploying the application to the end customer to ensure that the external debugger cannot read out secure memories in a customer application. In the example shown, SEC  120  is a security fuse which, when programmed, disables all external debug access. SEC  120  can only be restored by a full chip erase command, which erases all memory contents. SWD  121  is a Serial Wire Debug interface for communicating with the external debugger over a serial bus. 
       Example Process 
       [0016]      FIG. 2  is a flow diagram of an example process  200  of performed by a microcontroller system with secure information processing extensions, according to one implementation. Process  200  can be implemented in, for example, microcontroller system  100  described in reference to  FIG. 1 . 
         [0017]    In some implementations, process  200  can begin by detecting, by the microcontroller system, start of a system reset sequence ( 202 ). Responsive to the system event, process  200  can continue by configuring a first CPU of the microcontroller system to operate in secure mode that allows secure access to a system bus of the microcontroller system and to run secure code on the first CPU ( 204 ). For example, the system event can be a system reset and a fuse bit can be set at system reset that configures the first CPU to operate in secure mode. 
         [0018]    Process  200  can continue by configuring a second CPU to operate in non-secure mode that allows non-secure access to the system bus and to run non-secure code on the second CPU ( 206 ). 
         [0019]    Process  200  can continue by configuring the first CPU and the second CPU to exchange data and communicate with each other using non-secure shared memory ( 208 ). For example memory coupled to the system bus can be divided into secure and non-secure portions and the secure CPU and non-secure CPU can exchange data and communicate using the portion of non-secure shared memory. 
         [0020]    Process  200  can continue by configuring a peripheral access controller (PAC) coupled to the system bus to allow secure communication between the PAC and one or more peripherals coupled to the PAC ( 210 ). For example, the PAC can be coupled directly or indirectly (e.g., through bridge  113  in  FIG. 1 ) to the system bus and distributes one or more signals to each peripheral to command the peripheral to only allow secure accesses. 
         [0021]    When process  200  ends the system reset sequence ( 212 ), the CPU can execute its first instruction ( 214 ). 
         [0022]    While this document contains many specific implementation details, these should not be construed as limitations on the scope of what may be claimed but rather as descriptions of features that may be specific to particular embodiments. Certain features that are described in this specification in the context of separate embodiments can also be implemented in combination in a single embodiment. Conversely, various features that are described in the context of a single embodiment can also be implemented in multiple embodiments separately or in any suitable sub combination. Moreover, although features may be described above as acting in certain combinations and even initially claimed as such, one or more features from a claimed combination can, in some cases, be excised from the combination, and the claimed combination may be directed to a sub combination or variation of a sub combination.