FAQs

CoreGuard Overview

  • What is CoreGuard?

    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.

  • How does CoreGuard work?

    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 hardware interlock 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.

  • How is CoreGuard different?

    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. Base 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

  • What are 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.

  • How many micropolicies are available?

    The number of micropolicies is completely up to the customer. CoreGuard comes with a base set of micropolicies that together can stop over 90 percent of all 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.

    Control Flow Integrity Micropolicy

    Stops attackers from redirecting the flow of execution of a program.

     

    Other micropolicies include:

    Taint Tracking Micropolicy

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

    Compartmentalization Micropolicy

    Multi-zone compartmentalization micropolicy which 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.

  • How many micropolicies can be processed at one time?

    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.

  • Who writes micropolicies?

    Many customers implement CoreGuard with its base micropolicies only, as these micropolicies alone can stop more than 90 percent of all network-based attacks.

    If you have any unique security, safety, or privacy requirements, we can work closely with you to customize our base micropolicies, or to create new ones to meet your specific conditions or requirements.

  • How are micropolicies protected?

    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.

  • How is a micropolicy violation handled?

    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.

CoreGuard Versus

  • Why aren't today's cybersecurity solutions working?

    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.

  • How does CoreGuard compare to Arm TrustZone®?

    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.

  • How does CoreGuard compare to “secure processors?”

    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 Impact

  • What impact does CoreGuard have on PPA?

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

    Power

    It depends, but on average CoreGuard adds approximately 250K 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

    Adjusting rule cache size and metadata tag size will influence area impact. The current design (1K entry rule cache) uses approximately 250K gates and 32KB of dedicated RAM panels.

  • How is CoreGuard integrated with a processor?

    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.

  • Does the host processor need to be modified?

    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.

  • What changes are made to the toolchain?

    To enforce its complete set of micropolicies, CoreGuard requires some information about the inner workings of the program it is protecting. To extract this information, we need to make some minor modifications to the GCC compiler.

    It is possible to configure a limited set of micropolicies for customers who do not want to use a modified toolchain, however, the modified GCC compiler is required for customers who desire a more robust set of micropolicies.

  • How is debugging handled?

    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.

Compatability

  • Which processors are compatible with CoreGuard?

    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.

  • What operating systems does CoreGuard support?

    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.

  • What operating systems does CoreGuard support?

    CoreGuard supports all applications, including those written in C and C++.

    For more information about CoreGuard’s compatibility, contact us today.

  • Can CoreGuard protect smartphones & laptops?

    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.

  • Can CoreGuard be integrated with embedded systems in the field?

    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.

  • How does CoreGuard work with multiple cores?

    Working with multiple cores requires that one CoreGuard Policy Accelerator and Hardware Interlock be used for each core in the SoC, with all policy accelerators and hardware interlocks sharing a single CoreGuard Policy Executor (PEX). Alternatively, multiple cores could share a single hardware interlock—but this is dependent on the SoC fabric topology. Those with further questions about, or interest in, using CoreGuard in a multi-core system are encouraged to contact us today for more details.