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.

> 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.

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.

> 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...

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.

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.

> 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.

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.

Not a security expert here...

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.

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.

    sudo nano /etc/default/grub

    GRUB_CMDLINE_LINUX_DEFAULT="quiet i915.mitigations=off"

    sudo update-grub
    sudo reboot

    cat /proc/cmdline