FAQs

CoreGuard is proprietary silicon IP that empowers processors in embedded systems to defend themselves in real-time from network-based attacks. CoreGuard acts as a separate, sentry processor to the host processor—monitoring every instruction executed to ensure it complies with a set of security, safety, and privacy rules, called micropolicies. If an instruction violates an existing micropolicy, CoreGuard stops it from executing before any damage can be done. More information about CoreGuard is available here.

First, it collects metadata about the application for every piece of data and every instruction that is handled by the host processor—data that was otherwise discarded either during compilation or run-time. Then, for each instruction, CoreGuard crosschecks the metadata against the set of micropolicies installed on the SoC. Finally, if an instruction violates any micropolicy, CoreGuard’s policy enforcer blocks the instruction from executing before any damage can be done. If there are no micropolicy violations, the instruction completes with almost no delay. CoreGuard micropolicies are designed to stop entire classes of attacks, including buffer overflows, code injection, data exfiltration, and even safety violations.

CoreGuard was specifically designed to solve the cybersecurity problem at the root cause—the attacker’s ability to exploit software vulnerabilities and take over the processor. CoreGuard’s innovative design principles are what makes it the only cybersecurity solution that can deliver true security, safety, and privacy to embedded systems.

Integrate with Hardware Because Hardware is Unassailable

Hardware is not vulnerable to cyberattacks like software because an attacker cannot alter a silicon chip by accessing it over a network.

Integrate with Existing Processor Architectures

It is neither practical nor possible to replace the world’s processors with entirely new architectures designed for today’s security threats. This is why CoreGuard integrates with existing RISC processor cores and Instruction Set Architectures, essentially “retrofitting” existing architectures with a powerful new cybersecurity defense.

Defend Against Entire Classes of Network-based Attacks—Not Just Specific Attacks

All complex software contains bugs, and attackers find and exploit these vulnerabilities to gain access to an embedded system’s processor. MITRE’s Common Weakness Enumeration (CWE) list divides 705 known vulnerabilities into seven classes, and CoreGuard micropolicies are designed to stop these classes of attack. This lets CoreGuard block entire classes of attack, and even allows CoreGuard to defend against zero-day attacks, which exploit vulnerabilities before they’re known to exist.

Provide Customizable and Updatable Enforcement for an Evolving Threat Landscape

CoreGuard micropolicies are written in the proprietary Dover Policy Language (DPL), a domain-specific language designed only for the purpose of writing CoreGuard micropolicies. CoreGuard comes with a base set of micropolicies, but DPL allows for a granular level of customization. Our existing micropolicies can be customized and new micropolicies can be written to compose the exact protection a system needs. If new threats emerge or safety and security requirements change, micropolicies can be securely updated on systems, even after they are deployed.

Isolate CoreGuard Software from System Software

CoreGuard’s policy enforcer hardware maintains a strict separation between application software (including the operating system) and CoreGuard micropolicies and metadata. Only CoreGuard hardware can see and run CoreGuard micropolicies.

Micropolicies are custom security, safety, and privacy rules. CoreGuard micropolicies maintain metadata for every piece of data and every instruction handled by the host processor, giving CoreGuard the information it needs to distinguish between good and bad instructions. For each instruction, CoreGuard crosschecks the metadata against a set of micropolicies. If an instruction violates any micropolicy, CoreGuard blocks the instruction from executing before any damage can be done. Violation handling is customized at the application level to implement appropriate responses. CoreGuard micropolicies are written in the proprietary Dover Policy Language (DPL), a domain-specific language. Because DPL is designed only for the purpose of writing micropolicies, it includes specialized features and constructs that enable our micropolicy developers to write precise micropolicies with the most efficient code possible; most micropolicies are written with a dozen or fewer rules. Additionally, DPL has built-in properties to support formal verification. Formal verification of software means DPL mathematically authenticates the code to ensure it’s only doing what it’s designed to do.

The number of micropolicies is completely up to the customer. CoreGuard comes with a base set of micropolicies that together can stop the most prevalent and severe network-based attacks—with absolutely no alteration to your application. Our base micropolicies are as follows:

Read/Write/Execute (RWX) Micropolicy

Establishes traditional Read/Write/Execute permissions for code and data, but with fine-grained resolution.

Heap Micropolicy

Enforces protection on heap blocks in memory.

Stack Micropolicy

Enforces protection on the stack frame for a function in memory.

Other micropolicies include:

Confidentiality Micropolicy

A simple implementation of Information Flow Control relevant for both information integrity and confidentiality. The Confidentiality micropolicy considers a piece of data either “confidential” or “nonconfidential,” and tracks the influence of that data as it flows through the system. If any operands to an instruction are confidential, then the result of that instruction is also confidential.

Compartmentalization Micropolicy

CoreGuard’s Compartmentalization micropolicy divides the SoC into multiple “trusted” and “untrusted” zones. Its purpose is to protect trusted software components from being corrupted by untrusted applications that are either malicious or have been compromised by a cyberattack.

CoreGuard places no limit on the number of micropolicies that can be configured for an embedded system. Individual micropolicies are compiled into a composite micropolicy and checked simultaneously. While CoreGuard is able to enforce multiple micropolicies simultaneously, it takes only one micropolicy violation for CoreGuard to block an instruction from executing.

Many customers implement CoreGuard with its base micropolicies only, as these micropolicies are designed to stop the most prevalent and severe network-based attacks. If you have any unique security, safety, or privacy requirements, we can work closely with you to customize our micropolicies, or to create new ones to meet your specific conditions or requirements.

