We propose to build an autonomic platform with the following objectives:

• Enable programs to securely specify their in-memory structure and access policies to the platform, including interaction with verified shared libraries and shared components.
• After the program is recognized by the platform, detect changes to the program code/data.
• Prevent use violation, by bugs or malware, by enforcing code entry at well-known offsets.
• Prevent malware from root-kiting (invalidly hooking) critical services on the platform.
• Self-remediate the platform when an attack is detected.

Our architecture leverages privileges provided by VT-x to the VMM to monitor and protect software agents running inside a guest OS from other components of the same OS. This ensures that malware running in the guest OS is not able to tamper with critical software agents running in the same OS, even if the malware is able to achieve the highest privilege level within that OS. The VMM is measured at boot time as part of the measured boot sequence. Figure 2 shows the architectural overview.

Figure 2: Self-defending end-point architecture
click image for larger view
 

All the agents that need protection implement a data structure called the Integrity Manifest (IM). The IM is cryptographically signed by the vendor or another trusted source and it describes the structure of the agent when it is loaded into memory correctly. Other components of the architecture include the following:

• The Integrity Measurement Module (IMM) to use the IM to validate the agent in-memory. The IMM itself is part of an isolated secure partition in the platform such as a Service OS (VM).
• The Verification Registration Module (VRM) to provide hyper calls for (de)registration.
• The Memory Protection Module (MPM) to manage the page tables.

At a high level, the setup phase for self-defense of software agents proceeds as follows:

1. The guest OS loads the software agent into memory and starts executing it.
2. The agent (or 3rd party) registers with the VRM and requests memory protections. As a part of this registration request, the agent provides its IM to the VRM.
3. The VRM forwards the unauthenticated request along with the Manifest to the IMM. The IMM validates the signature of the manifest belongs to a trusted vendor or other source using a certificate authority signing hierarchy. Integrity of the manifest is then verified using this signature to ensure it was not modified.
4. The IMM uses highest privilege memory accesses to read the agent in the host physical memory, and it validates that the agent has not been altered, by comparing the agent's loaded image with the IM's description of that image [7].
5. If the IMM is able to validate that the agent is correctly loaded in memory, the VRM forwards the registration request to the memory protections module (MPM)
6. The MPM creates a Protected Page Table (PPT) for the agent code and data to protect the agent from run-time memory attacks. The MPM ensures this by removing the references to the agent's code and data from the APT used by the OS.

Once the setup described above is completed the MPM enforces various system policies such as preventing invalid jumps into the code and disallowing outside (non-agent code) read and/or write access into protected agent data. The MPM ensures that it can see all these events without risk of circumvention, due to the hardware virtualization capability of the processor. Specific events such as page faults cause transitions into the MPM that moderates these access attempts.

We have prototyped this architecture on an Intel VT-x based platform with Intel's lightweight VMM (LVMM) and used it to protect network drivers running in Windows XP* guest OSs.