I was thinking about splitting my 16 cores into 4 groups, 4 e-core for dom0 and 4 e-cores for sys qubes, 4 p-cores for browsers/email and 4 p-cores for my personal/work qubes.
I think this would allow me to maximize the advantage of the p cores, but would I need to make a libvirt/xen/by-name config for each vm to be able to assign the vcpus?
Does grouping the cores give me any extra protection against hardware attacks?
Does CPU pinning make it safe/safter to use smt?
My CPU has 8 e-cores that don’t support hyper-threading, and 8/16 p-core that support hyper-threading.
My current setup is that 4 e-core and dedicated to dom0, and the other 4 are dedicated to my sys qubes (net, firewall, usb, vpn, and whoinx)
I have enabled smt and split the 16 p-cores between my personal/work qubes and my disposable qubes, with 8 cores for each group.
My goal is to isolate each of the four groups, does CPU pinning allow me to do that to the point where it’s safe to enable smt?
Maybe I’m just too dumb to understand how MDS works, but isn’t it a requirement that both the target and attacker has a thread on the same core?
I use stm=on with sched-gran=core on top of this I have grouped my VMs to make sure different threat levels don’t share the same cores.
Is it correct that an attacker only would be able to use MDS to attack VMs that share the same cores?
I am not sure by reading this, for example
especially under “Mitigation”
MDS mitigation can be fully enabled, with SMT also disabled by adding the “mds=full,nosmt” flag to the kernel boot command line.
Exactly, but since we cannot fully prevent cross-thread attacks, leaving smt=on is more than dangerous as I see it, not to speak I can hardly see the point of “keeping attacks between VM’s on the same core” whichever the reason for their grouping is.
On the other hand, doesn’t this mean - all VM’s can be attacked, only with the number of attacks equaled to the number of cores?
Yet, I’m probably overlooking something,.
My main goal is just to be sure that my disposable browsers qubes can’t be used to bridge into my user qubes or dom0. I couldn’t care less if one or all of the disposable qubes get hacked, I always assume they are hacked anyway.
You mean bridged by MDS attacks? But there are side-channel attacks against which this doesn’t help? On the contrary, as I’m trying to comprehend?
The main attacks you mitigate by disabling smt is as fare as I know Zombieload and Foreshadow, but they are hardly relevant anymore, but who know what the future brings. Turning off smt doesn’t prevent the other transient attacks.
My logic is that if I take 8 core and only use them to run my disposable qubes, whatever happens on the 8 cores stays on the 8 cores, and can’t spread to the rest of the system. I don’t know if this is true, but I have not been able to find any information that the HT/SMT attacks work outside the core they are running one.
can’t spread by MDS attacks, but can by
And my dilemma is: is the one who is able to misuse MDS attacks, able to misuse “other transient attacks” too?
Because when yes, then I see no point in widening attack surface by leaving smt on.
But I understand your logic.
As I understand it, you can use MDS on Intel Core gen 6 to 8 and Xeon v5 and 6 it’s the same with L1TF, but MDS can only read memory and L1TF is notoriously hard to execute.
I think it’s unlikely that someone would be able to use any of the know SMT exploits as the initial attack vector, the attacker would need to already have compromised a VM to use them. And if the attacker already has compromised a VM, they can use other transient attacks.
Besides, I’m using an Intel Core gen 12 as fare as I know there are no known SMT exploits for this CPU. There could be unkown/non-public exploits, but I don’t have a threat-model that involve someone deploying a million dollar zero-day CPU exploits just to hack my desktop PC.
I get why SMT is turned off by default, but it would be nice if there was a bit of information for the people who want to turn on SMT.