Patent ID: 12210615

DETAILED DESCRIPTION

A system-on-chip (SoC) isolation architecture, design, and method of operation are described wherein an SoC control point entity constructs and maintains a dynamically programmable isolation barrier around each execution domain under control of a two-way control channel data stream, thereby providing software-configured hardware enforced mechanisms for dynamic runtime software protection, isolation, and virtualization control. The disclosed SoC control point entity may be implemented as a dedicated CPU that creates a separate two-way control channel connected between the SoC control point entity and a CPU control point for each execution domain. By programming the control channel with a control channel data stream, the SoC control point entity creates an isolation barrier that is physically and programmatically separate and independent from all of the execution domain processors on the SoC, and therefore also independent from any software, including privileged software, running on those execution domain processors. In selected embodiments, the control data includes a set of pre-emption interrupt vector addresses and a set of pre-emption interrupt triggers to create a dynamic runtime isolation barrier that specifies different pre-emption actions taken by the execution domain when switching between partitions. Each control channel may be implemented with any suitable combination of control registers, routing access circuits, and/or electrical connections (power, clock, etc.) which attach or connect the execution domain to the SoC system. For example, each control channel may include an address space controller (ASC) which defines allowed or blocked address spaces for the attached execution domain. Each control channel may also include a peripheral access controller which defines allowed or blocked peripherals for the attached execution domain. In addition or in the alternative, each control channel may include a reset control block (RCB) which establishes different reset vector addresses that may be latched for the attached execution domain, depending on the type of reset being triggered. In addition or in the alternative, each control channel may include an interrupt routing block which specifies external interrupts that are allowed to reach the attached execution domain. In operation, the SoC control point entity sends startup control data to a control channel connected to an execution domain processor to control the access and isolation of the execution domain processor at boot time. In addition, new control data may be sent at any time, allowing the control channel to dynamically reconfigure the isolation barrier during runtime. In addition, the control channel can send return data back over the control channel data stream, allowing the SoC control entity to monitor the status/health of the execution domain and to take action depending on the status of the return data.

As seen from the foregoing, there are a number of advantages to the disclosed SoC control point isolation mechanism. First, the isolation barrier protection is data-driven rather than being driven by a privilege execution mode of any execution domain processor, so the isolation barrier protection is not susceptible to privilege escalation attacks. And because the isolation control mechanism is provided as a separate data stream for each execution domain, the control data provides dynamic context-specific isolation and address virtualization control for each domain, thereby eliminating any requirement of bus master device ID bits that must be carried on bus transactions. Another advantage of providing an SoC control point that is separate from the execution domain processors is that the CPU-level facilities for the relevant CPU architecture do not need to be changed, meaning that existing software environments can be used on each CPU without modification. Most importantly, since the protection, isolation, and virtualization provided by the disclosed SoC control point isolation mechanism are not dependent on the privileged execution model of the processors on the SoC, any privileged software running on any execution domain processor cannot modify or compromise the SoC control point isolation mechanisms.

Various illustrative embodiments of the present invention will now be described in detail with reference to the accompanying figures which illustrate functional and/or logical block components and various processing steps. While various details are set forth in the following description, it will be appreciated that the present invention may be practiced without these specific details, and that numerous implementation-specific decisions may be made to the invention described herein to achieve the device designer's specific goals, such as compliance with process technology or design-related constraints, which will vary from one implementation to another. While such a development effort might be complex and time-consuming, it would nevertheless be a routine undertaking for those of ordinary skill in the art having the benefit of this disclosure. For example, selected embodiments of the present invention are implemented, for the most part, with electronic components and circuits known to those skilled in the art, and as a result, circuit details have not been explained in any greater extent since such details are well known and not considered necessary to teach one skilled in the art how to make or use the present invention. In addition, selected aspects are depicted with reference to simplified circuit schematics, logic diagrams, and flow chart drawings without including every circuit detail or feature to avoid limiting or obscuring the present invention. Such descriptions and representations are used by those skilled in the art to describe and convey the substance of their work to others skilled in the art. In general, an algorithm refers to a self-consistent sequence of steps leading to a desired result, where a “step” refers to a manipulation of physical quantities which may, though need not necessarily, take the form of electrical or magnetic signals capable of being stored, transferred, combined, compared, and otherwise manipulated. It is common usage to refer to these signals as bits, values, elements, symbols, characters, terms, numbers, or the like. These and similar terms may be associated with the appropriate physical quantities and are merely convenient labels applied to these quantities. Unless specifically stated otherwise as apparent from the following discussion, it is appreciated that, throughout the description, discussions using terms such as “processing” or “computing” or “calculating” or “determining” or “displaying” or the like, refer to the action and processes of a computer system, or similar electronic computing device, that manipulates and transforms data represented as physical (electronic) quantities within the computer system's registers and memories into other data similarly represented as physical quantities within the computer system memories or registers or other such information storage, transmission or display devices.

For a contextual understanding of the security challenges presented with SoC-based information handling systems, reference is now made toFIG.1which depicts a simplified system level architecture block diagram of an information handling system wherein a single processor core1runs a plurality of partitioned software partitions5-9in memory that are populated with code from different vendors A, B, X, Y, Z which access different cloud services2-4. In an example automotive embodiment, the processor core1stores a security application, such as a GPS program from Vendor A, in the secure partition5. In addition, a general-purpose application, such as an infotainment from Vendor X or weather program from Vendor Y or video program for Vendor Z, is stored in the partitions6-8, and an automotive safety control application, such as a navigation and driver assistance application from an automotive Vendor B, is stored in safety partition9. Because the vendor-specific partitions5-9are connected to access and store data on one or more cloud-based servers (e.g., Amazon Web Services® 2, Azure® 3, or Google® 4), they are designed to be separate and independent from one another so that they do not share anything, such as programming code, security keys, intra-partition debugging access, etc. To enforce such partition separation, a hypervisor at the processor core1can provide certain levels of isolation between the individual partitions5-9, but such privileged-based isolation is not sufficient to protect against malware attacks on the processor core1since access to one partition provides access to other partitions at the same privilege level. Similarly, isolation systems which rely on processor IDs to protect peripherals or memory areas are vulnerable to privilege escalation attacks where the processor core1uses the same processor ID for all peripherals or memory areas.

For an improved understanding of selected embodiments of the present disclosure, reference is now made toFIG.2which depicts a simplified schematic block diagram of an SOC system10which includes one or more execution domains24-26, a system memory31, and a set of peripherals32-34. Each of the execution domains24-26is characterized by a single processor27-29(e.g., CPU, DSP, GPU, etc.) or a cluster of homogeneous processors. In this context, “homogeneous processors” refers to processors using the same instruction set architecture (ISA), and a “cluster of homogeneous processors” refers to an interconnected group of homogeneous processors where one operating environment (e.g., linux) may control the entire group such that from the outside it appears to be one multi-threaded processor. These processors may be of any architecture (ARM, RISC-V, PPC, etc.), and may be mixed on a given SoC implementation. The depicted SoC system10also includes a dedicated SOC control entity11which is physically and programmatically independent from all of the execution domain processors27-29on the SoC10, and independent from any software, including privileged software, running on those execution processors27-29. In selected embodiments, the SoC control entity11is a CPU running a system control program which implements an isolation control architecture by issuing control data12-14to control channels which create dynamic runtime isolation barriers21-23around corresponding execution domains24-26. As will be appreciated, the dedicated SOC control entity11may be connected and configured to communicate over a private and/or public crossbar switch or bus interconnect to the plurality of control channels1-N corresponding to the “N” execution domain processors27-29.

On the SOC system10, the independent SoC runtime control entity11is the first programmable element which executes during system boot to establish separate data stream connections12-14which configure the isolation barriers21-23around each of the execution processors/domains24-26. As described hereinbelow, each data stream12-14defines the context in which the corresponding execution domain24-26is allowed to execute in relation to accessing the system memory31and peripherals32-34or otherwise respond to system interrupts and resets. For example, the control data (e.g.,12) from the SoC control entity11to the execution domain (e.g.,24) may include data specifying allowable address ranges, access type for each of those address ranges, peripherals which the execution domain can access, interrupts which are allowed to enter the domain, reset vector addresses and triggers, pre-emption interrupt triggers and associated pre-emption vector addresses, and/or virtual-to-physical address mappings. By using separate control channel data streams12-14to configure the isolation barriers21-23around each execution domain24-26, the SoC control entity11is not required to isolate the execution domains by using processor device IDs that must be carried on bus transactions. As a result, the isolation control architecture provided by the SoC runtime control entity11is scalable to protect an unlimited number of execution domains since there is no requirement of adding more bus transaction bits for device IDs, no matter how many execution domains are added.

At startup, the SoC control point entity11sends control data12-14over different control channels1-3that are connected, respectively, to N execution domains24-26to control the ability of the execution domain processor27-29to access various system resources. In addition, the SoC control point entity11may send new control data over the control channels1-3at any time, allowing the isolation barriers21-23to be dynamically reconfigured during runtime. In this way, the SoC control point entity11creates a dynamic runtime isolation barrier21-23around each execution domain24-26.

For an improved understanding of selected embodiments of the present disclosure, reference is now made toFIG.3which depicts a simplified schematic block diagram of the SOC system10shown inFIG.2to illustrate how the SoC control entity11generates control data40over a control channel2to create a dynamic runtime isolation barrier22that specifies access and isolation constraints for actions performed by the execution domain in relation to the memory31and peripherals32-34. In selected embodiments, the control data40may specify that the isolation barrier22allow memory accesses to defined address space ranges and allowed access types (Read/Write/Execute) on each of those ranges. As a result, if a memory access request from the execution domain processor28is outside of the defined address space range, then the isolation barrier22blocks the illegal memory access request41. However, if a memory access request from the execution domain processor28is within the defined address space range, then the isolation barrier22allows the memory access request42.

