Abstract:
A method including: assigning identifiers to respective domains, where each of the domains is allocated a corresponding set of resources, and where the resources in the sets of resources are accessible at respective physical addresses; storing permissions to access the physical addresses, where each of the permissions indicates which of the physical addresses one or more of the domains are permitted to access. The method also includes: assigning a code to a first domain, where the code includes instructions, and where each of the instructions includes a corresponding one of the physical addresses; tagging each of the instructions by adding the identifier assigned to the first domain to each of the instructions; and during execution of each of the instructions, comparing the identifier included in the corresponding instruction to one of the permissions; and based on the comparison, permitting access to the set of resources allocated to the first domain.

Description:
CROSS-REFERENCE TO RELATED APPLICATIONS 
     The present disclosure is a continuation of U.S. patent application Ser. No. 12/026,840 (now U.S. Pat. No. 8,677,457), filed on Feb. 6, 2008. This application claims the benefit of U.S. Provisional Application No. 60/889,086 filed on Feb. 9, 2007. The entire disclosures of the applications referenced above are incorporated herein by reference. 
    
    
     BACKGROUND 
     Many consumer products, such as mobile phones, set top boxes, personal digital assistants (PDA), and other systems running an operating system, are implemented with one or more processor cores. To secure a piece of code on the system, the processes that can access the code must be controlled. One approach is to partition a core into a trusted zone and a non-trusted zone. Code in the trusted zone can access all of the system resources. Code in the non-trusted zone has limited access to the system resources, as managed by code in the trusted zone. Two separate pieces of code in the non-trusted zone have the same level of permissions for access to the resources. However, it may be desirable to prevent access between the codes in the non-trusted zone. For example, an electronic wallet application and a digital rights management application may both run in the non-trusted zone. To maintain the integrity of each piece of code, access by the other needs to be controlled or prevented. A common approach is to run each piece of code in different cores. This approach, however, requires extra hardware. 
     Further, system resource access permissions are typically defined based on the virtual address space for the resources. Once permission for a piece of code is verified, the virtual address is translated to the physical address via a look-up table (LUT). However, this security mechanism is software based and may be bypassed or corrupted by a variety of means, including the direct use of the physical address of a resource directly, hence bypassing the virtual address translation. Thus, it may be difficult to prove the level of security provided by software based mechanisms. 
     Accordingly, it would be desirable to provide a method and system for providing security for codes running in non-trusted domains in a processor core. 
     BRIEF SUMMARY OF THE INVENTION 
     A method and apparatus of the invention provide security within a processor core by configuring a trusted domain and a plurality of isolated domains. Each isolated domain is assigned a unique domain identifier. One or more resources are associated with each of the isolated domains. The associations are stored as permissions to access the physical addresses of the resources. A code to be executed by a hardware device is assigned to one of the isolated domains, and the unique domain identifier for the assigned isolated domain is written to the hardware device. When the hardware device executes the code, each instruction is logically tagged with the domain identifier written to the hardware device. The instruction is identifiable as a request to access a physical address of a resource. The hardware device compares the domain identifier of the instruction with the permissions of the physical address in the instruction. If the domain identifier of the instruction has permission to access this physical address, then access to the resource at the physical address is allowed. Access to the resource is otherwise blocked. In this manner, codes assigned to different isolated domains can run independently within the same processor core without interference from each other. Further, since the permissions are configured based on the physical addresses of the resources, concerns related to software-based security mechanisms are not relevant. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         FIG. 1  illustrates an exemplary embodiment of multiple isolated domains in a processor core. 
         FIG. 2  is a block diagram of a processor core architecture in which embodiments of the invention may be implemented. 
         FIG. 3  is a flowchart illustrating an exemplary embodiment of the creation of isolated domains in a processor core. 
         FIG. 4  is a flowchart illustrating an exemplary embodiment of the use of the domain identifier. 
         FIG. 5  is a flowchart illustrating an exemplary embodiment of the use of the domain identifier for asynchronous events. 
     
    
    
     DETAILED DESCRIPTION 
     Embodiments of the invention relates to a method and apparatus for providing security for codes running in non-trusted domains of a processor core. The following description is presented to enable one of ordinary skill in the art to make and use the invention and is provided in the context of a patent application and its requirements. Various modifications to the embodiments and the generic principles and features described herein will be readily apparent to those skilled in the art. Thus, the invention is not intended to be limited to the embodiments shown, but is to be accorded the widest scope consistent with the principles and features described herein. 
     The invention will be described in the context of particular methods having certain steps. However, the method operates effectively for other methods having different and/or additional steps not inconsistent with the invention. 
       FIG. 1  illustrates an exemplary embodiment of multiple isolated domains in a processor core. As illustrated in  FIG. 1 , a processor core may be logically partitioned into a plurality of domains. The processor core is described in more detail below with reference to  FIG. 2 . A “domain”, as used in this specification, is a set of system resources (such as peripherals, memory space, etc.) which exist as a group. Any or all of these resources may be shared or private. Resources are private if they are accessible only to one domain. Resources are shared if they are accessible to more than one domain. Resources are accessible at their physical addresses. 
     The domains may include a trusted domain  101  and a plurality of non-trusted domains  102 . The non-trusted domains  102  may include a main domain  103  and a plurality of isolated domains  104 - 106 . A “trusted domain” is a domain which is privileged and able to configure other domains. A trusted domain  101  is able to access the resources of the processor core allocated to the trusted domain and the non-trusted domains. The trusted domain  101  includes code  107  for configuring the non-trusted domains  103 - 106  and for managing communications between codes in the non-trusted domains  103 - 106 . 
     The “main domain”  103  is a primary non-trusted domain in the processor core. The operating system may be run in the main domain  103 . Code in the main domain  103  is not able to access resources which are private to the trusted domain  101  or any of the isolated domains  104 - 106 , but is able to access the shared resources. The “isolated domains”  104 - 106  are non-trusted domains that have at least some private resources. There may be multiple such isolated domains  104 - 106 , each with its own resources. The isolated domains  104 - 106  are only able to access their own private and shared resources, as described below. Each of the non-trusted domains  102  is assigned a unique domain identifier. 
       FIG. 2  is a block diagram of a processor core in which the invention may be implemented. The core  200  includes a hardware device  201  with an execution engine  202  for executing code. The hardware device  201  can be of any type, such as a processor, a memory controller, a universal asynchronous receiver/transmitter (UART) device, etc. When the execution engine  202  executes code, the instructions are placed in an execution pipeline  203 . One or more caches  204  can be used to manage the execution of the instructions. The hardware device  201  and the cache  204  are coupled to a system bus  205 . Coupled to the system bus  205  are resources, which can include memory  206  and one or more I/O devices  207 . The hardware device  201  can access the resources  206 - 207  at their respective physical addresses. 
       FIG. 3  is a flowchart illustrating an exemplary embodiment of the creation of isolated domains in a processor core. Referring to both  FIGS. 2 and 3 , when the core  200  is booted, code  107  in the trusted domain  101  configures a plurality of isolated domains  104 - 106 . Each isolated domain is assigned a unique domain identifier (step  301 ). One or more resources  206 - 207  are associated with each isolated domain. The associations are stored as permissions to access the physical addresses of the resources  206 - 207  (step  302 ). When a hardware device  201  is configured, the code to be executed by the hardware device  201  is assigned to one of the isolated domains  104 - 106  (step  303 ). The domain identifier for the assigned isolated domain is then written to the hardware device  201  (step  304 ). 
       FIG. 4  is a flowchart illustrating an exemplary embodiment of the use of the domain identifier. When the execution engine  202  executes code in an isolated domain, each instruction is logically tagged with the domain identifier of the isolated domain written to the hardware device  201  (step  401 ). Logically, the domain identifier is being associated with each instruction in the execution pipeline  204 , and the operations associated with this instruction have the associated domain identifier. In the exemplary embodiment, the domain identifier comprises additional bits sent on the system bus  205  along with the instruction. 
     During execution of the code, the hardware device  201  compares the domain identifier of the instruction with the permissions for the resources  206 - 207  (step  402 ). The instruction is identifiable as a request for access to a physical address of a resource. Thus, the hardware device  201  compares the permissions of the physical address in the instruction with the domain identifier of the instruction (step  403 ). If the domain identifier of the instruction has permission to access the physical address, then access to the resource at the physical address is allowed (step  404 ). Otherwise, access is blocked (step  405 ), and a “memory out of range” error is returned. The hardware device  201  can use the assigned domain identifier to check the permissions each time a resource access is attempted or at any time during the execution of the code. 
     For example, assume that processor core  200  includes resources, RESOURCE 1  and RESOURCE 2  with physical addresses ADD 1  and ADD 2 . During configuration of the core  200 , two isolated domains, DOMAIN 1  and DOMAIN 2  are configured and assigned unique domain identifiers (step  301 ). Both RESOURCE 1  and RESOURCE 2  are associated with DOMAIN 1 , while only RESOURCE 1  is associated with DOMAIN 2 . The permissions for ADD 1  are stored as giving access to DOMAIN 1  and DOMAIN 2 , and the permissions for ADD 2  are stored as giving access to DOMAIN 1  (step  302 ). 
     Assume that two applications, APP 1  and APP 2  are configured to run on PROCESSOR 1  and PROCESSOR 2 , respectively. During the configuration of the applications, APP 1  is assigned to DOMAIN 1 , and APP 2  is assigned to DOMAIN 2  (step  303 ). DOMAIN 1  is then written to PROCESSOR 1 , and DOMAIN 2  is written to PROCESSOR 2  (step  304 ). 
     When PROCESSOR 1  executes APP 1 , each instruction is logically tagged with DOMAIN 1  (step  401 ). Assume that a first instruction of APP 1  includes a request to access ADD 1 . PROCESSOR 1  checks the permissions of ADD 1  and determines that DOMAIN 1  has been given access (steps  402 - 403 ). The first instruction is thus allowed access to the resource at ADD 1  (step  404 ). Assume that a second instruction of APP 1  includes a request to access ADD 2 . PROCESSOR 1  checks the permissions of ADD 2  and determines that DOMAIN 1  has been given access (steps  402 - 403 ). The second instruction is thus allowed to access the resource at ADD 2  (step  404 ). 
     When PROCESSOR 2  executes APP 2 , each instruction is logically tagged with DOMAIN 2  (step  401 ). Assume that a first instruction of APP 2  includes a request to access ADD 1 . PROCESSOR 2  checks the permissions of ADD 1  and determines that DOMAIN 2  has been given access (steps  402 - 403 ). The first instruction is thus allowed access to the resource at ADD 1  (step  404 ). Assume that a second instruction of APP 2  includes a request to access ADD 2 . PROCESSOR 2  checks the permissions of ADD 2  and determines that DOMAIN 2  has not been given access (steps  402 - 403 ). The second instruction is thus blocked from accessing the resource at ADD 2  (step  405 ). A “memory out of range” message is returned. 
     In this manner, APP 1  and APP 2  execute in separate isolated domains and each are only able to access their own private or shared resources. Neither is able to access resources which are private to the trusted domain  101  or any of the other non-trusted domains. Neither APP 1  nor APP 2  need to be modified. If APP 1  and APP 2  is required to communicate, this communication is managed through the code  107  in the trusted domain  101 . 
     Occasionally, the checking of the domain identifier cannot be performed in real time, such as for asynchronous events. Accesses from asynchronous events may not be related to the current isolated domain executing at an execution engine. The asynchronous event can be either from an external change, e.g., an interrupt, or from an action which took place some time previous, e.g. DMA completion at which time there was a different current domain. An isolated domain in which the event should be handled is the target isolated domain, which is identified by the domain identifier tagged on the asynchronous event. The target isolated domain can be the current isolated domain or a isolated domain different from the current isolated domain. 
       FIG. 5  is a flowchart illustrating an exemplary embodiment of the use of the domain identifier for asynchronous events. When a hardware device  201  detects an asynchronous event (step  501 ), the hardware device  201  compares the domain identifier of the event with the domain identifier of the current isolated domain executing on an execution engine  202  (step  502 ). If they match (step  503 ), then the event is allowed to occur in the current isolated domain (step  504 ). If they do not match, then the event is hidden in the current isolated domain (step  505 ). The hardware device  201  then generates a transition request to the trusted domain  101  to transfer the asynchronous event to the target isolated domain (step  506 ). Code in the trusted domain  101  transitions the execution engine  202  to the target isolated domain (step  507 ). The event is then shown in the target isolated domain (step  508 ), in which the event is handled. The hardware device  201  compares the permissions of the physical addresses of the resources  206 - 207  with the domain identifier of the event to determine which resources the event can access, as described above with reference to  FIG. 4 . 
     In the exemplary embodiment, the transition to the target isolated domain comprises a series of operations carried out between two instructions with different domain identifiers on the same execution engine or set of engines. The transition code can be implemented in any one of a number of ways. For example, clean up code is run in the current isolated domain, followed by a run of set up code in the target isolated domain. The clean up code hides the current isolated domain&#39;s resources. Once the transition to the target isolated domain occurs, the set up code enables the target isolated domain&#39;s resources. For another example, a single code is run in the trusted domain  101  to disable the resources of the current isolated domain and to enable the resources of the target isolated domain. 
     In the exemplary embodiment, the transition code contains no operational code. The transition code only performs the transition from a current isolated domain to a target isolated domain. The operation of any instruction is then handled in the target isolated domain, not by the transition code. 
     For example, assume that a UART interrupt is configured to be taken in one isolated domain, DOMAIN 1 . Assume also that another isolated domain, DOMAIN 2 , is currently running on the execution engine  202 . When the hardware device  201  detects the interrupt event (step  501 ), the hardware device  201  compares the domain identifier of the interrupt event, DOMAIN 1 , with the domain identifier of the currently running isolated domain, DOMAIN 2  (step  502 ). Since they do not match (step  503 ), the interrupt event is hidden in DOMAIN 2  (step  505 ). The hardware device  201  generates a transition request to the trusted domain  101  to transfer the interrupt event to DOMAIN 1  (step  506 ). Code in the trusted domain  101  transitions the execution engine  202  from DOMAIN 2  to DOMAIN 1  (step  507 ). The interrupt event is then shown in DOMAIN 1 , which is then handled by the execution engine  202  (step  508 ). The hardware device  201  determines the permissions to access the physical addresses of the resources  206 - 207 , as described above with reference to  FIG. 4 . 
     In some cases, it may be more expedient to place a resource “above” the point where the domain identifier tag is added to an instruction. For example, an initial design may wish to execute all instructions at the system-on-chip (SOC) level, thus avoiding modification of the core  200 . Examples of such resources include caches and memory management unit/translation lookaside buffer (MMU/TLB), typically used in virtual address translation. If the execution engine  202  is executing one piece of code at a time, a register can be associated with the hardware device  201  for storing the domain identifier assigned to the code. The value in the register is logically attached to a group of instructions executed by the execution engine  202 , rather that tagging each individual instruction. When the execution engine  202  transitions to a different isolated domain, the value in the register is changed to the domain identifier of that isolated domain. 
     If one or more of the caches in the processor core  200  are above the level where the domain identifier is added to an instruction, then when the execution engine  202  transitions to a different isolated domain, the cache is flushed of content belonging to the previously executing isolated domain. Flushing of the cache is required since access to the cache is not checked at this level. The flushing may be implemented in any number of ways, for example: defining only one isolated domain as cacheable; tagging cache contents to indicate which isolated domain the content belongs to, and the cache is selectively flushed for contents of a particular isolated domain; or completely flushing the cache. 
     Similar to the cache, the MMU/TLB can exist above the point where the domain identifier is added to an instruction. Direct modification to the MMU/TLB would be a secure operation and the address tables should either be secure or in the correct domain. As the domain identifier is used to determine permissions based on physical addresses rather than virtual addresses, there is no security breach if a TLB is “corrupted” to point to an undesirable address. 
     Although the exemplary embodiment is described above as a mechanism for securing access between codes in non-trusted domains for a processor core, the concept of multiple domains can be expanded to be an identifier for a task within the overall system. For example, the task may be to allocate bus bandwidth or processing time. This is normally done at the operating system level, but in this alternative embodiment, domains are used where there is more than one operating system running on the system. For example, a single digital signal processor (DSP) is used to perform multiple tasks, such as processing of multimedia and modem functions. Each task is assigned a different operating system or real-time operating system (RTOS), and is not allowed to occupy more than its allotted space on the system. Domains can be used at all levels of the system, such as allowing different fractions of a shared cache to be allocated to different tasks, different amount of bus bandwidth, etc. The domain identifier can also be used for prioritization of the tasks with the system. 
     A method and apparatus for providing security for codes running in non-trusted domains in a processor core have been disclosed. The method and apparatus configure a processor core to include a trusted domain and a plurality of isolated domains. Each of the isolated domains is assigned a unique domain identifier. One or more resources are associated with each of the isolated domains. The associations are stored as permissions to access the physical addresses of the resources. A code to be executed by a hardware device is associated with one of the isolated domains, and the unique domain identifier for the assigned isolated domain is written to the hardware device. When the hardware device executes the code, each instruction is logically tagged with the domain identifier written to the hardware device. The instruction is identifiable as a request to access a physical address of a resource. The hardware device compares the domain identifier of the instruction with the permissions of the physical address in the instruction. If the domain identifier of the instruction has permission to access this physical address, then access to the resource at the physical address is allowed. Access to the resource is otherwise blocked. In this manner, codes assigned to different isolated domains can run independently within the same processor core without interference from each other. Further, since the permissions are configured based on the physical addresses of the resources, concerns related to software-based security mechanisms are not relevant. 
     The invention has been described in accordance with the embodiments shown, and one of ordinary skill in the art will readily recognize that there could be variations to the embodiments, and any variations would be within the spirit and scope of the invention. For example, the invention can be implemented using hardware, software, a computer readable medium containing program instructions, or a combination thereof. Software written according to the invention is to be either stored in some form of computer-readable medium such as memory CD-ROM, or is to be transmitted over a network, and is to be executed by a processor. Consequently, a computer-readable medium is intended to include a computer readable signal, which may be, for example, transmitted over a network. Accordingly, many modifications may be made by one of ordinary skill in the art without departing from the spirit and scope of the appended claims.