CPU cache-based communication between two co-located virtual machines

Re:CPU cache-based communication between two co-located virt... by brendangregg on Thursday March 30, 2017 @12:08PM (#13996595)

I noticed the paper tested an Xeon E5-2670 on EC2, which is old (Sandy Bridge; eg, m2's) and pre-dates Intel Cache Allocation Technology (IntelCAT):

https://software.intel.com/en-us/articles/introduction-to-ca...

Support for IntelCAT was added to Xen two years ago. Eg:

    [root@vmm-psr vmm]# xl psr-hwinfo --cat
    Cache Allocation Technology (CAT):
    Socket ID       : 0
    L3 Cache        : 12288KB
    Maximum COS     : 15
    CBM length      : 12
    Default CBM     : 0xfff

And to Linux 4.10 a couple of months ago: https://lwn.net/Articles/694800/

While I suspect IntelCAT could disable this side channel, I'd personally hesitate before turning it on for everyone on the cloud. Does it out weigh the performance cost? ... Can customers opt-in to this?

[ Parent | on HN ]

Re:CPU cache-based communication between two co-located virt... by j_s on Thursday March 30, 2017 @01:41PM (#13997355)

Yes it was specifically called out in someone's tweet I'm trying to find but I believe this was mentioned in the paper.

Edit: My mix-up on the paper!

Malware Guard Extension: Using SGX to Conceal Cache Attacks (Extended Version) | https://arxiv.org/pdf/1702.08719.pdf (2017)

Recently, Intel introduced an instruction set extension called CAT (cache allocation technology) [51]. With Intel CAT it is possible to restrict CPU cores to one of the slices of the last-level cache and even to pin cache lines. Liu et al. [83] proposed a system that uses CAT to protect general purpose software and cryptographic algorithms. Their approach can be directly applied to protect against a malicious enclave. However, this approach also does not allow to protect enclaves from an outside attacker.

[...]

Instead of using Intel CAT on the operating level it could also be used to protect enclaves on the hardware level. By changing the eenter instruction in a way that it implicitly activates CAT for this core, any cache sharing between SGX enclaves and the outside as well as co-located enclaves could be eliminated. Thus, SGX enclaves would be protected from outside attackers. Furthermore, it would protect co-located enclaves as well as the operating system and user programs against malicious enclaves.

[83] https://www.researchgate.net/profile/Yuval_Yarom/publication...

[ Parent | on HN ]

Re:CPU cache-based communication between two co-located virt... by brendangregg on Thursday March 30, 2017 @01:51PM (#13997433)

this paper? https://cmaurice.fr/pdf/ndss17_maurice.pdf where is IntelCAT mentioned?

[ Parent | on HN ]

Re:CPU cache-based communication between two co-located virt... by redrabbyte on Thursday March 30, 2017 @12:40PM (#13996885)

If there are no more shared cache sets between VMs, then yes, it's dead ofc

I would suspect if one VM would like to be separated from the others in terms of cache sets, the others really don't have the choice to opt out?

[ Parent | on HN ]

Re:CPU cache-based communication between two co-located virt... by brendangregg on Thursday March 30, 2017 @02:16PM (#13997625)

good point...

[ Parent | on HN ]