In similar fashion, the control data40may specify that the isolation barrier22allow or block access requests to defined peripherals from the execution domain processor28. For example, if a peripheral access request from the execution domain processor28is to an approved peripheral32(e.g., Peripheral1), then the isolation barrier22allows the peripheral access request43. However, if a peripheral access request from the execution domain processor28is to a blocked peripheral34(e.g., Peripheral3), then the isolation barrier22blocks the peripheral access request44. The control data40may also specify that the isolation barrier22allow or block defined interrupts sent to the execution domain processor28. For example, the control data40may specify that the isolation barrier22block an interrupt request46to the execution domain processor28that is identified as an unpermitted interrupt. However, if an interrupt is identified by the control data40as a permitted interrupt request47, then the isolation barrier22allows the interrupt request47to be delivered to the execution domain processor28.

As will be appreciated, the control data40provided by the SoC control entity11enables the isolation barrier22to be programmed for isolation control of the execution domain by allowing or blocking actions that can be performed by the execution domain processor28. Examples of actions that can be allowed or blocked by the control data40include, memory or peripheral access requests by the execution domain processor28, interrupt requests the execution domain processor28, reset vector actions by the execution domain processor28, or any suitable access request to or from the execution domain processor28.

It will also be appreciated, that the control data40may be sent at any time, and not just during boot up. For example, at time t1, the SoC control entity11may send control data which specifies that the isolation barrier22block a peripheral access request46to Peripheral334, as indicated by P3 Access blocked (t1)44. However, at a subsequent time t2, the control data40may be sent by the SoC control entity11which specifies that the isolation barrier22allow a peripheral access request47to Peripheral334, as indicated by P3 Access allowed (t2) In this way, the SoC control entity11can dynamically reconfigure the isolation barrier22during runtime.

For an improved understanding of selected embodiments of the present disclosure, reference is now made toFIG.4which depicts a simplified schematic block diagram of the SOC system10shown inFIG.2to illustrate how the SoC control entity11generates control data50over a control channel2to create a dynamic runtime isolation barrier22that specifies different reset actions that can be taken by each execution domain (e.g., execution domain25) in response to different vectors V1. In selected embodiments, the control data50may dynamically set or specify vector addresses51for different reset vectors or pre-emption vectors52stored in memory31that may be latched, depending on the type of reset or pre-emption being triggered. For example, the control data50may specify that a first type of reset is latched to a first vector address V153in memory31where one or more reset instructions are stored for processing the first type of reset. In addition, the control data50may specify that a second type of reset is latched to a second vector address V254in memory31where one or more reset instructions are stored for processing the second type of reset. Likewise, the control data50may specify that a third type of reset is latched to a third vector address V355in memory31where one or more reset instructions are stored for processing the third type of reset.

As disclosed herein, the control data50may configure the isolation barrier22to direct any number of reset types to different reset vector addresses52in memory31. In selected embodiments, the SoC control entity11sends reset control data50by loading a vector address52corresponding to a predetermined reset type into a control channel2control register. At some later time, the predetermined reset type is activated/triggered by the SoC control entity11by setting a bit in a control channel2control register, where the bit corresponds to the aforementioned predetermined reset type, and this activation causes the execution domain processor to immediately start fetching instructions from the corresponding reset vector address52in memory31. And since the SoC control entity11is able to dynamically set the control data at any time to latch an individual execution domain25to a different reset vector address based on the type of reset triggered, the SoC control entity11can reset an execution domain that is hung, or can reset an execution domain for a safety and/or security violation. In this way, the reset performance of the execution domain25may be dynamically configured under software control by the SoC control entity11to provide flexible, runtime resets for an individual domain, in contrast to conventional hardware-based reset systems which provide a fixed reset solution to the entire SoC system so that all execution domains are reset together.

For an improved understanding of selected embodiments of the present disclosure, reference is now made toFIG.5which depicts a simplified schematic block diagram of the SOC system10shown inFIG.2to illustrate how the SoC control entity11generates control data60over a control channel2to create a dynamic runtime isolation barrier22by generating new control data63in response to monitored actions by the control channel2. As depicted, the control data60is a 2-way control data stream that includes return data62that is sent to the SoC control entity11by the control channel2in response to monitored events being detected by the control channel2. In selected embodiments, the return data62from the control channel (e.g.,2) to the SoC control entity11may include illegal address space access attempts, and may also optionally include checkpoint data so that the health of the execution domain25can be monitored. In addition, the 2-way control data stream60includes new control data63that is generated by the SoC control entity11and sent to the control channel2to update the runtime control of the execution domain25. For example, the new control data63from the SoC control entity11to the control channel (e.g.,2) may include data specifying allowable address ranges, access type for each of those address ranges, peripherals which the execution domain can access, interrupts which are allowed to enter the domain, reset vector addresses and triggers, pre-emption interrupt triggers and associated pre-emption vector addresses, and/or virtual-to-physical address mappings. With the 2-way control data stream60providing an opportunity to feedback information to the SoC control entity11, check points can be established at the control channel2so that the SoC control entity11can monitor the health or performance of the execution domain25. For example, if an illegal memory access61attempts to access memory31outside of an allowed address range, the control channel2may be configured to send a return data message62to the SoC control entity11identifying the illegal memory access attempt. In response, the SoC control entity11may send new control data63which configures the control channel2and/or execution domain processor28to take corrective action, such as reloading the execution domain software, resetting the execution domain, or taking the execution domain offline.

As seen from the foregoing, there are numerous benefits of implementing the isolation control architecture with a separate and programmable SoC control entity that dynamically programs the control channel to create an isolation barrier around each execution domain. First, the disclosed isolation control architecture allows different execution domains in the SoC system to be isolated from one another with dynamically reconfigurable isolation barriers to suit changing system needs at startup and during runtime. In addition, the isolation performance is not dependent on the privileged execution modes of any of the execution domain processors. Instead, execution domain access to system resources is dynamically configured by a control entity that is outside of the scope of any execution domain processor/CPU control point or any privileged software running on said execution domain processor/CPU control point. As a result, even if the highest privilege level in the execution domain is compromised, the runtime system control is not compromised. In addition, the disclosed isolation control architecture uses a data-driven control mechanism that is completely agnostic to any underlying processor architecture (ARM, RISC-V, PPC, etc.) in the execution domains, and can support processors of any type (CPU, DSP, GPU, etc.) without changes to the control software. The disclosed isolation control architecture also provides a control data feedback capability so that return data sent back from the control channels to the runtime control entity can be used to make fine-grained changes to the system configuration.

For an improved understanding of selected embodiments of the present disclosure, reference is now made toFIG.6which depicts a simplified schematic block diagram of the SOC system10shown inFIG.2to illustrate how the SoC control entity11generates control data70over a control channel2that includes virtual-to-physical address mappings to create a dynamic runtime virtualization isolation barrier71that specifies access and isolation constraints for actions performed by the execution domain25in relation to the memory31and peripherals32-34. In selected embodiments, the control data70may specify that the virtualization isolation barrier71allow the associated execution domain25to process only specified or approved interrupt requests and/or reset requests associated with defined reset triggers. In addition, the control data70may specify that the virtualization isolation barrier71allow only memory accesses to defined SoC virtual address space ranges and allowed access types (Read/Write/Execute) on each of those ranges. In addition, the control data70may specify virtual-to-physical address mapping data so that the virtualization isolation barrier71can translate or map the defined SoC virtual address space ranges into SoC physical address space ranges. As a result, if a memory access request72from the execution domain processor28is outside of the defined SoC virtual address space range, then the virtualization isolation barrier71blocks the illegal memory access request72. However, if a memory access request72(e.g., 0x0) from the execution domain processor28is within the allowed SoC virtual address space range, then the virtualization isolation barrier71uses the virtual-to-physical address mapping data to transform the memory access request72into a SoC physical address73(e.g., 0xffff0000) before allowing the memory access request73to proceed to memory31.

In similar fashion, the control data70may specify that the virtualization isolation barrier71for an execution domain25allow or block access requests to defined peripherals from the execution domain processor28. For example, if a peripheral access request74from the execution domain processor28is to an approved peripheral32(e.g., Peripheral1), then the virtualization isolation barrier71uses the virtual-to-physical address mapping data to allow the peripheral access request74to access the approved peripheral32. However, if a peripheral access request from the execution domain processor28is to a blocked peripheral34(e.g., Peripheral3), then the virtualization isolation barrier71blocks the peripheral access request.

In allowing peripheral access requests, it will be appreciated that the virtualization isolation barrier71may use the virtual-to-physical address mapping data to remap virtual address space contentions for SoC resources at the SoC level. For example, if two execution domains (e.g.,25,26) have issued approved peripheral requests74,77to virtual addresses for the same peripheral device (e.g., Peripheral1), the virtualization isolation barrier71for the first execution domain25may use its virtual-to-physical address mapping data to allow the peripheral access request74to access the approved peripheral32, while the virtualization isolation barrier76for the second execution domain26may use its virtual-to-physical address mapping data to remap the peripheral access request77to access the approved peripheral34.

As disclosed herein, the control data70provided to configure the virtualization isolation barrier71enables an address space virtualization at the SoC level that is “outboard” of any memory management unit (MMU) in the execution domains25,26. In particular, even if the execution domain25has an MMU, the address coming out of the MMU is an SoC virtual address72that is mapped to an SoC physical address73by the virtualization isolation barrier71. This allows for virtualization of memory-mapped peripherals at the SoC level. This SoC-level virtualization is outside of the scope of any privileged software running in any execution domain.

It will also be appreciated, that the control data70may be sent at any time to configure the virtualization isolation barrier71, thereby dynamically virtualizing the approved memory address ranges and peripherals across the entire SoC with a potential mix of execution domain types and differing processor/CPU architectures, independent of any software running at any privilege level within the execution domains25-26. Since the virtualization isolation barrier71may be configured to virtualize the address ranges and peripherals at the SoC level without the knowledge of the execution domains24-26, there is no requirement for virtualization hardware or software in the execution domain. And because virtualization is outside of the scope of the execution domain, the software running in the execution domain(s) does not need to be specifically designed or built for a virtual environment, thereby simplifying the execution domain software. The use of control data70to configure the virtualization isolation barrier71also eliminates any requirement for running a software agent or hypervisor in the execution domain. Another advantage of using separate control data streams (e.g.,70,75) to separately configure the virtualization isolation barriers71,76at the SoC level is that virtualization can be established across multiple execution domains, even if they are of differing underlying processor type or architecture

