Linux has flags that allow disabling mitigations to get performance back. MacOS and Windows probably have the same. Pretty much the only thing that is running unauthenticated workloads on my dev machine are my browser and mail client. Is there a way to disable the mitigation’s globally but enable them per process? I don’t mind much getting a 10-30% performance hit on browsing, but I do mind when compiling/testing things.
I'm going to say no, or at least, not easily. Some of the mitigations like reptolines involve changing how the host kernel is compiled, and you can obviously only do that once per machine. Separate kernel/user page tables is one where there's a big overhead and it seems as if it could be possible to do this per-process (ie. have some processes which do the "old way" and share the kernel page table, while your hardened browser would use the slower separate page tables). But the devil will be in the details and I'm no Andrea Archangeli.
In my experience the biggest problem is something that cannot be solved by the kernel anyway, which is the microcode updates. AFAIK it's impossible to get that performance back by any means, even the mitigations=off flag cannot do that.
Maybe look at QubesOS (it runs many desktop processes in separate virtual machines) which will give you defence in depth, and mitigates many other browser attacks as well as architectural ones. You could run your trusted stuff outside Qubes (in the dom0) where it I guess ought to run at full speed.
BTW I solve this problem by having a separate development machine for compiling and testing my own code which never runs anything untrusted. And that other machine is an AMD Zen 2 so it's not quite so vulnerable and also much faster for the price!
In my experience the biggest problem is something that cannot be solved by the kernel anyway, which is the microcode updates. AFAIK it's impossible to get that performance back by any means, even the mitigations=off flag cannot do that.
It is my understanding that these microcode updates get applied either by the operating system at boot time (applying the update every time you boot), or by the motherboard, if the BIOS was updated. As only this last method is "permanent" (or at least it requires you to downgrade your BIOS, something not always feasible) if you never upgraded your BIOS, I guess it should be possible to prevent the OS from applying the updates.
From my understanding, the microcode is the firmware of the CPU.
It's usually upgraded by a BIOS update or by Windows update. Windows update send driver/firmware updates, security patches or general updates if the vendor wants to support that way of distribution.
I think it's quite device specific and method specific whether the microcode can be upgraded and downgraded the same way.
The other poster is correct... microcode can be upgraded by BIOS update or Windows update, but the update doesn't persist on the CPU itself after a reboot (it has to be reapplied every boot, by either BIOS or Windows)
I’d happily reboot (though preferably not use a separate image entirely, nor a separate machine) to a get 5-10% speed increase when gaming.
If I can’t do that and I have to choose between fast/insecure or slow/secure I’ll take my chances with fast/insecure. I’ll rather give up doing anything sensitive on my machine than give up 5% perf.
This is a good idea that opens you up to the attack.
If browser running in 'safe mitigated mode' was compromised then it itself could try to disable the mitigation that was on for it.
The original Spectre paper[0] describes an attack on KVM where software with guest ring 0 access can read host memory. I'm not sure if it's possible without guest ring 0 access.
Comments
Linux has flags that allow disabling mitigations to get performance back. MacOS and Windows probably have the same. Pretty much the only thing that is running unauthenticated workloads on my dev machine are my browser and mail client. Is there a way to disable the mitigation’s globally but enable them per process? I don’t mind much getting a 10-30% performance hit on browsing, but I do mind when compiling/testing things.
I'm going to say no, or at least, not easily. Some of the mitigations like reptolines involve changing how the host kernel is compiled, and you can obviously only do that once per machine. Separate kernel/user page tables is one where there's a big overhead and it seems as if it could be possible to do this per-process (ie. have some processes which do the "old way" and share the kernel page table, while your hardened browser would use the slower separate page tables). But the devil will be in the details and I'm no Andrea Archangeli.
In my experience the biggest problem is something that cannot be solved by the kernel anyway, which is the microcode updates. AFAIK it's impossible to get that performance back by any means, even the mitigations=off flag cannot do that.
Maybe look at QubesOS (it runs many desktop processes in separate virtual machines) which will give you defence in depth, and mitigates many other browser attacks as well as architectural ones. You could run your trusted stuff outside Qubes (in the dom0) where it I guess ought to run at full speed.
BTW I solve this problem by having a separate development machine for compiling and testing my own code which never runs anything untrusted. And that other machine is an AMD Zen 2 so it's not quite so vulnerable and also much faster for the price!
It is my understanding that these microcode updates get applied either by the operating system at boot time (applying the update every time you boot), or by the motherboard, if the BIOS was updated. As only this last method is "permanent" (or at least it requires you to downgrade your BIOS, something not always feasible) if you never upgraded your BIOS, I guess it should be possible to prevent the OS from applying the updates.
From my understanding, the microcode is the firmware of the CPU.
It's usually upgraded by a BIOS update or by Windows update. Windows update send driver/firmware updates, security patches or general updates if the vendor wants to support that way of distribution.
I think it's quite device specific and method specific whether the microcode can be upgraded and downgraded the same way.
The other poster is correct... microcode can be upgraded by BIOS update or Windows update, but the update doesn't persist on the CPU itself after a reboot (it has to be reapplied every boot, by either BIOS or Windows)
I’d happily reboot (though preferably not use a separate image entirely, nor a separate machine) to a get 5-10% speed increase when gaming.
If I can’t do that and I have to choose between fast/insecure or slow/secure I’ll take my chances with fast/insecure. I’ll rather give up doing anything sensitive on my machine than give up 5% perf.
This is a good idea that opens you up to the attack. If browser running in 'safe mitigated mode' was compromised then it itself could try to disable the mitigation that was on for it.
They're also pointless when running number-cruching instances in the cloud.
I thought a big problem with these side-channel leaks was that other tenants on the same cloud instance could view your data.
When you're number crunching you usually borrow a full machine ("exclusive VM").
Run a browser in a VM with a hardened kernel?
Or can a properly designed attack break out of the VM and hardened kernel?
The original Spectre paper[0] describes an attack on KVM where software with guest ring 0 access can read host memory. I'm not sure if it's possible without guest ring 0 access.
https://spectreattack.com/spectre.pdf