I also propose the title here be changed to 'Security mitigations in intel-compute-runtime no longer needed, disabling brings 20% boost' because as it currently is it misleads that Canonical is reopening the Spectre vulnerability in the GPU for performance's sake. It's not. While there, I'd say update the link to point to the source.
Relevant quote:
> After discussion between Intel and Canonical’s security teams, we are in agreement that Spectre no longer needs to be mitigated for the GPU at the Compute Runtime level. At this point, Spectre has been mitigated in the kernel...
Intel researchers discovered that Intel graphics processors allowed userspace to modify page table entries via writes to MMIO from the Blitter Command Streamer and exposed kernel memory information, resulting in possible privilege escalation and information disclosure vulnerabilities. A local user could use this issue to escalate their privileges on the local machine.
It's i915.mitigations
If my interpretation is correct, that means as long as you're using an up-to-date, patched kernel with standard mitigations enabled, the extra security layer Intel added is no longer necessary. It could expose another bug not yet covered by patches, though, as the heavy-handed patch probably also prevented more security issues.
So, they decided to remove this (IIUC third) level now.
Since you're doing the research, you tell us. Is NEO_DISABLE_MITIGATIONS (the flag mentioned in TFA) related to i915.mitigations, and if so, how?
TFA mentions that Intel ships prebuilt driver packages with this NEO_... flag set, and that Canonical and Intel programmers talked at some length about the flag.
Would it really be infeasible to simply design compute systems under the assumption that all users can get root access? Most of these vulnerabilities can be mitigated for free by not giving any access to users you wouldn't mind having root access.
The problem is, users aren't even the threat boundary any more. Some classes of attacks like Rowhammer have been successfully exploited from Javascript.
But Discretionary Access Controls is a standard part of OS design for a very long time.
It is certainly possible to go back to DOS-days and run all your programs without controls as terminate and stay resident programs. But that would be awfully inconvenient.
The concept of "users" isn't just for human users. It is used to do things like prevent your web server from being able to read and edit your password files and such things.
I guess the question for me though (as neither a deep expert in security nor low-level hw) is, how much less efficient would that be than the kinds of mitigations used today for shared hardware? If it's far more guaranteed-safe and the cost is only just a bit higher than today's mitigations... that would be interesting indeed.
The topic is related to now being the time to disable it as there seems to be no need for it anymore due to a kernel patch, as well as Intel themselves publishing upstream without these.
> Intel themselves have enabled this flag in their builds available on their Github release page upstream."
> At this point, Spectre has been mitigated in the kernel, and a clear warning from the Compute Runtime build serves as a notification for those running modified kernels without those patches.
sudo nano /etc/default/grub
Look for GRUB_CMDLINE_LINUX_DEFAULT and add: i915.mitigations=off GRUB_CMDLINE_LINUX_DEFAULT="quiet i915.mitigations=off"
Then: sudo update-grub
sudo reboot
To verify: cat /proc/cmdline