For an improved understanding of selected embodiments of the present disclosure, reference is now made toFIG.7which depicts a simplified block diagram of an access control channel81having a programmable front end82and a signals-based back end83. Connected between the SoC control entity11and execution domain86, the access control channel81is connected to exchange control data80with the SoC control entity11. In particular, control data80that is received from the SoC control entity11may be used to configure a separate access control channel (e.g.,81) for each execution domain (e.g.,86), thereby creating a dynamic runtime isolation barrier for each execution domain that provides enforceable mechanisms for runtime protection, isolation, virtualization, and execution control (context-switching). And by providing a separate access control channel81for each execution domain, the SoC system can host up to n independent software execution environments (partitions) wherein the isolation, virtualization, and context-switching between these environments is handled via the runtime control data stream80from the SoC control entity11.

In the access control channel81, the programmable front end82is connected to receive the control data80that enters the data stream, and the back end83is the end point of the data stream where all of the signals are connected to the execution domain86under control of the control data stream80. In between the front end82and back end83are the various hardware and software mechanisms84-85needed to interpret the control data80and implement control of the relevant signals to and from the execution domain86.

The programmable front end82is only accessible by the SoC control entity11and may be implemented with a common, standardized, or uniform programmable interface84that is the same for all types and architectures of execution domain processors. In selected embodiments, the common programmable interface84will be memory-mapped over a private address space so that it will only be accessible by the SoC control entity11. In other embodiments, the common programmable interface84will be memory-mapped over a public address space or other suitable interconnect. One of the advantages of using a uniform input interface84is that the SoC control entity11can control one or more execution domains without any knowledge of the underlying processor or CPU structure87. This means that the software running on the SoC control entity can be much simpler (by virtue of communicating with a standard programmable interface84) and still support any processor type or architecture at the execution domain without knowledge of that processor (by virtue of the functional customization provided by the hardware and software mechanisms85). The uniform input interface84also allows any number of access control channels to be added to an SoC system design without requiring any hardware redesign.

The back end83of the access control channel81may include multiple hardware and software mechanisms85that are connected to the common programmable interface84to provide the hardware and software connection between the execution domain86and the rest of the SoC system, While the programmable front end interface84remains the same for all processor types and architectures, the back end control circuitry85will be specific to the processor architecture87of the connected execution domain86. For example, the back end83may include an interrupt routing control block85A which is programmed by the control data80which assigns one or more “allowed interrupts” to the execution domain86so that the interrupt routing block85A determines if an interrupt request to the execution domain CPU87is an “allowed” interrupt before forwarding any “allowed” interrupts to the execution domain86. In addition, the back end83may include a reset control block85B which is programmed by the control data80to establish one or more reset vector addresses in memory for different types of allowed resets so that the reset control block85B determines if a received reset request is a reset type that is “allowed” for the execution domain86before setting a reset line to the execution domain86. The back end83may also include a JTAG debug control unit85C which is programmed by the control data80with jtag debug control data to selectively enable or disable the scan chain control signal going into the CPU87on a per-partition basis, thereby providing dynamic partition-based jtag debug control for isolating software partitions across jtag debug operations. In addition, the back end83may include a preemption control block85D which is programmed by the control data80to establish one or more pre-emption vector addresses in memory for different types of allowed pre-emption interrupt triggers so that the preemption control block85D determines if a received pre-emption interrupt request is “allowed” for the execution domain86before setting a pre-emption event line to the execution domain86. The back end83may also include a power management block85E which is programmed by the control data80to switch power modes in the execution domain86in response to a low-power request. In addition, the back end83may include a messaging interface block85F which is programmed by the control data80to provide a service interface which allows the execution domain CPU87to request services from the SoC control entity11. The back end83may also include an address space control and mapping block85G which is programmed by the control data80to assign address locations for “allowed” memory and/or peripherals for the execution domain86so that the address space control and mapping block85G determines if an access request88by the execution domain CPU87is “allowed” before forwarding any “allowed” access requests89to the memory or peripheral. In embodiments where virtualization of the isolation barrier is supported, the address space control and mapping block85G may be programmed with virtual-to-physical address mappings which are used to map or translate an SoC virtual address for an access request88into an SoC physical address for an “allowed” memory and/or peripherals access request89, thereby creating a dynamic runtime virtualization isolation barrier around each execution domain.

By providing the access control channel between the SoC control entity11and each execution domain, isolation of the different execution domains can be achieved without requiring deviceIDs or streamIDs either internally or externally, to communicate over the system crossbar or interconnect switch. As a result, any number of access control channels may be attached to the SoC control entity11without requiring further hardware redesign of the system crossbar or interconnect switch. This means that there is no limitation on the number of execution domains that may be supported by a given SoC design, making it simple to define device families with differing numbers of execution domains.

For an improved understanding of selected embodiments of the present disclosure, reference is now made toFIG.8which depicts a simplified schematic block diagram of the SOC system10shown inFIG.2to illustrate how the SoC control entity11generates control data90over a control channel2that includes a set of pre-emption interrupt vector addresses and a set of pre-emption interrupt triggers to create a dynamic runtime isolation barrier91that specifies different pre-emption actions taken by the execution domain25when switching between partitions96-98. In particular, control data90that is received from the SoC control entity11may be used to configure a separate isolation barrier91for each of n partitions hosted by an execution domain (e.g.,25), thereby creating n dynamic runtime isolation barriers for each of N execution domains. Thus configured, each dynamic runtime isolation barrier provides enforceable mechanisms for runtime protection, isolation, virtualization, and execution control (context-switching) that are independent from those of the various processor-based subsystems, and which are immune from the kinds of attacks that compromise the integrity of conventional systems.

In selected embodiments, the control data90may specify that the isolation barrier91allow the associated execution domain25to switch between different software execution environments (partitions) by using the control data90to configure one or more pre-emption interrupt vectors92by defining a set of pre-emption interrupt triggers and a corresponding set of pre-emption interrupt vector addresses93-95in memory31. In response to each trigger initiated by the SoC control entity11, the execution domain25latches or retrieves an independently defined pre-emption vector address (e.g.,93) and the execution domain processor28begins fetching instructions from that latched address93. While three pre-emption vector trigger/address pairs93-95are shown, the number of these trigger/address pairs may differ, depending on the defined implementation. In selected embodiments, the pre-emption interrupt is non-maskable by the execution domain processor28, and may be used by the SoC control entity11to switch the execution context or partition at the execution domain28. Because the pre-emption interrupt is not defined as part of the architecture of the processor or CPU28, it is outside of the scope of the operating environments in any of the execution domains24-26, and in fact the execution domain operating environments24-26are unaware of the pre-emption interrupt or of the context switching that occurs. This context switching can be routine context switching between partitions based on priority or a time-sliced model, or it may be in response to some specific situation, such as a safety violation, security breach, or low-power state.

Unlike a reset, the pre-emption interrupts are recoverable. And to the extent the pre-emption interrupt is not defined by the underlying processor architecture in the execution domains, any privileged software running in those domains does not attempt to have a handler for this interrupt. Instead, the pre-emption interrupt is an SoC-level mechanism that is best defined and implemented by the SoC architecture. With these properties, the software running in the execution domain partitions does not have to be specially built for this context-switching architecture. Instead, the isolation barrier91keeps the partitions strictly isolated from each other and from the rest of the system. In addition, the isolation barrier91may be implemented as a virtualization isolation barrier91which can remap addresses and virtualize peripherals, all without any software agent running on the execution domain processor.

To enable partition switching with the pre-emption vectors, the SoC control entity11installs and maintains code for one or more pre-emption vectors92at the vector address93-95in memory31. Although the pre-emption vector code92is executed by the execution domain processor28, it is stored in external memory31so that it is not part of the execution domain25or any of its partitions. In addition, the pre-emption vector code92cannot be modified by the execution domain processor28or any privileged software running in any of the partitions. Before the pre-emption trigger is initiated, the SoC control entity11sends control data90to map the memory region92containing the pre-emption interrupt handler. This memory region92is marked as “execute only”, and the execution domain processor28has no ability to write into this memory space, and can only fetch and execute the code found there. This code saves the state of the current context executing on the processor28, and then loads the context for the next partition to be executed. This is necessary because there are registers in the processor core28which can only be accessed by the core, and the state of these registers must be saved/restored on a context switch. While the execution domain processor28is saving the current core state and loading the state for the next partition, the SoC control entity11is sending control data90for the address ranges which the next partition is allowed to access, and the virtual mappings for those address ranges. Once the SoC control entity11has completed this task, the “next” partition has become the current partition, and the execution domain processor is directed to start executing the current partition code.

To illustrate an example sequence of operations for using pre-emption vectors to switch between partitions,FIG.8depicts a first step (1) where the execution domain25is executing software running in a first partition96. Subsequently at a step (2), the SoC control entity11issues control data90which activates one of the defined pre-emption interrupt triggers. At step (3), the execution domain processor28responds to the trigger by latching the pre-emption vector address93associated with the trigger, and at step (4), the execution domain processor28starts fetching instructions from the latched pre-emption vector address93. Subsequently at a step (5), the SoC control entity11issues new control data90which removes access from the first partition96(e.g., by saving the current control channel state from the first partition96) and adds access to a second partition97(e.g., by loading the previously stored control channel state for the second partition97). And at step (6), the execution domain processor28switches to execute software running in a second partition97once the vector code has been executed.

Partitions can be switched based on usage models, priority models, time-slice models, or any other cause including safety/security violations. The partition being switched out has no knowledge of the switch, and when it comes back into context (switched back in), it begins executing right where it last left off. This defines an SoC level context-switch mechanism that requires no software agent in the execution domains, and is out of scope of any privileged software running in those domains.

