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...
rurban · 7h ago
And re-enables CVE-2019-0155?
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
jeroenhd · 6h ago
Based on the comments and the article, it seems like Intel is relying on a patched kernel so that the mitigations at the GPU driver stack are no longer necessary. You get security warnings if you try to run the unpatched GPU stack without a patched kernel.
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.
bayindirh · 3h ago
From what I read, the disabled mitigations are not even in the driver, but in the compute stack which drives the GPU. Since the mitigations are moved to kernel and driver levels, compute stack mitigations are redundant and too heavy handed.
So, they decided to remove this (IIUC third) level now.
Lindby · 6h ago
They mention that there are mitigations in the kernel nowadays, so the mitigations they turned off here are now redundant. But I'm uncertain if that refers to the same cve that you mention.
phoronixrly · 6h ago
> 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...
simoncion · 6h ago
> It's i915.mitigations
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.
CjHuber · 6h ago
Is it not a known fact that these mitigations cause a significant performance drop? I have never heard anyone assuming otherwise
bilekas · 5h ago
That's not debated and nobody mentioned that it's a 'surprise' there is a perf hit.
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.
gotoeleven · 2h ago
A question for people who are security experts: do you think the model of a computer having limited users and privileged users, with a user gaining privileged access being a massive security problem, is really tenable? The CPU/GPU are shared resources on a machine and isolating the work they do by user is quite difficult.
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.
ospray · 2h ago
Its more like we build computers that way to protect people from running code they shouldn't and limiting the blast radius if they do. A lot of the protections that pushed iOS zero click jailbreak exploit chains to the $10 million plus range impact capability and performance heavily. However you do have a good user experience that "just works" and keeps people safe. Run as sudo no pass if want man just for many that's to much risk.
mschuster91 · 2h ago
> The CPU/GPU are shared resources on a machine and isolating the work they do by user is quite difficult.
The problem is, users aren't even the threat boundary any more. Some classes of attacks like Rowhammer have been successfully exploited from Javascript.
Rakshith · 2h ago
how do we disable it?
washadjeffmad · 34m ago
depends on your boot configuration. if you use systemd-boot, use kernelstub -a "i915.mitigations=off". if you have /etc/default/grub, add it as a kernel parameter then update-grub.
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.
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.
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.