VM CPU mapping - countermeasurements against covert channels via cpu caches?

[1'09348'109438'0194328'0194328'0914328'091432]

Hello,

How I can define, that VM1 is running exclusively the CPU1..4?

(and so all other VM's will run on CPU core 5..8)

This would prevent the data leaks due to covert channels via cpu caches.

https://www.qubes-os.org/doc/data-leaks/

Kind Regards

[Andrew]

1'09348'109438'0194328'0194328'0914328'091432:

> This would prevent the data leaks due to covert channels via cpu caches.

I doubt it. Usually all cores share the same LLC, at least.

Andrew

[1093284'109438'019438'0914328'0913284'0913]

Hi Andrew,

could it be that with some real-time OS features, it will possible to splitt the Cores of an CPU in two clean domains?

This would lead to a better latency performance for real time communication, like skype and for some "air-gapped engines" inside Q.

Kind Regards

[Andrew]

1093284'109438'019438'0914328'0913284'0913:

I'm confused what you're trying to achieve: static scheduling of some
VMs on some cores, or the elimination of caches as potential inter-VM
covert channels. Can you explain exactly what your goal is?

I have an idea: go read up on the relevant literature (which I am sure
exists in substantial volume), reformulate your goal if necessary, and
tell us what you learn.

Andrew

[1087340917834091784309178094378]

Hallo Andrew,

real crypto works always with air-gapped machines.

PC0 handels all encryptions (PC0 is sheltered)
PC1 is the achive

The charme of this solution is, that the risk of bit-leaks, of the crypto keys can mitigated.

In qubes I could use a dual CPU system.

CPU0 handels all encryptions in all CyptoVMs (PC is sheltered)
CPU1 is the power-support for all other VMs

How I can make sure that all CyptoVMs are powered by the cores of the CPU0 and all others by the CPU1?

Kind Regards

P.S. Optional would be the (external) "crypto-chip" solution, like a FPGA board.

[1039841094380918430'91843'09]

Assume my PC has to CPUs.

How I can configure Qubes that all black VMs are running under CPU0 and all other VMs are running under CPU1?

That would be cool!

Kind Regards

[12384013418489'14'810'4]

Hello,

would be the Intel Skylake Technology SGX a solution, so that the keys cannot be read from the crypto processes?

https://github.com/01org/linux-sgx

Kind Regards

[Ilpo Järvinen]

On Tue, 28 Jun 2016, 12384013418489'14'810'4 wrote:

> would be the Intel Skylake Technology SGX a solution, so that the keys
> cannot be read from the crypto processes?

In these covert attacks, the keys are not "read" but leaked. Those leaks
are unlikely to be solved by SGX as it's not the threat it is used to
counter (i.e., SGX prevents reading of those DRM keys directly from
RAM in plain text form :-)). With SGX, the memory is encrypted so that
it cannot be "read", however, the CPU still does calculations of an SGX
enclave the same way as without them which creates the opportunity for
the very same covert channels to form.

Other interesting technology in this domain is ability to somehow control
cache allocations that is available at least with Broadwell Xeons.
However, I'm not convinced it can fully remove cache-based covert
channels either.


--
i.

[091384'019438'0913284'0918324'09]

Hello Ilpo Järvinen,

would be it an option, if some "secure CPU" is just encrypt the caches before it handles over the CPU power to other processes?

Perhaps in the some near future?

Kind Regards

[Andrew]

091384'019438'0913284'0918324'09:

Please, go read the literature on cache-based side-channel attacks and
all the proposed countermeasures.

Isolating VMs to different cores which still share the same last level
cache, or encrypting the data in the cache (though it's unclear what you
mean by "encrypt[ing] the cache") are not sufficient to prevent leaking
secret data.

Here's a classic example why:
https://dl.packetstormsecurity.net/papers/general/flush-reload.pdf.

Andrew

[1'093480'19438'019438'091843'098]

Hello Andrew,

the idea is, if crypt-methods may help...

E.g. can holomorphic encryption be used to do all the crypt-key calculation on encrypted data (instead of the plain-text of the key) - so "nobody" can leak key-bis, also if N VMs work in parallel?

Kind Regards