Since the partitions in each execution domain have no fixed ID number, each execution domain can have as many as n independent software partitions which are run one at a time under control of the SoC control entity11which switches between the partitions and the isolation between the partitions via the control data stream90. As each partition is switched into context, the SoC control entity11sends new control data90to configure the virtualization isolation barrier90with allowed address ranges, peripherals, interrupts, and virtual mappings for the new partition. Thus, each partition runs in its own space, isolated from the other partitions, and all under the control of the SoC control entity. While any (or all) of the partitions running on any of the execution domains may have a traditional hypervisor-based context-switching environment running, this CPU-based context-switching does not interfere or conflict with the SoC-level context switching that is controlled by the SoC Control entity11.

There are a number of benefits and advantages of using the control data90to switch between partitions on an execution domain by configuring the isolation barrier91with the pre-emption interrupt vector(s)92having defined pre-emption interrupt triggers and corresponding pre-emption interrupt vector addresses. First, the context/partition switching between multiple (n) software partitions on an execution domain processor is controlled on the SoC level without use of any resources of the execution domain processors, including privilege execution modes of those processors. Second, SoC level context-switching can be provided for multiple (N) execution domains which may have different underlying processor architectures or types. In addition, SoC level context-switching can implement context-switching and load-balancing across execution domains of same microprocessor architecture.

For an improved understanding of selected embodiments of the present disclosure, reference is now made toFIG.9which depicts a simplified schematic block diagram of the SOC system10shown inFIG.2to illustrate how the SoC control entity11generates control data100over a control channel2that includes JTAG debug control data to create a dynamic runtime virtualization isolation barrier101that controls and limits JTAG debug operations to access only a specified partition running on the execution domain25and to prevent access to the other n−1 partitions running on the execution domain25. With existing SoC systems, a partition running in a given execution domain that is under JTAG debug can potentially access all partitions running on that execution domain processor. Conventional attempts to limit JTAG debug operations rely on the privilege execution mode of the underlying processor in the execution domain, but independent software partitions running at the same privilege level cannot be distinguished by such methods. And while extensive and expensive third-party debug tooling is available and widely used for debugging the execution domain processor, such tools are not designed to limit operations to specific partitions on the execution domain processor.

In order to restrict or control partition access during JTAG debug operations, the control data100that is received from the SoC control entity11may be used to configure a separate virtualization isolation barrier101for each of n partitions hosted by an execution domain (e.g.,25), thereby creating n dynamic runtime isolation barriers for each of N execution domains. In addition, the control data100includes JTAG debug control data for selectively enabling or disabling JTAG debug operations on a per-partition basis, and each execution domain (e.g.,25) includes JTAG circuitry which is connected and configured to respond to the control data100to precisely isolate JTAG debug operations to a specific partition or set of partitions. Within a partition, the virtualization isolation barrier101is configured to restrict the access that the debugger has on specific ranges in memory. And it can do all this while supporting standard JTAG debug tooling. Controlled by control data100from the independent SoC control entity11, the disclosed JTAG debug control mechanism is out of scope of any privilege software running in the execution domains, and thus cannot be compromised by such software.

In selected embodiments, the control data100specifies, for each partition, a JTAG debug enable/disable signal (e.g., Partition1Debug Signal, Partition2Debug Signal, . . . Partition n Debug Signal) that the virtualization isolation barrier101provides to the execution domain processor28. If the JTAG debug signal has not been expressly enabled for a partition, then it is disabled by default for the partition (e.g., Partition1Debug Signal=0). For a currently active partition in the execution domain25(e.g., Partition2104), if the JTAG debug signal is enabled (e.g., Partition2Debug Signal=1), then the debug signal to the processor28is asserted while that partition104is actively executing. However, if the JTAG debug signal is not enabled (e.g., Partition2Debug Signal=0) for a currently active partition in the execution domain25(e.g., Partition2104), then the debug signal to the processor28is de-asserted while that partition104is executing. The JTAG debug signals to each execution domain processor28, which is under the control of the control data stream100, is reevaluated on each partition context switch and either enabled or disabled accordingly.

In addition, the control data100can configure the virtualization isolation barrier101to switch the scan chain output106to the scan chain bypass register109on a memory access107to an inactive region (e.g.,102), either thru the processor28or directly thru the memory envelope provided by the virtualization isolation barrier101, thereby restricting the viewing of selected memory regions even for a partition under debug. In selected embodiments, if JTAG debug operations have been enabled for a partition (e.g., Partition2104), then for each address range which that partition has access through the virtualization isolation barrier101, the JTAG debug is marked as “active” or “inactive.” If an address range is marked as “active” (e.g., for Partition2104), then the debug memory windows and disassembly windows work as normal. However, if an address range is marked as “inactive” (e.g., Inactive Region102), then a debug memory accesses107to the inactive region is switched to the scan chain bypass register109as the output source, whether they be initiated by a memory window or a disassembly window. For example, by routing the scan output thru a JTAG-defined 1-bit bypass register109, no information about the inactive memory region102is leaked. In no case will the debugger have access to any memory region/address range which the partition running without debug does not have access to. This prevents viewing sensitive code/data thru the debugger. With this approach, existing third-party tools in the form of libraries and data sets can be kept isolated, even as the code that executes them is debugged.

When a partition context-switch occurs and the control data100has not enabled the JTA debug signal for the new active partition, the debug signal to the core is de-asserted and no debug operation is possible. To provide additional access protection, the virtualization isolation barrier101may respond to the debug enable/disable signals in the control data100by selectively disabling the Test Data Input (TDI), Test Data Output (TDO), and Test Clock (TCK) signals going to the JTAG header, thereby making the header electrically inert in whole or in part when JTAG debug operations are not enabled.

By configuring the virtualization isolation barrier101to limit JTAG debug access to specific memory partition regions, there is no need to modify external (typically third-party vendor) JTAG debug hardware and software. This means that debug schemes based on privilege modes of execution will still operate as intended within the software partition. If debug is enabled for user-mode code but not for supervisor mode code, then the external JTAG hardware will continue to detect the privilege mode signals from the core and respond accordingly.

For an improved understanding of selected embodiments of the present disclosure, reference is now made toFIG.10which depicts a simplified block diagram of an SoC system200having a first isolation control architecture where an SoC control CPU201uses a private address space202(e.g., a system crossbar switch, Network-on-Chip, cache-coherent interconnect, system interconnection infrastructure, etc.) to program a plurality of control channels251-253which create a plurality of dynamic runtime isolation barriers215,225,235around a corresponding plurality of CPUs214,224,234which are configured to run execution domains241-243. In the depicted SoC system200, the SoC control CPU201and execution domain CPUs214,224,234may be identically designed or homogenous, or may include one or more CPUs or cores having different designs. However, the SoC control CPU201is physically and programmatically independent from all of the execution domain CPUs214,224,234, and is configured to execute a first isolation control program or thread209during boot before any of the execution domain CPUs214,224,234are released from reset.

The SoC system200also includes a public address space206(e.g., a crossbar switch, Network-on-Chip, cache-coherent interconnect, system interconnection infrastructure, etc.) connecting the SoC control CPU201to main memory207, which may include one or more levels of cache memory, such as an L1 instruction cache, L1 data cache, and/or L2 cache. In selected embodiments, the caches are internal to an execution domain, inside the isolation barriers215,225,235, and not shared between execution domains. The public address space206also connects the SoC control CPU201to one or more peripherals208. In this way, the SoC control CPU201may directly access the main memory207and peripheral(s)208over the public address space206.

Instead of being connected directly to the main memory207or peripheral(s)208over the public address space206, each of the execution domains241-243is connected indirectly to the public address space206over a corresponding control channel251-253which is connected to and controlled by the SoC control CPU201to construct and maintain a dynamically programmable isolation barrier215,225,235around each execution domain processor214,224,234, thereby providing an enforceable and dynamic runtime software isolation mechanism for each execution domain241-243. Depending on the microarchitecture of the SoC system200, each control channel251-253can be controlled and programmed by the SoC control CPU201using the private address space202which gives the SoC control CPU201exclusive access to secure resources, such as boot ROM203, interrupt controller204, a flash controller205(storing, for example, external firmware images), or other resources, such as SRAM memory, timer registers, etc. In particular, the SoC control CPU201executes the isolation control program or thread209to generate control data CD1-Nwhich is transmitted over the private address space202to program the control channels251-253. In particular, control channel1251is connected at switching address S2of the private address space202to receive programming control data CD1from the SoC control CPU201. In similar fashion, control channel2252is connected at switching address S3of the private address space202to receive programming control data CD2from the SoC control CPU201, and control channel3253is connected at switching address S4of the private address space202to receive programming control data CD N from the SoC control CPU201.

With this arrangement of intervening control channels251-253, the execution domains241-243can never access the secure resources203,204,205because there is no bus master interface from the execution domain CPUs214,224,234in the private address space of SoC control CPU201. In addition, the main memory207and peripheral(s) connected in the public address space206cannot access resources in private address space202for the same reason. The arrangement of intervening control channels251-253also means that the execution domains241-243can only access the secure resources203,204,205,251-253through service requests to the SoC control CPU201over the public address space206or through a messaging interface in the control channels251,252,253.

By programming the control channels251-253with a control channel data stream upon initialization of the SoC system200, the SoC control CPU201configures the isolation barriers215,225,235to provide an “enclosure” protection function around each execution domain241-243which is connected and configured to communicate with SoC system resources (e.g., address space(s)206, memory207, peripherals208, etc.) via the control channels251-253. As disclosed herein, each control channel251-253may be implemented with any suitable combination of control registers, routing access circuits, and/or electrical connections (power, clock, etc.) which attach or connect the execution domain to the SoC system. For example, each control channel251-253may be constructed with at least an interrupt routing block211,221,231, a reset control block (RCB)212,222,232, and an address space controller (ASC) block213,223,233. In addition, each control channel251-253may include one or more control and/or status registers which are accessible over a programmable register interface210,220,230solely from the private address space202. In this arrangement, software executing in the SoC control CPU201may securely and dynamically configure each control channel251-253during startup or runtime to create the isolation barriers215,225,235which control access to and from each execution domain CPU214,224,234associated with said control channel251-253. In addition, the SoC control CPU201may send new control data CDiat any time, allowing each control channel (e.g.,251) to be dynamically reconfigured during runtime. In addition, each control channel (e.g.,251) can send return data RDiback to the SoC control CPU201, by using the corresponding control channel (e.g.,251), thereby allowing the SoC control CPU201to monitor the status/health of the execution domain241and to take action depending on the status of the return data. As shown, there is also a connection between the SoC control CPU201and the public address space206so that the SoC control CPU201can access the public address space.

