Back to Blog
How CoreGuard Supports More Secure Compartmentalization


Last year, the costs associated with cybercrime for businesses skyrocketed 23 percent, raising their annual costs to $11.7 million, on average, according to Accenture’s 2017 Cost of Cyber Crime Study. Worse yet, the study found that the most expensive component of a cyberattack is associated with information loss, accounting for an astounding 43 percent of the total cost of cybercrime.

While stats like these are alarming, they should come as no surprise. News sites never seem to run out of a steady supply of stories around data breaches—some of which are massive, such as Equifax’s, that is costing the company $4 billion and counting.

Fortunately, compartmentalization is a growing segment of the cybersecurity space and new innovations, such as CoreGuard™ have helped expand the availability of compartmentalization solutions to include open ISAs, such as RISC-V.

What is compartmentalization & why is it important?

In a cyber world of complex and esoteric solutions, compartmentalization is refreshingly simple to understand and, believe it or not, an example from World War II helps highlight this.

While the Manhattan Project is most famously known for leading to the development of nuclear weapons, it was also key to laying the groundwork for how we think about compartmentalization in information security, today.

Back in 1942, Major General Leslie Groves used compartmentalization to make sure that no one working on the atomic bomb had enough information to create a national security crisis. Those who were responsible for enriching uranium had no idea why they were doing it or what it would be used for. Parts of the bomb that needed to be manufactured were designed, developed, and assembled in different facilities with the factory workers having no idea how the pieces fit together or that they even interacted with each other at all.

The genius here is that by restricting knowledge on a need-to-know basis, the Manhattan Project was able to avoid the types of leaks or spy work that might compromise it. And that’s the basic idea behind compartmentalization: controlling and limiting access to information.

Today, compartmentalization at its most basic level supports the principle of least privilege (PoLP). The PoLP is the practice that each component of a system is only able to access the information it needs in order to perform a computation. Some popular compartmentalization solutions, such as Arm’s TrustZone, refer to these two distinct compartments as “trusted” and “untrusted” zones, with private information falling into the former category and public information into the latter. (More on this later.)

By separating information into separate, appropriate compartments, and limiting who can access each compartment, we can better protect the information and feel more confident that the people accessing it are 1) authorized to and 2) doing so without malicious intent.

What are the limitations of Compartmentalization?

If there’s no easy solution to information security, then there certainly isn’t a perfect one either. It’s just the reality of today’s landscape: all solutions have their strengths, as well as their limitations, and compartmentalization is no different.

Fortunately, understanding the limitations of compartmentalization can help us understand where risks may lie within our systems, as well as help us understand what other solutions are needed to provide even better security to the end user.

One such limitation of compartmentalization has to do with applications. While compartmentalization does an excellent job of making sure applications in one compartment don’t interact with, or compromise, the applications of a separate compartment, compartmentalization doesn’t actually make these applications any less vulnerable to attack. All software is vulnerable because all software has bugs which means even applications within a “trusted” compartment can be compromised and compartmentalization can only stop the attacker from gaining access to other compartments. If, for example, someone was able to gain access to a trusted compartment and compromise an application therein, all compartmentalization can do is limit the scope of the damage to said compartment.

This makes compartmentalization well suited to systems such as smartphones, where the mobile vendor has a suite of services (for example: authentication, trusted boot, over-the-air updates, networking, and cellular stacks) that need to be protected from third-party applications that may not be trustworthy. This helps ensure that the third-party applications stored in one compartment can’t disrupt the important phone vendor services located in a separate compartment.

It’s also allowed for the adaptation of smartphones in the workplace, with one notable implementation being Samsung’s Knox security, which allows you to place sensitive work material in a protected compartment that can’t be accessed by any of your public applications, like apps downloaded from the Google Play Store.

Another important limitation comes from the fact that many compartmentalization solutions can only assign permission and memory attributes to a predefined set of memory regions. When a system can only compartmentalize into a couple of zones, it’s easier for a malicious actor to launch attacks which try to manipulate data in a way they shouldn’t.

For example, a code injection attack can exploit a software vulnerability (such as a buffer overflow) to introduce arbitrary code that will change the system’s course of execution. The injected code may try to write to an area of memory that is read-only, or execute code when it should be reading data.

How does CoreGuard support more secure Compartmentalization?

CoreGuard™ is a silicon IP that was designed, in part, to eliminate the limitations of compartmentalization—either on its own, or by strengthening already available solutions.

As a sentry processor, CoreGuard acts like a bodyguard to protect embedded systems from cyberattacks. It monitors every instruction executed by the host processor to ensure that it complies with a defined set of security, safety, and privacy rules. These rules are called micropolicies, and they can be customized to the meet the user’s specific needs.

This makes CoreGuard an ideal integration for users who already have a compartmentalization solution, but want to create a more secure system by going a step further to protect applications and software within each compartment.

As mentioned, CoreGuard monitors every single instruction sent to the host processor and will do this regardless of whether the instructions are coming from a trusted or untrusted zone. If an instruction violates one of the programmed micropolicies, CoreGuard will stop it from executing, before any damage can be done.

Since CoreGuard is enforced in silicon and not software, it can’t be compromised over the network. Further, since the technology lives directly on the SoC, it can operate without the rest of the system being able to access it or even see it.

