Ilpo Järvinen:
> On Thu, 16 May 2019, g80vmgm...@riseup.net wrote:
>
>> From XSA297:
>> """
>> Work is ongoing on xen-devel to develop core-aware scheduling, which
>> will mitigate the cross-domain leak by ensuring that vcpus from
>> different domains are never concurrently scheduled on sibling threads.
>> However, this alone will not prevent cross-privilege level leakage from
>> within the same domain, including leakage from Xen.
>> """
>>
>> I'm sorry, I'm not subscribed to xen-devel and am too lazy to go through
>> its archives. Is anyone from the Qubes team monitoring this--or better,
>> participating in it?
>>
>> I can imagine a few Qubes-specific mitigations that might use some Xen
>> scheduling features to defend against future types of side-channel info
>> leaks in CPUs:
>>
>> 1) Schedule each domain in a given security label ('color') on a
>> specific CPU. If there are not enough CPUs, make clear to the user
>> which colors might be scheduled on the same physical CPU core.
>>
>> 2) Most (all?) CPUs that support Qubes have at least 2 cores. Assign
>> the first core the 'high' security label. Assign all other cores the
>> 'low' security label. Assign dom0, possible future AdminVM, and any
>> user-designated VMs the 'high' security label. Schedule high-labeled
>> VMs exclusively on high-labeled CPU cores, and never schedule a
>> low-labeled VM on a high-labeled CPU core.
>>
>> Information could still leak through e.g. shared caches, and special
>> attention obviously must be paid there, but this might be a useful
>> mitigation for similar kinds of attacks discovered in the future.
>>
>> It could be worthwhile to sketch out what kinds of features Qubes might
>> need from Xen in order to accomplish this kind of thing and work with
>> them while they develop this new scheduler.
>
> There is also some L3 cache region masking feature (CAT, which is also
> supported by Xen) onwards from Broadwell (but it might be only available
> for Xeons). And whether it could really close the L3 side-channels or
> not probably depends on internal L3 architecture (if an off-masked L3
> region contains the attacked data, whether it is retrieved by CPU or not).
>
>
Interesting. I have not heard of this feature before. I'll look into
it. Thanks!
I think it's also time to seriously consider deploying something like
TRESOR[1], especially in combination with 2) above. It must be
carefully designed so it doesn't leave the keys _more_ exposed to leaks,
though.
[1]: Tilo Mueller, Felix C. Freiling, Andreas Dewald. "TRESOR Runs
Encryption Securely Outside RAM".
https://www1.informatik.uni-erlangen.de/filepool/projects/tresor/tresor.pdf
--
You received this message because you are subscribed to the Google Groups
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/qubes-users/7a059aff-8806-5cc2-d963-a7342c029654%40riseup.net.
For more options, visit https://groups.google.com/d/optout.