Since connections from the execution domains241-243to system resources (e.g.,207,208) on the public address space206are made through the control channels251-253, each ASC block213,223,233can be programmed by the SoC control CPU201to assign peripherals208to a specific execution domain, or permit peripherals to be shared among two or more domains. In similar fashion, access to appropriate regions of memory207and to appropriate subsets of peripherals208can be allowed or blocked by programming the ASC block213,223,233of an associated control channel251-253. In either case, an access request from the execution domain processor (e.g.,214) to a peripheral or memory address location is processed by the isolation barrier (e.g.,215) by first routing the access request to the ASC block (e.g.,213) which checks the access request against the allowed or blocked peripherals or memory addresses, and only passes the access request to the public address space206if the access request is for an allowed peripheral or memory address. By default, each ASC block213,223,233may be configured to block all outgoing access requests from an execution domain241-243except for the regions of memory and peripheral address space configured by the SoC control CPU201to be allowed for the corresponding execution domain.

In similar fashion, each control channel251-253may include an interrupt routing block211,221,231which is programmed by the SoC control CPU201to handle processing of external interrupts by the execution domain241-243. For example, when each control channel251-253is connected to receive interrupts from the interrupt controller204, the interrupt routing block211,221,231can be programmed by the SoC control CPU201to assign each execution domain one or more peripherals208that are allowed to generate interrupts for that execution domain. Thus, rather than allowing each interrupt to access each execution domain, the interrupt request to an execution domain CPU (e.g.,214) is effectively processed by the isolation barrier (e.g.,215) when the programmed interrupt routing block211,221,231determines if a received interrupt is an “allowed” interrupt (e.g., an interrupt from a peripheral assigned to its execution domain). If not, then the interrupt routing block (e.g.,211) prevents the interrupt request from reaching the execution domain CPU (e.g.,214). But if the interrupt is from an “allowed” peripheral, then the interrupt routing block211, forwards the interrupt to its corresponding execution domain CPU214.

In addition, each control channel251-253may include a reset control block212,222,232which is programmed by the SoC control CPU201to establish one or more reset vector addresses and to provide a control register to release an execution domain CPU from a power-on-reset and to trigger the reset of the execution domain CPU for different types of resets, such as a warm reset and watchdog timer reset by the SoC control CPU201. Each type of reset can have an independent reset vector address stored in memory207, which allows the software at these vector addresses to operate independently from the software at other reset vector addresses. In addition, the resetvector addresses specified in the reset control block212,222,232of the control channels251-253cannot be overridden by software in one of the execution domains, even if the instruction set architecture for the execution domain CPU permits privileged software to configure vector addresses. In this way, there is no fixed reset behavior that is fixed in hardware and applied to all execution domains241-243. Instead, each reset request to an execution domain CPU (e.g.,214) is effectively processed by the isolation barrier (e.g.,215) when the programmed reset control block212,222,232determines if a received reset is a reset type that is “allowed” for the execution domain (e.g.,241). If not, then the reset control block (e.g.,212) prevents the reset request from reaching the execution domain CPU (e.g.,214). But if the reset is an “allowed” reset request, then the reset control block212forwards the reset to its corresponding execution domain CPU214which is configured to latch a corresponding reset vector address from memory where software can be fetched and executed by the execution domain CPU.

For an improved understanding of selected embodiments of the present disclosure, reference is now made toFIG.11which depicts a simplified block diagram of an SoC system300having a second isolation control architecture where an SoC control CPU301uses a public crossbar switch302to program a plurality of control channels351-353which create a plurality of dynamic runtime isolation barriers315,325,335around a corresponding plurality of execution domain CPUs314,324,334which are configured to run execution domains341-343. In the depicted SoC system300, the SoC control CPU301and execution domain CPUs314,324,334may have homogenous or different designs, but the SoC control CPU301is physically and programmatically independent from all of the execution domain CPUs314,324,334, and is configured to execute a first isolation control program or thread309during boot before any of the execution domain CPUs314,324,334are released from reset.

As depicted, the system crossbar switch or interconnect302connects the SoC control CPU301to SoC system resources, such as boot ROM303, a flash controller304, main memory305, one or more peripherals306, an interrupt controller307, and/or other resources, such as SRAM memory, timer registers, etc. In this way, the SoC control CPU301may directly access the SoC system resources303-307over the public address space of the system crossbar switch or interconnect302. However, instead of being connected directly to the SoC system resources303-307over the system crossbar switch302, each of the execution domain CPUs314,324,334is connected indirectly to the system crossbar switch or interconnect302over a corresponding control channel351-353, each of which is programmed and controlled by the SoC control CPU301to construct and maintain a dynamically programmable isolation barrier315,325,335around each execution domain processor314,324,334, thereby providing an enforceable and dynamic runtime software isolation mechanism for each execution domain341-343. However, instead of using a private crossbar switch or interconnect to program the control channels (as depicted inFIG.10), the SoC control CPU301controls and programs the control channels351-353by sending control data messages CDiover the public crossbar switch or interconnect302to program the control channels351-353. As a result, the control channel1351is connected at switching address S5of the public crossbar switch/interconnect302to receive programming control data CD1from the SoC control CPU301. In similar fashion, control channel2352is connected at switching address S6of the public crossbar switch/interconnect302to receive programming control data CD2from the SoC control CPU301, and control channel3353is connected at switching address S7of the public crossbar switch/interconnect302to receive programming control data CDNfrom the SoC control CPU301. With this arrangement of intervening control channels351-353, the execution domains341-343can only access the SoC system resources302-307when the control data CD1-Nfrom the SoC control CPU301programs the control channels351-353to allow such access requests through the isolation barriers315,325,335.

By programming the control channels351-353with a control channel data stream upon initialization of the SoC system300, the SoC control CPU301configures the isolation barriers315,325,335to provide an “enclosure” protection function around each execution domain341-343which is connected and configured to communicate with SoC system resources302-307via the control channels351-353. As disclosed herein, each control channel351-353may be implemented with any suitable combination of control registers, routing access circuits, and/or electrical connections (power, clock, etc.) which attach or connect the execution domain to the SoC system. For example, each control channel351-353may have an interrupt routing block311,321,331, a reset control block (RCB)312,322,332, and an address space controller (ASC) block313,323,333. In addition, each control channel351-353may include one or more control and/or status registers which are accessible over a programmable register interface310,320,330from the public address space302. In this arrangement, software executing in the SoC control CPU301may securely and dynamically configure each control channel351-353during startup or runtime to create the isolation barriers315,325,335which control access to and from each execution domain CPU314,324,334associated with said control channel351-353. In addition, the SoC control CPU301may send new control data CDiat any time, allowing each control channel (e.g.,351) to be dynamically reconfigured during runtime. In addition, each control channel (e.g.,351) can send return data RDiback to the SoC control CPU301by using the public crossbar switch302, thereby allowing the SoC control CPU301to monitor the status/health of the execution domain341and to take action depending on the status of the return data.

Since connections from the execution domains341-343to system resources302-307on the system crossbar switch302are made through the control channels351-353, each ASC block313,323,333can be programmed by the SoC control CPU301to assign address locations in memory305and/or peripherals306to one or more execution domains. Once programmed, an access request from the execution domain processor (e.g.,314) to a peripheral or memory address location is processed by the isolation barrier (e.g.,315) by first routing the access request to the ASC block (e.g.,313) which checks the access request against the allowed or blocked peripherals or memory addresses, and only passes the access request to the system crossbar switch/interconnect302if the access request is for an allowed peripheral or memory address. In similar fashion, each control channel351-353may include an interrupt routing block311,321,331which is programmed by the SoC control CPU301to assign each execution domain one or more “allowed interrupts.” Once programmed, the interrupt routing block (e.g.,311) effectively enables the isolation barrier (e.g.,315) to process an interrupt request to an execution domain CPU (e.g.,314) by determining if a received interrupt is an “allowed” interrupt so that the interrupt routing block (e.g.,311) forwards any “allowed” interrupt to its corresponding execution domain CPU314, but otherwise prevents the interrupt request from reaching the execution domain CPU. In addition, each control channel351-353may include a reset control block312,322,332which is programmed by the SoC control CPU301to establish one or more reset vector addresses for different types of resets. Once programmed, the reset control block (e.g.,312) effectively enables the isolation barrier (e.g.,315) to process each reset request to an execution domain CPU (e.g.,314) by determining if a received reset is a reset type that is “allowed” for the execution domain (e.g.,341). If not, then the reset control block (e.g.,312) prevents the reset request from reaching the execution domain CPU (e.g.,314). But if the reset is an “allowed” reset request, then the reset control block312forwards the reset to its corresponding execution domain CPU314which is configured to latch a corresponding reset vector address from memory where software can be fetched and executed by the execution domain CPU.

