Disabling Intel Graphics Security Mitigation Boosts GPU Compute Performance 20%

https://www.phoronix.com/news/Disable-Intel-Gfx-Security-20p

by rcarmo • 1 year ago

84 18 1 year ago

rurban• 1 year 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

Lindby• 1 year 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.

simoncion• 1 year 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.

jeroenhd• 1 year 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.

phoronixrly2• 1 year 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...

bayindirh• 1 year 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.

CjHuber• 1 year ago

Is it not a known fact that these mitigations cause a significant performance drop? I have never heard anyone assuming otherwise

bilekas• 1 year 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.

phoronixrly2• 1 year ago

Source if you wish to skip the clickbait, blogspam and toxic comments: https://bugs.launchpad.net/ubuntu/+source/intel-compute-runt...

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

gotoeleven• 1 year 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.

mschuster91• 1 year 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.

ospray• 1 year 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.

lotharcable• 1 year ago

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.

ytpete• 1 year ago

I'm assuming what they are thinking along the lines of is not that we'd do away with the notion of privilege levels, but more that privilege boundaries would become 1:1 with hardware boundaries. So perhaps you'd have a dedicated CPU core with its own isolated cache for running the kernel, or that sort of thing. Almost like multiple separate systems communicating across client-server boundaries.

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.

Rakshith• 1 year ago

how do we disable it?

washadjeffmad• 1 year 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.

nodesocket• 1 year ago

Just set this on my MiniPC running Debian which runs Jellyfin.

    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

pabs3• 1 year ago

Wonder if it would be possible to enable them at runtime instead, based on whether the current Linux kernel boot has mitigated them or not.

Disabling Intel Graphics Security Mitigation Boosts GPU Compute Performance 20%

Related Stories