3 ms·

The final conclusion the speaker comes to in this talk is that you should disable de-duplication. It doesn't seem like there are any ways of mitigating it sugge

by cixin 10y ago

The final conclusion the speaker comes to in this talk is that you should disable de-duplication. It doesn't seem like there are any ways of mitigating it suggested. Essentially, the first method is a timing attack. If can tell if a crafted page is duplicated or not by the time it takes to modify the page. Modifying a defuplicated page will take longer, because a new copy has to be created. The only way I can see around this is to introduce random delays into all page writes, this might be feasible I guess, if you only needed to delay a small percentage of writes. However it's likely the performance penalty would be unacceptable.

ris 10y ago
I guess something that could help would be for the deduplicator to be slightly more conservative. When doing a deduplication pass, if it finds a duplicate page, rather than merging them straight off, mark one of the pages as "reclaimable", but only do that reclaim once the page is required for recycling. In the intervening time, the different users are still pointing at their private copies and no CoW has to take place if there is a modification (it is simply un-marked as a deduplication candidate). "Lazy" deduplication. Then the attacker would also have to force the system into enough memory pressure to be requesting to recycle these pages - something it may not be in the position to do if it is a guest with capped resources. The pages would also presumably be recycled in a less predictable order, making it harder to come up with simple a "wait 10 minutes" rule to ensure the recycling has taken place. Now, I'm sure what I've described would not be particularly simple to implement, but that's another thing.
- DannyBee 10y ago
  This also has performance implications since now you can't use the "reclaimable" memory for cache, etc.
  - ris 10y ago
    Well, I'd say if the need arises to use it for cache, reclaim it and perform the dedup.
DannyBee 10y ago
"Modifying a defuplicated page will take longer, because a new copy has to be created." Well, kinda. They only eventually have to be created. You don't have to create the new copy immediately, you could overlay new data on the old page (IE create new sparse page. Anything filled in on the new page is read from new page, anything else goes to backing dedupe'd page. real copy is made in background so this goes back to being fast) Of course, this mostly just makes it harder, assuming you can place enough memory pressure on the machine.
- Filligree 10y ago
  And how would you implement a "sparse page"? Without hardware support, the only idea I can think of is to mark the page unreadable and pass all memory reads through the kernel. Which would be readily detectable... among other problems.
  - DannyBee 10y ago
    Sure, you'd need hardware support. But, for example, hardware dedup is infeasible (IE you can make the compression go in hardware, but the management, not so much or sanely. Unless you can make both constant time, ...). Sparse pages are at least feasible in hardware. Also, you realize that passing all memory reads through the kernel is what any read barrier garbage collected language does, right?

by cixin 10y ago

ris 10y ago

I guess something that could help would be for the deduplicator to be slightly more conservative. When doing a deduplication pass, if it finds a duplicate page, rather than merging them straight off, mark one of the pages as "reclaimable", but only do that reclaim once the page is required for recycling. In the intervening time, the different users are still pointing at their private copies and no CoW has to take place if there is a modification (it is simply un-marked as a deduplication candidate). "Lazy" deduplication. Then the attacker would also have to force the system into enough memory pressure to be requesting to recycle these pages - something it may not be in the position to do if it is a guest with capped resources. The pages would also presumably be recycled in a less predictable order, making it harder to come up with simple a "wait 10 minutes" rule to ensure the recycling has taken place. Now, I'm sure what I've described would not be particularly simple to implement, but that's another thing.

DannyBee 10y ago
This also has performance implications since now you can't use the "reclaimable" memory for cache, etc.
- ris 10y ago
  Well, I'd say if the need arises to use it for cache, reclaim it and perform the dedup.

DannyBee 10y ago

"Modifying a defuplicated page will take longer, because a new copy has to be created." Well, kinda. They only eventually have to be created. You don't have to create the new copy immediately, you could overlay new data on the old page (IE create new sparse page. Anything filled in on the new page is read from new page, anything else goes to backing dedupe'd page. real copy is made in background so this goes back to being fast) Of course, this mostly just makes it harder, assuming you can place enough memory pressure on the machine.

Filligree 10y ago
And how would you implement a "sparse page"? Without hardware support, the only idea I can think of is to mark the page unreadable and pass all memory reads through the kernel. Which would be readily detectable... among other problems.
- DannyBee 10y ago
  Sure, you'd need hardware support. But, for example, hardware dedup is infeasible (IE you can make the compression go in hardware, but the management, not so much or sanely. Unless you can make both constant time, ...). Sparse pages are at least feasible in hardware. Also, you realize that passing all memory reads through the kernel is what any read barrier garbage collected language does, right?