Each of the SoC control CPUs and execution domain CPUs described herein may be configured to execute instructions and to process data according to a particular instruction set architecture (ISA). In a selected embodiment, a highly suitable example of a design for a processor core or CPU is a StarCore® SC3850 processor core that runs at 1 GHz. Those of ordinary skill in the art also understand the present invention is not limited to any particular manufacturer's microprocessor design. The processor core or CPU may be found in many forms including, for example, any 32-bit or 64-bit microprocessor manufactured by NXP®, Motorola®, Intel®, AMD®, Sun® or IBM®. However, any other suitable single or multiple microprocessors, microcontrollers, or microcomputers may be utilized. In the illustrated embodiment, each of the SoC control CPUs and execution domain CPUs may be configured to operate independently of the others, such that all CPUs may execute in parallel. In some embodiments, each of the CPUs may be configured to execute multiple threads concurrently, where a given thread may include a set of instructions that may execute independently of instructions from another thread. Such a CPU may also be referred to as a multithreaded (MT) core. Thus, a single multi-core SoC200with four cores will be capable of executing a multiple of four threads in this configuration, with a first core handling the SoC control CPU functionality as a top priority core, and with the remaining cores handling the functionality of the execution domain CPUs. However, it should be appreciated that the invention is not limited to four processor cores or CPUs, and that more or fewer cores or CPUs can be included. In addition, the term “core” refers to any combination of hardware, software, and firmware typically configured to make requests and/or receive status information from associated circuitry and/or modules (e.g., one or more peripherals, as described below). Such cores include, for example, digital signal processors (DSPs), central processing units (CPUs), microprocessors, and the like. These cores are often also referred to as masters, in that they often act as a bus master with respect to any associated peripherals. Furthermore, the term multi-core (or multi-master) refers to any combination of hardware, software, and firmware that includes two or more such cores, regardless of whether the individual cores are fabricated monolithically (i.e., on the same chip) or separately. Thus, a second core may be the same physical core as first core, but has multiple modes of operation (i.e., a core may be virtualized).

In accordance with selected embodiments of the present disclosure, the SoC isolation control architecture may be implemented with a multithreaded processor architecture whereby a single processor core runs two or more hardware execution threads. One example of such a multi-threading processor is a switch-on event multithreading (SOEMT) processor which provides prioritized, pre-emptive thread scheduling in response to assertion of events. In particular, there are properties of SOEMT processors which may be used to provide execution domain isolation on an SOEMT processor where a single CPU core supports N hardware threads, where N is equal to at least 1 plus the total number of execution domains supported on the SoC system. In prioritizing the N threads, a first thread (Thread0) has the highest hardware-defined priority for use with executing the SoC control entity function. The remaining lower priority threads may have relative priorities for running the execution domains of the SoC system. For example, threads executing real-time processes should have a higher priority than threads executing non-real-time processes. During each processor cycle, instructions are executed for a highest-priority, active thread. When a higher-priority thread becomes active, the executing thread is pre-empted by the higher-priority thread, and only resumes execution when all higher-priority threads are inactive. Each thread may be active or inactive, and inactive threads are activated by assertion of events assigned to that thread.

In SOEMT processors, events are physical signals that originate from either hardware or software. Events are similar to interrupt requests, but with two critical differences. The first difference is that events never force asynchronous redirection of program flow. Once activated, a thread runs to completion, and subsequent event assertions are recorded, but not recognized, until the software in the thread executes a wait-for-event (WFE). If a WFE is executed when the thread has no other asserted events, that thread becomes inactive. The second difference between events and interrupt requests is that the address at which execution resumes following a WFE is controlled by software and is typically the address following the WFE instruction or another address specific to the software state when executing that particular WFE. In contrast, interrupts save the previous execution address and commence execution at a predefined interrupt vector address.

As the highest priority thread, Thread0will, upon activation, pre-empt any other thread and cannot itself be pre-empted. The execution domain isolation mechanisms discussed herein take specific advantage of these two properties. Each hardware thread has a dedicated set of registers that include, at least, all architecturally-defined user mode registers of the ISA.

Unlike typical multithreaded processors, threads are not isomorphic. Thread0is the only thread having full access to the physical address space, including the full machine-mode control and status register (CSR) space in the case of a RISC-V processor. In addition, only Thread0is active after hardware reset. Further, Thread0is the only thread that can: (1) execute instructions that force another thread into a known state, which is used to initialize the other threads; (2) recover from catastrophic errors or software compromise within the other threads; and (3) initiate context switching by threads supporting execution domains with multiple, independent software partitions. Privilege levels available within each thread are those defined by the underlying ISA, but, even at the highest privilege level, threads other than Thread0do not have full access to low-level CPU hardware or the full, physical address space.

For an improved understanding of selected embodiments of the present disclosure, reference is now made toFIG.12which depicts a simplified block diagram of an SOC isolation architecture400which uses a single, multi-threaded SOEMT processor core410to create a dynamic runtime isolation barrier around each execution domain. As depicted, the single, multi-threaded SOEMT processor core410executes an SoC control entity domain420and all execution domains (e.g.,430,440,450) in separate threads. Private address space415of the SoC control entity domain420is designed into the CPU hardware. While the multi-threaded SOEMT processor core410includes four hardware threads, any number of hardware threads greater than or equal to two may be present.

Depending on the microarchitecture, the SoC control entity domain420can be implemented within the SOEMT processor410on thread0(the “isolation thread”421) using thread-aware logic within address-generation hardware, which generates an illegal address exception if a thread other than thread0attempts to access an address in private address space415. Alternatively, the SoC control entity domain420can be implemented externally to the SOEMT processor410as part of the address decoding. Yet another alternative is to implement the control channels432,442, and452to map the addresses which would otherwise access the private address space415to access different locations, either within the public address space475or (if private resources are present within execution domains) internal to the respective execution domains430,440, or450. If the SoC control entity domain420is implemented externally to the SOEMT processor410, the originating thread number accompanies each memory transaction as an ancillary attribute. Private address space415gives the SoC control entity domain420exclusive access to secure resources, such as boot ROM422, SRAM424, timer registers426, and a flash controller428(storing, for example, external firmware images). On the other hand, each of the execution domains430,440,450and the SoC control entity domain420, can access the public address space475through their control channels, including, for example, memory460and peripherals470. In this manner, the execution threads (execution threads431,441,451) are not isomorphic to the isolation thread, in that they are not directly provided access to the secure hardware registers and memories within the private address space415. The execution threads only access the secure resources through service requests to the highest priority isolation thread421(e.g., thread0). In addition, the peripheral(s)470in public address space475cannot access resources in private address space415, as indicated by unidirectional interface block480.

Each execution domain (430,440, and450) is coupled to the SoC control entity domain420via a control channel (432,442, and452, respectively) that is configured by the SoC control entity domain420upon initialization of the SoC system. Once configured, each control channel432,442,452effectively creates an isolation barrier433,443,453around a corresponding execution domain430,440,450so that the execution domain threads431,441,451can have only approved or “allowed” communications with system resources. To create the isolation barriers433,443,453, the control channels432,442, and452are constructed with at least an address space controller, a reset control block, and an interrupt routing block. In addition, each control channel432,442, and452may have control/status registers, accessible solely from the private address space415of the SoC control entity domain420, that allow software executing in the highest priority control thread421to configure access allowed by the execution threads431,441, or451associated with said control channel. The control channel management interfaces (designated by the dashed line connecting the isolation domain private address space415to the control channels432,442, and452) are accessible solely by the highest priority control thread421via the private address space415.

Memory bus connections from the execution domains430,440,450are made through the corresponding control channel432,442,452which effectively creates the isolation barrier433,443,453. ASC programming can assign peripherals470to a specific execution domain, or permit peripherals to be shared among two or more domains. Access to appropriate regions of memory and to appropriate subsets of peripherals can be through the ASC of an associated control channel. By default, the ASC blocks all outgoing access from an execution domain thread, so only those regions of memory and peripheral address space configured by the highest priority control thread421for that execution domain are accessible.

In addition, the execution domains430,440,450are connected to receive external interrupts the interrupt routing block of the control channel432,442,452. If a peripheral is assigned to an execution domain, then interrupts from that peripheral block are allocated to that execution domain. Otherwise, the interrupt is blocked.

The reset control block of each control channel432,442,452establishes addresses of reset vectors and provides a control register to release a thread from a power on reset and to trigger the reset of the hardware thread for various other types of resets. Each reset type can have independent reset vector addresses, which allows the software at these vector addresses to operate independently from the software at other reset vector addresses. In addition, the vector addresses specified in the reset control block cannot be overridden by software in an execution domain, even if the ISA permits privileged software to configure vector addresses.

An inter-thread event generation mechanism may be used for the execution threads431,441, and451to request services from highest priority control thread421. Depending on the architecture of SOEMT processor core410, the inter-thread event generation mechanism can be a machine instruction that asserts a hardware event, a subset of the processor's normal system call/environment call mechanism, or a predefined programmatic interface using inter-thread flag bits that generate events to the target thread.

On an SOEMT processor core410using RISC-V ISA where there is a separate control and status register (CSR) address space, the CSRs pertaining to hardware configuration, clock and power management, physical address space, and the control channels only appear in the machine mode CSR space of thread0. Other threads have only a basic set of machine mode CSRs as required to conform to the RISC-V Privileged Architecture specification. Threads other than thread0on a RISC-V processor can be reset from thread0. Execution domains can support more than one software partition. If such multi-partition support is needed, the execution domain needs to support a resumable non-maskable interrupt facility, assertable from the isolation domain.

Service requests from an execution domain430,440,450to the SoC control entity domain420are communicated by generating events which activate thread0. On a RISC-V processor, for example, this can be implemented by decoding a subset of function codes of the environment call (ECALL) instruction to assert particular events to thread0. But due to ECALL being used for system calls on RISC-V, and assignment of function codes in the RISC-V ABI standard not being yet finalized, embodiments can implement a custom service request instruction for this purpose. For use with ISAs that do not have explicit provision for custom instructions, events alternatively can be asserted by software using inter-context communication (ICC) flag bits accessed via CSRs or memory-mapped I/O, as appropriate for the relevant ISA.

