Microarchitectural Security of AWS Firecracker VMM: Threat Models

Table of Links

• Abstract and Introduction
• Background
• Threat Models
• Analysis of Firecracker's Containment Systems
• Analysis of Microarchitectural Attack and Defenses in Firecracker Microvms
• Conclusion, Acknowledgments, and References

3. THREAT MODELS

We propose two threat models applicable to Firecracker-based serverless cloud systems:

(1) The user-to-user model (Figure 3): a malicious user runs arbitrary code sandboxed within a Firecracker VM and attempts to leak data, inject data, or otherwise gain information about or control over another user’s sandboxed application. In this model, we consider

(a) the time-sliced sharing of hardware, where the instances of the two users execute in turns on the CPU core, and

(b) physical co-location, where the two users’ code runs concurrently on hardware that is shared in one way or another (for example, two cores on the same CPU or two threads in the same core if SMT is enabled).

(2) The user-to-host model (Figure 4): a malicious user targets some component of the host system: the Firecracker VMM, KVM, or another part of the host system kernel. For this scenario, we only consider time-sliced sharing of hardware resources. This is because the host only executes code if the guest user’s VM exits, e. g. due to a page fault that has to be handled by the host kernel or VMM.

For both models, we assume that a malicious user is able to control the runtime environment of its application. In our models, malicious users do not posses guest kernel privileges. Therefore, both models grant the attacker slightly less privileges than the model assumed by [1] where the guest kernel is chosen and configured by the VMM but assumed to be compromised at runtime. Rather, the attacker’s capabilities in our models match the capabilities granted to users in deployments of Firecracker in AWS Lambda and Fargate.