There are lots of duplicate contents when you look at memory pages in a running system. For example, in cloud hosts, many virtual machines (VMs) are running the same software stack or many apps may statically link similar libraries in your mobile phone.
We hence can save a whole lot of memory if we could eliminate this duplication and this is where memory deduplication comes into play. Memory deduplication periodically scans memory pages and keeps one read-only copy by merging many duplicate pages. When a party (e.g., a VM) wants to write to a shared copy, a copy-on-write event makes sure that correct semantics are preserved by creating a private copy for the writing party.
This works relatively well and people have reported that they could save a lot of memory using memory deduplication. But there are security concerns…
Attacks on Memory Deduplication
In our previous work, we showed that it is possible to abuse memory deduplication to leak high-entropy information using a side channel. This attack relied on the slow writes to figure out whether a page exists in the system. We further showed that it is possible to abuse the predictability of the merge operation for performing deterministic cross-VM Rowhammer attacks.
In this work, we show that the attack surface of memory deduplication is much larger: it is possible to leak the existence of another page in the system by only reading from memory. Further, it is possible to abuse the predictability of memory reuse even when the merge operation itself is not predictable for Rowhammer attacks, as is the case in some implementations (e.g., Windows).
We use these findings to build a secure memory deduplication system which we call VUsion.
VUsion’s Secure Design
To address the side-channel attacks, we have to make sure that all pages that are shared should behave the same as the pages that are not shared. To enforce this, we remove all access permissions from all the pages that are considered for deduplication. As soon as they are accessed, we will always duplicate a copy regardless of whether the page was merged (i.e., copy-on-access).
This is secure because the attacker can no longer tell whether the page was originally shared (more details in the paper), but it sounds very expensive, both in terms of performance and deduplication rates. You would expect that performance will be horrible because of copy-on-access on any page regardless of whether they are shared. You would also expect that deduplication rate will be horrible as well, because any access would cause a shared page to reduplicate.
Fortunately, one key insight allows VUsion to operate with both good performance and high deduplication rate! We noticed that most of deduplication benefits come from idle pages in the system. Hence, with a simple working set estimation, we can reduce the performance overhead but preserve deduplication on idle pages. Furthermore, the deduplication process is a slow background process which means that the cost of the extra page faults due to copy-on-access will be amortized over a long period of time.
The diagrams below compare deduplicated (or fused) pages in KSM, the original implementation of memory deduplication in the Linux kernel, and VUsion.
To address the Rowhammer attacks, we rely on a high-entropy pool for allocating physical pages. Using this pool, the attackers cannot rely on predictable behavior in the memory deduplication system for reliable Rowhammer attacks.
VUsion is implemented on top of the Linux kernel 4.10.0-rc6. We make heavy use of various kernel subsystems such as the original KSM, khugepaged and idle page tracking.
We measured that accessing pages always takes the same amount of time regarding their merge status and the allocations are always random, protecting memory deduplication against side-channel and Rowhammer attacks. There are lots of results about security, performance and deduplication rates in our paper. But here are some teasers:
VUsion only introduces 2.7% of performance overhead on top of KSM in the SPEC 2006 benchmark suite as the following figure shows.
VUsion only degrades the deduplication rate by 1% when we started 16 VMs started from different Linux images (including CentOS, debian, etc.) as the following figure shows.
VUsion is available as open-source software: https://github.com/vusec/vusion
Frequently Asked Question
- How can I check whether memory deduplication is enabled in my cloud?
You need to check the support for memory deduplication in your virtualization platform (e.g., KVM, Xen, etc.). Different people call memory deduplication differently: Linux/KVM calls it same-page merging, Windows calls it memory combining, VMWare calls it transparent page merging, and Virtual Box calls it page fusion.
- I checked and memory deduplication is enabled in my cloud. Are my VMs secure against attacks on memory deduplication?
Probably not. As far as we know, none of the virtualization platforms implement techniques for protecting against side-channel and Rowhammer attacks like VUsion does. You can apply our patch to secure memory deduplication if you run Linux/KVM.
- I am a “client” of a cloud provider. How can I check whether memory deduplication is enabled?
You cannot easily check if your cloud provider does not tell you (or lies about it). You can try one of the side channels on your own memory pages to check this as we have described in our paper. Try this on your own risk though.
- Fake Merging and Share XOR Fetch sound prohibitively expensive, but you show that they are indeed practical. How come?
Because most of the deduplicated pages are actually idle like page cache. Do note that it is generally not easy to measure the overhead of advanced memory management features on all corner cases. We did however tried our best to measure VUsion’s overhead on all scenarios we could think of and generally observed low overhead.
- What about Transparent Huge Pages?
VUsion is fully compatible with Transparent Huge Pages while preserving security. Please find more information about it in our paper.
- Why the name VUsion?
Page fusion is another name for memory deduplication. Vusion is pronounced similar to fusion in Dutch and VU is the abbreviation of our university’s name, hence VUsion.
This work was supported by the European Commission through project H2020 ICT-32-2014 “SHARCS” under Grant Agreement No. 644571 and by the Netherlands Organisation for Scientific Research through grant NWO 639.023.309 VICI “Dowsing”. The public artifacts reflect only the authors’ view. The funding agencies are not responsible for any use that may be made of the information they contain.