In the disclosed SOEMT processor embodiments, resource control pursuant to a system call is performed by a physically different hardware thread. As a result, privilege escalation within an execution domain cannot be used to override or circumvent proper handling of system calls. Software in any execution domain430,440,450has no ability to alter the privilege level of software in the SoC control entity domain420, and cannot access the private address space414of the SoC control entity domain420. And since events activate thread0at an address controlled by thread0rather than via an exception vector, it is not possible to redirect control by malicious software that corrupts a vector table. Similarly, because the system call handler uses a return stack in private memory accessible solely within the SoC control entity domain420, neither is a return-oriented attack. Because SOEMT uses a run-to-completion model, with events to thread0recognized only after the isolation software has executed a wait-for-event (WFE), control flow in SoC control entity domain420is not asynchronously redirected due to actions by software in other domains, which prevents the use of switch-on event multithreading from creating race conditions that might be exploitable. Furthermore, because thread0cannot be preempted, interrupts to execution threads that occur while thread0is active are not handled until after thread0executes a WFE, so interrupts initiated by execution thread activity cannot affect isolation thread execution.

For an improved understanding of selected embodiments of the present disclosure, reference is now made toFIG.13which depicts a simplified flow chart500showing a sequence of steps performed by a SOC control entity501in combination with one or more control channels502to create a dynamic runtime isolation barrier around each execution domain503. As discussed above, the sequence begins at SoC boot startup when the SoC control entity501generates one or more initial control data streams (step510). On the SoC system, the SoC control entity501is a physically and programmably independent control point which is dedicated to the isolation control function. And rather than providing a software-based isolation function executing in a privileged state on one (or more) of the processors on the SoC system, the SoC control entity501is configured to generate a separate runtime control data stream at step510for each execution domain being isolated.

At step511, the SoC control entity501sends a control data stream to the control channel502for each execution domain503being isolated. In selected embodiments, there may be a plurality of control channels502-1,502-2,502-nwhich correspond, respectively, to a plurality of execution domains503-1,503-2,503-nwhich are being isolated. In such cases, the SoC control entity501may send a separate control data stream to each of the control channels502-1,502-2,502-n. In any case, the control data stream transmission step511may be sent over private and/or public crossbar switch or bus interconnect to the plurality of control channels502corresponding to the “N” execution domain processors503.

At step520, the control channel (e.g.,502-1) receives the control data stream from the SoC control entity501over the private and/or public crossbar switch or bus interconnect. In receiving the control data stream, each control channel502-1is connected between the SoC control entity501and a protected execution domain503-1in the SoC system to effectively intercept and control what the execution domain processor is allowed to access or receive from the SoC infrastructure and each addressable memory or peripheral block.

At step521, the control channel502-1processes the control data to create a dynamic runtime isolation barrier around the corresponding execution domain503-1by configuring the control channel502-1to specify access and isolation constraints. To this end, the control data is stored at the control channel502-1in one or more control registers and/or routing or access control blocks which control the electrical connection for each execution domain. Once stored at the control channel502-1, the control data stream defines the context which the execution domain503-1is allowed to execute within. For example, control data may be stored at the control channel502-1as an allowed or blocked memory address space in an address space controller. The control data may also be stored at the control channel502-1as an allowed or blocked peripheral device in a peripheral access controller. In addition or in the alternative, the control data may be stored at the control channel502-1as a blocked interrupt in an interrupt routing controller. In addition or in the alternative, the control data may be stored at the control channel502-1as a reset vector address and/or reset trigger in a reset control block. In addition or in the alternative, the control data may be stored at the control channel502-1as virtual-to-physical mappings to enable creating of a virtualization barrier around the execution domain. In addition or in the alternative, the control data may be stored at the control channel502-1as pre-emption vector data which includes vector addresses and corresponding pre-emption triggers to control partition switching by the virtualization isolation barrier around the execution domain. In addition or in the alternative, the control data may be stored at the control channel502-1as partition debug control data to selectively enable or disable debug operations at each partition by the virtualization isolation barrier around the execution domain. As seen from the foregoing, the control channel502may be programmed to effectively provide an “enclosure” protection function around each execution domain503. In contrast, conventional isolation control techniques employ an “exclosure” protection function (e.g., to define an area from which unwanted intrusions are excluded) by using dedicated secure enclave subsystems to construct an isolation barrier around the SoC infrastructure and each addressable memory or peripheral block to block accesses by the execution domains. In addition to the conceptual simplicity of positioning the control channel502-1to provide enclosure protection around the execution domains, enclosure-based protection has a number of performance benefits over exclosure-based protection. First, the isolation barrier around the execution domain prevents unauthorized accesses from consuming power or wasting cycles on the shared infrastructure (e.g., crossbar switch, bus interconnect). In addition, the opportunity for malicious software to perform on-chip denial-of-service attacks is reduced. Another advantage is that infrastructure hardware may be reduced since there is no transaction source identifier needed to be conveyed from initiator to responder.

After the isolation barrier is programmed and activated by the control channel502at step521, each execution domain (e.g.,503-1) is activated to leave reset and begin executing software at step530. As illustrated, the execution domains503are controlled to begin executing after the SoC control entity501executes during system boot so that the control data stream can be generated and sent to create the dynamic runtime isolation barriers before starting the execution barriers503.

At step531, the execution domain (e.g.,503-1) accesses system resources (e.g., addressable memory, peripherals, interrupts, and/or resets) subject to the access and isolation limits established by the dynamic runtime isolation barrier. Controlled exclusively by the control data stream generated by the SoC control entity501and provided to the control channel502, each dynamic runtime isolation barrier prevents any software being executed with the execution domain503from being physically able to access the control channel502. In addition, the dynamic runtime isolation barrier at each execution domain503prevents unauthorized outgoing accesses (e.g., memory or peripheral accesses) from leaving their respective execution domains of origin, and also prevents unauthorized incoming accesses (e.g., interrupt requests, resets, etc.) from entering their respective destination execution domains.

To provide feedback to the SoC control entity501, each control channel502at an execution domain503may be configured to generate a return data stream at step522. For example, check points can be established at the execution domain503-1to monitor its health or performance. For example, if an illegal memory or peripheral access request is issued by the execution domain503-1, the control channel502-1may be configured to generate a return data stream identifying the illegal memory access attempt. In addition or in the alternative, the return data stream may be generated if an unpermitted interrupt or reset request is sent to the execution domain503-1. At step523, the control channel502-1sends the return data stream over private and/or public crossbar switch or bus interconnect to the SoC control entity501.

At step514, the SoC control entity501receives the return data stream from the control channel502-1over the private and/or public crossbar switch or bus interconnect. After receiving the return data stream, the SoC control entity501updates the control data stream at step515. For example, the updated control data stream may specify one or more corrective actions, such as reloading the execution domain software, resetting the execution domain, or taking the execution domain offline. Subsequently, the updated control data stream is sent to the control channel at step511, and the processing sequence continues.

In addition or in the alternative, the SoC control entity501may be configured to periodically update or change the control data stream provided to each control channel502. To this end, the SoC control entity501may include a timer that is set after sending the control data stream to the control channel502. The duration of the timer could be any desired interval, though in selected embodiments, the timer interval is at least sufficient to allow the execution domain(s) to leave reset and begin executing software. For so long as the timer has not expired (negative outcome to detection step512), there is no action taken by the SoC control entity501. However, once the timer expires (positive outcome to detection step512), the SoC control entity501updates the control data stream at step513. For example, the updated control data stream may specify one or more predetermined actions, such as allowing memory accesses to a specified address range that had previous been blocked, or vice versa. Subsequently, the updated control data stream is sent to the control channel at step511, and the processing sequence continues.

By now, it should be appreciated that there has been provided herein a multi-processor system-on-chip (SOC) method, apparatus, and system for securely operating one or more execution domains on a single integrated circuit system on a chip. As disclosed, the multi-processor SOC includes an execution domain processor that is configured to run a first execution domain which hosts multiple independent software partitions by accessing, for each software partition, one or more SoC resources, where the SoC resources may include an addressable memory, one or more peripherals, an interrupt request and/or a reset request. In addition, the multi-processor SOC includes a first control point processor that is physically and programmatically independent from the execution domain processor and configured to generate a first runtime isolation control data stream for controlling access to the one or more system-on-chip resources by identifying at least a first SoC resource that each software partition is allowed to access, where the first runtime isolation control data stream includes one or more pre-emption interrupts, each including a set of pre-emption interrupt vector addresses and a set of corresponding pre-emption interrupt triggers which are set by the first control point processor. In selected embodiments, the first control point processor is configured to run an isolation control program that is independent from any privileged software running on the execution domain processor. In selected embodiments, the first runtime isolation control data stream is a runtime virtualization isolation control data stream which the first control point processor uses to configure the access control circuit to provide a dynamic runtime virtualization isolation barrier for controlling access to the one or more system-on-chip resources by the first execution domain by identifying at least a first system-on-chip resource that the first execution domain is allowed to access and mapping a virtual address for the first system-on-chip resource to a physical address for the first system-on-chip resource. In other selected embodiments, the first runtime isolation control data stream generated by the first control point processor does not include a device identifier for the first control point processor. In other selected embodiments, the first control point processor is configured to generate the first runtime isolation control data stream before the execution domain processor is released from reset to run the first execution domain. In selected embodiments, the first control point processor is configured to install partition instructions at each pre-emption interrupt vector address in memory. In selected embodiments, the partition instructions stored in memory at each pre-emption interrupt vector address are executed by the execution domain processor to save a current context of a current partition executing on the execution domain processor before loading a saved context for a second partition to be executed on the execution domain processor. In other selected embodiments, the pre-emption interrupts are non-maskable by the execution domain processor. In selected embodiments, the first control point processor may be configured to generate the one or more pre-emption interrupts so that the execution domain processor switches between the independent software partitions based on a partition priority model or a time-slice model. In other embodiments, the first control point processor may also be configured to generate the one or more pre-emption interrupts so that the execution domain processor switches between the independent software partitions in response to a predetermined safety violation event, a predetermined security breach event, or a predetermined low-power state event. The multi-processor SOC also includes an access control circuit connected between the execution domain and the one or more system-on-chip resources and configured to provide a dynamic runtime isolation barrier in response to the first runtime isolation control data stream, where the dynamic runtime isolation barrier enables the execution domain processor to switch between the independent software partitions in response to each separate pre-emption interrupt trigger by fetching partition instructions from a corresponding pre-emption interrupt vector address in memory that is associated with said separate pre-emption interrupt trigger. In other embodiments of the disclosed multi-processor SOC, the first access control circuit is configured to generate feedback data in response to any blocked access by the first execution domain, and the first control point processor is configured to generate an updated runtime isolation control data stream for controlling access to the one or more system-on-chip resources by the first execution domain in response to the feedback data.