CoreGuard micropolicies are written in the proprietary Dover Policy Language (DPL), a domain-specific language. Because DPL is designed only for the purpose of writing micropolicies, it includes specialized features and constructs that enable our micropolicy developers to write precise micropolicies with the most efficient code possible; most micropolicies are written with a dozen or fewer rules. A smaller codebase significantly decreases the likelihood for software bugs. Additionally, DPL has built-in properties to support formal verification. Formal verification of software means DPL mathematically authenticates the code to ensure it’s only doing what it’s designed to do. In addition, micropolicies and metadata are isolated from the rest of the system in a separate, protected section of memory that cannot be seen, accessed, modified, or executed by the system’s operating system or its applications. This approach means only CoreGuard hardware can see and run CoreGuard micropolicies. CoreGuard micropolicies are also encrypted and code-signed to prove the legitimacy of their author, and to guarantee they have not been altered or corrupted since they were signed. Lastly, CoreGuard micropolicies are installed using a secure boot process to guarantee the integrity of the micropolicy code.

When an instruction violates a micropolicy, CoreGuard issues a violation via an interrupt to the host processor. How your program handles a violation is highly customizable and will depend on the type of embedded system, application, and other specific requirements. Some examples of how an application can be programmed to handle a CoreGuard violation include canceling the thread, enabling secondary operations, or turning on detailed logging.

Most cybersecurity solutions today focus on building defensive software around our networks, systems, and applications. But in reality, they only increase vulnerability by adding yet another layer of inherently flawed software. As a result, companies and individuals are left even more exposed. Coupled with this reality is the fact that processors are not equipped to do anything about it. Our embedded systems have processors with an architecture that dates back to the 1940s—an era when network intrusions could not even be imagined, never mind prevented. Conventional processors blindly execute any instructions they are presented with, even if those instructions were exploited or are unsafe; processors don’t know the difference between good and bad instructions, and they can’t enforce what they don’t know.

Arm TrustZone is a technology (currently available with Arm Cortex-A® and Cortex-M® series processors) that enforces a two-zone compartmentalization policy by dividing the SoC into “trusted” and “untrusted” zones. Its purpose is to protect trusted software components from being corrupted by untrusted applications that are either malicious or have been compromised by a cyberattack. CoreGuard strengthens compartmentalization approaches, like Arm TrustZone, by protecting applications within each compartment or zone. Fine-grained micropolicies can block cyberattacks before they take hold in each compartment. If you are integrating CoreGuard with an Arm processor that uses TrustZone, there is no need to duplicate those protections using CoreGuard. CoreGuard can complement your existing hardware security with micropolicies that target the host of vulnerabilities not covered by TrustZone. If you are using an Arm or RISC-V processor that does not have TrustZone, CoreGuard can provide compartmentalization and more.

In today’s world, most vendors claiming they have a “secure processor” mean they have added encryption, and perhaps key management, to a standard processor. Encryption and key management provide “communications security,” which helps ensure that any data going to and from the system is encrypted. Encrypting communication is a good precaution, but it alone does not warrant calling the processor “secure.” CoreGuard is the only solution aimed squarely at “computing security”—with a goal of blocking all forms of attack that can come in over a network.

CoreGuard is designed for configurable power, performance, area, and security optimization.

Power

It depends, but CoreGuard adds as few as 153K gates that run at the same speed as your processor with similar toggle rates.

Performance

CoreGuard utilizes a rule cache for negligible system performance impact. With an appropriately sized rule cache (1K), we see little to no impact on performance after a brief warm-up period.

Area

The area of CoreGuard varies, depending on the type of processor it’s protecting, the size of the rule cache, and the size of the metadata tags. The current CoreGuard design can be as low as 153K gates.

CoreGuard is delivered as an IP block. With our customers, we employ a two-phase integration process. First, we provide an interface model of CoreGuard which enables you to determine all the modifications you need to make to your SoC to integrate CoreGuard. Second, we deliver the CoreGuard RTL to synthesize your design onto an ASIC or FPGA, including toolchain and micropolicy integrations. To learn more about our engagement model and how to start evaluating CoreGuard, visit our Get CoreGuard page, today.

Yes, integrating CoreGuard requires minimal modifications to the host processor. We only require a few inputs and outputs, some of which may already be in place. These inputs and outputs include:

Non-Maskable Interrupt Input

The processor needs an NMI input; CoreGuard uses this for issuing violations. CoreGuard can use an existing NMI input or a new one can be added.

Instruction Trace Output

The processor needs a set of outputs that provide the Instruction Address (PC), Data Address, and Data Action (load/store) of every retired instruction.

Interrupt Output(s)

The processor needs interrupt outputs that inform CoreGuard of an external interrupt. This enables CoreGuard to content-switch with the host processor to keep interrupt latency low.

The modified GNU toolchain provided with the CoreGuard SDK has a debugging mode that can be used to prototype and test your applications with CoreGuard micropolicies. We work with our customers to integrate CoreGuard into their software Integrated Development Environments in order to leverage the debugging capabilities of those tools.

CoreGuard is compatible with Reduced Instruction Set Computer processors, including Arm, MIPS, and RISC-V architectures. CoreGuard is optimized for embedded systems with smaller software stacks, such as controllers and microcontrollers. If you have a particular requirement or would like more details about compatibility with a specific processor, contact us today.

CoreGuard currently supports FreeRTOS version 10. This embedded operating system is shipped with our SDKs. Support for additional real-time operating systems is in process, and a Linux solution will be offered in a future release.

CoreGuard supports all applications, including those written in C and C++. For more information about CoreGuard’s compatibility, contact us today.

Not yet. The current implementation of CoreGuard is optimized for embedded systems with smaller software stacks. At present, our focus is on protecting embedded systems, which accounts for the vast majority of processors used in today’s market.

Possibly, if the system uses an FPGA processor and has adequate memory. If the system uses an ASIC processor, CoreGuard needs to be integrated into the next design cycle.