This means device makers can leverage any industry-leading compartmentalization solution of their liking, and then use CoreGuard to reinforce and further harden that solution by allowing CoreGuard to protect the software and applications stored within each compartment or zone.

With that said, if you’re not already leveraging or considering a compartmentalization solution, then CoreGuard can handle both for you.

For example, implementing a simple two-compartment policy is pretty straightforward and can easily be expanded upon.

To accomplish this, we first have to track the compartment in which the system is operating. CoreGuard tracks the current compartment as metadata on the Program Counter. Then, by adding metadata to instructions in a distinguished EnterTrustedMode function, the compartmentalization policy will notice when a compartment switch is invoked.

The Compartmentalization Micropolicy, when it sees an instruction in EnterTrustedMode executing, can set the metadata for the Program Counter to indicate that the Trusted compartment is in effect. A corresponding ExitTrustedMode function can then be used to reset the metadata on the Program Counter. The following two rules keep track of which mode the system is in.

  1. If the current instruction is labeled "in EnterTrustedMode function", then update metadata Compartment(PC) = “Trusted”
  2. If the current instruction is labeled "in ExitTrustedMode function", then update metadata Compartment(PC) = "Not Trusted”

CoreGuard provides access control for Compartmentalization

At boot time, a designated instruction word at the end of EnterTrustedMode is assigned metadata that will trigger the first rule above; similarly for ExitTrustedMode. The compartmentalization policy will also declare whether the Program Counter starts as Trusted or Not Trusted.

Besides switching between compartments, the other critical element of a compartmentalization policy is to indicate which code and data is accessible to which compartment. CoreGuard establishes access to memory at boot time by executing a micropolicy in which untrusted mode can only access memory (functions and data) that is labeled “untrusted,” whereas trusted mode can access all memory.

As part of its secure boot process, CoreGuard consults a metadata database in the boot ROM for tagging of memory (application and data). While it is straightforward to specify an arbitrary number of compartments using CoreGuard micropolicies, let’s stick with the two-compartment example, for now.

In this scenario, the boot ROM will segregate all data and instructions into those two compartments by marking the metadata associated with each word in memory as it is loaded.

Once the metadata for all words of memory is annotated with the compartment in which that memory resides, CoreGuard can implement general rules for the different classes of operation encountered as code executes on the machine. The following two rules check whether an operation is allowed:

  1. If the current instruction is Jump/Branch/Call, allow the instruction if Compartment(PC) == Compartment(TargetInstruction)
  2. If the current instruction is Load (from memory), or Store (to memory), allow the instruction if Compartment(PC) == Compartment(MemoryReferenced)

Having more than two compartments, and specifying how the different compartments are allowed to interact, is a powerful approach towards the goal of “least privilege” system design.

With least privilege design—or principle of least privilege (POLP)—each module has only the access/privileges it needs to accomplish its specific function. That way, if one module is compromised, damage is minimized.

It is easy to modify our Compartmentalization Micropolicy to allow global access if the compartment noted on the Program Counter is Trusted. Also, our Compartmentalization Micropolicy can be extended to any number of compartments.

The first rule states that if we see a control transfer instruction, the compartment of the target instruction should match the current compartment, which is tracked on the Program Counter. For example, to jump into code marked as Trusted, the Program Counter must already be marked as “in Trusted zone.” The second rule checks memory access similarly. For example, to load from or store to memory labeled Trusted, the Program Counter must be labeled as “in Trusted Zone.” Similar rules are straightforward for fall-through control flow, and for allowing Trusted mode to access code and data labeled Not Trusted.

CoreGuard goes beyond simple Compartmentalization

Simple compartmentalization solutions can only establish a predefined number of compartments, often opting for two, basic trusted and untrusted zones. This simple compartmentalization does an excellent job of protecting trusted software components from being corrupted by untrusted applications that are either malicious or have been compromised. However, it fails to prevent individual modules from being compromised. In other words, simple compartmentalization limits the scope of damage due to a cyberattack to the compartment in which it occurred, but it doesn’t do anything to make individual software components any less vulnerable to attack.

CoreGuard goes beyond simple compartmentalization to provide more sophisticated, multiple compartment schemes that enable least privilege design.

Further, CoreGuard can be used not only for compartmentalization, but also to implement policies that actually block cyberattacks in the first place. For example, by implementing a Memory Safety Micropolicy, CoreGuard can prevent large classes of memory safety violation attacks (e.g., buffer overflow attacks), and by implementing a Taint Tracking Micropolicy, CoreGuard can track the integrity and confidentiality of data as it flows through the system to prevent the exfiltration of confidential data.

CoreGuard integrates with all currently available compartmentalization solutions, allowing users to go beyond simple compartmentalization and establish more secure systems.

To learn more about CoreGuard and how it provides more secure compartmentalization, contact Dover Microsystems, today.



Share This Post

More from Dover

PublishedNovember 04, 2021

In recent years, we have seen a significant rise in attacks on firmware.  A survey conducted by Microsoft concluded that in the last four years, there has been a 500% increase in reported firmware attacks, and 83% of surveyed businesses reported a...

Privacy Semiconductors