In another form, there has been provided a method, system, and apparatus for controlling operations of an execution domain on a multi-processor system-on-chip. In the disclosed method, a runtime isolation control data stream is generated by a control point processor for controlling access to one or more system-on-chip resources by an execution domain processor, where the runtime isolation control data stream includes one or more pre-emption interrupts, each including a set of pre-emption interrupt vector addresses and a set of corresponding pre-emption interrupt triggers which are set by the control point processor. In selected embodiments, the one or more pre-emption interrupts are non-maskable by the execution domain processor. In selected embodiments, the control point processor generates the runtime isolation control data stream before the execution domain processor is released from reset to run the first execution domain. The disclosed method also includes generating, by an access control circuit connected between the execution domain processor and the one or more system-on-chip resources, a dynamic runtime isolation barrier in response to the runtime isolation control data to control access to the one or more system-on-chip resources by the execution domain processor that is physically and programmatically independent from the control point processor, where the dynamic runtime isolation barrier enables the execution domain processor to switch between the independent software partitions in response to each separate pre-emption interrupt trigger by fetching partition instructions from a corresponding pre-emption interrupt vector address in memory that is associated with said separate pre-emption interrupt trigger. In selected embodiments, the partition instructions stored in memory at each pre-emption interrupt vector address are executed by the execution domain processor to save a current context of a current partition executing on the execution domain processor before loading a saved context for a second partition to be executed on the execution domain processor. In addition, the disclosed method includes running a first execution domain on the execution domain processor which is configured to host multiple independent software partitions by accessing, for each software partition, one or more system-on-chip resources in compliance with the dynamic runtime isolation barrier. In selected embodiments, the control point processor generates the runtime isolation control data stream by generating the one or more pre-emption interrupts so that the execution domain processor switches between the independent software partitions based on a partition priority model or a time-slice model. In other embodiments, the control point processor generates the runtime isolation control data stream by generating the one or more pre-emption interrupts so that the execution domain processor switches between the independent software partitions in response to a predetermined safety violation event, a predetermined security breach event, or a predetermined low-power state event. In selected embodiments, the disclosed method may also include generating, by the access control circuit, feedback data in response to any blocked access by the execution domain processor; and then generating, by the control point processor, updated runtime isolation control data stream for controlling access to the one or more system-on-chip resources by the execution domain processor in response to the feedback data.

In yet another form, there has been provided a system-on-chip, device, system, and method of operation for controlling operations of an execution domain. The disclosed system-on-chip includes an interconnect and one or more system-on-chip resources connected to the interconnect. In addition, the disclosed system-on-chip includes a system-on-chip control point entity coupled to the interconnect and configured to generate a plurality of two-way runtime isolation control channel data streams, including at least a first two-way runtime isolation control data stream which includes one or more pre-emption interrupts, each having a set of pre-emption interrupt vector addresses and a set of corresponding pre-emption interrupt triggers which are set by the system-on-chip control point entity. The disclosed system-on-chip also includes a plurality of execution domains that are not directly connected to the interconnect that include at least a first execution domain which is configured to host multiple independent software partitions by accessing, for each software partition, one or more system-on-chip resources in compliance with a dynamic runtime isolation barrier. In addition, the disclosed system-on-chip includes a plurality of access control channels attached, respectively, between the plurality of execution domains and the interconnect. As disclosed, each access control channel that is attached to an execution domain is coupled to receive a corresponding two-way runtime isolation control channel data stream from the system-on-chip control point entity and is configured to define a corresponding dynamic runtime isolation barrier in response to the corresponding two-way runtime isolation control channel data stream, where the corresponding dynamic runtime isolation barrier enables the attached execution domain to switch between independent software partitions in response to each separate pre-emption interrupt trigger by fetching partition instructions from a corresponding pre-emption interrupt vector address in memory that is associated with said separate pre-emption interrupt trigger.

Some of the above embodiments, as applicable, may be implemented using a variety of different information processing systems. For example, althoughFIG.2and the discussion thereof describe an exemplary SoC isolation control architecture, this exemplary architecture is presented merely to provide a useful reference in discussing various aspects of the invention. Description of the architecture has been simplified for purposes of discussion, and it is just one of many different types of appropriate architectures that may be used in accordance with the present disclosure. Those skilled in the art will recognize that the boundaries between logic blocks are merely illustrative and that alternative embodiments may merge logic blocks or circuit elements or impose an alternate decomposition of functionality upon various logic blocks or circuit elements. Thus, it is to be understood that the architectures depicted herein are merely exemplary, and that in fact many other architectures can be implemented which achieve the same functionality. In an abstract, but still definite sense, any arrangement of components to achieve the same functionality is effectively “associated” such that the desired functionality is achieved. Hence, any two components herein combined to achieve a particular functionality can be seen as “associated with” each other such that the desired functionality is achieved, irrespective of architectures or intermedial components. Likewise, any two components so associated can also be viewed as being “operably connected,” or “operably coupled,” to each other to achieve the desired functionality.

In addition, the example SoC system embodiments illustrated inFIGS.7-8may be implemented with circuitry located on a single integrated circuit or within a same device. Alternatively, the SoC system embodiments may include any number of separate integrated circuits or separate devices interconnected with each other. For example, the main memory107may be located in whole or in part on the same integrated circuit as the SoC control CPU101or on a separate integrated circuit or located within another peripheral or slave discretely separate from other elements of SoC system100. Peripherals107may also be located on separate integrated circuits or devices.

Furthermore, those skilled in the art will recognize that boundaries between the functionality of the above-described operations merely illustrative. The functionality of multiple operations may be combined into a single operation, or the functionality of a single operation may be distributed in additional operations. Moreover, alternative embodiments may include multiple instances of a particular operation, and the order of operations may be altered in various other embodiments.

All or some of the software described herein may be received from elements of the SoC system, such as, for example, from computer readable media such as memory107or other media on other computer systems. Such computer readable media may be permanently, removably or remotely coupled to an information processing system, such as the SoC system100. The computer readable media may include, for example and without limitation, any number of the following: magnetic storage media including disk and tape storage media; optical storage media such as compact disk media (e.g., CD-ROM, CD-R, etc.) and digital video disk storage media; nonvolatile memory storage media including semiconductor-based memory units such as FLASH memory, EEPROM, EPROM, ROM; ferromagnetic digital memories; MRAM; volatile storage media including registers, buffers or caches, main memory, RAM, etc.; and data transmission media including computer networks, point-to-point telecommunication equipment, and carrier wave transmission media, just to name a few.

In selected embodiments, the SoC systems disclosed herein are part of a computer system such as an embedded microcontroller. Other embodiments may include different types of computer systems. Computer systems are information handling systems which can be designed to give independent computing power to one or more users. Computer systems may be found in many forms. A typical computer system includes at least one processing unit, associated memory and a number of input/output (I/O) devices.

A computer system processes information according to a program and produces resultant output information via I/O devices. A program is a list of instructions such as a particular application program and/or an operating system. A computer program is typically stored internally on computer readable storage medium or transmitted to the computer system via a computer readable transmission medium. A computer process typically includes an executing program or portion of a program, current program values and state information, and the resources used by the operating system to manage the execution of the process. A parent process may spawn other, child processes to help perform the overall functionality of the parent process. Because the parent process specifically spawns the child processes to perform a portion of the overall functionality of the parent process, the functions performed by child processes (and grandchild processes, etc.) may sometimes be described as being performed by the parent process.

The term “program,” as used herein, is defined as a sequence of instructions designed for execution on a computer system. A program, or computer program, may include a subroutine, a function, a procedure, an object method, an object implementation, an executable application, an applet, a servlet, a source code, an object code, a shared library/dynamic load library and/or other sequence of instructions designed for execution on a computer system.

Benefits, other advantages, and solutions to problems have been described above with regard to specific embodiments. However, the benefits, advantages, solutions to problems, and any element(s) that may cause any benefit, advantage, or solution to occur or become more pronounced are not to be construed as a critical, required, or essential feature or element of any or all the claims. The term “coupled,” as used herein, is not intended to be limited to a direct coupling or a mechanical coupling. As used herein, the terms “comprises,” “comprising,” or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Furthermore, the terms “a” or “an,” as used herein, are defined as one or more than one. Also, the use of introductory phrases such as “at least one” and “one or more” in the claims should not be construed to imply that the introduction of another claim element by the indefinite articles “a” or “an” limits any particular claim containing such introduced claim element to inventions containing only one such element, even when the same claim includes the introductory phrases “one or more” or “at least one” and indefinite articles such as “a” or “an.” The same holds true for the use of definite articles. And unless stated otherwise, terms such as “first” and “second” are used to arbitrarily distinguish between the elements such terms describe. Thus, these terms are not necessarily intended to indicate temporal or other prioritization of such elements.

Although the described exemplary embodiments disclosed herein are directed to various embodiments, the present invention is not necessarily limited to the example embodiments which illustrate inventive aspects of the present invention that are applicable to a wide variety of SoC systems and operational methodologies. Thus, the particular embodiments disclosed above are illustrative only and should not be taken as limitations upon the present invention, as the invention may be modified and practiced in different but equivalent manners apparent to those skilled in the art having the benefit of the teachings herein. Accordingly, the foregoing description is not intended to limit the invention to the particular form set forth, but on the contrary, is intended to cover such alternatives, modifications and equivalents as may be included within the spirit and scope of the invention as defined by the appended claims so that those skilled in the art should understand that they can make various changes, substitutions and alterations without departing from the spirit and scope of the invention in its broadest form.