Opt Green: KDE Eco's New Sustainable Software Project

Posted Jun 3, 2024 16:01 UTC (Mon) by pizza (subscriber, #46)
In reply to: Opt Green: KDE Eco's New Sustainable Software Project by cesarb
Parent article: Opt Green: KDE Eco's New Sustainable Software Project

> With rare exceptions, these vulnerabilities usually need superuser access (or even physical access) to be exploited. To get there, the attacker has to first get past the web browser and the operating system.

Once upon a time, you were correct. However in more recent times, many of these data-leakage exploits require no elevated privileges, and real-world attacks have been demonstrated using nothing but javascript running in a web browser.

Opt Green: KDE Eco's New Sustainable Software Project

Posted Jun 4, 2024 13:08 UTC (Tue) by cesarb (subscriber, #6266) [Link] (6 responses)

> However in more recent times, many of these data-leakage exploits require no elevated privileges, and real-world attacks have been demonstrated using nothing but javascript running in a web browser.

Yes, Spectre is one of the "rare exceptions" I was thinking of (vulnerabilities in out-of-band management systems like Intel AMT is the other, since they allow remote access which completely bypasses the operating system, and it's hard to even know whether they are enabled or not).

But Spectre (and similar) is limited; it cannot do much more than leaking in-memory data. It cannot modify data, it cannot leak "cold" data which is only on disk, and mitigations in web browsers and operating systems can reduce some of its impact (at a performance cost) even without help from the CPU microcode or platform firmware.

Opt Green: KDE Eco's New Sustainable Software Project

Posted Jun 4, 2024 13:36 UTC (Tue) by pizza (subscriber, #46) [Link] (5 responses)

> But Spectre (and similar) is limited; it cannot do much more than leaking in-memory data.

When that "in-memory data" includes crypto and session keys, authentication credentials to external third party-run services, leaking said "in-memory data" can give an attacker the literal keys to your non-local kingdom.

> mitigations in web browsers and operating systems can reduce some of its impact (at a performance cost) even without help from the CPU microcode or platform firmware.

There's very little the browser can do given that the information being leaked isn't restricted to processes controlled by the browser. Heck, some of these attacks can leak information across *virtual machines*.

Even at the OS level, these "mitigations" generally consist of completely disabling hardware features, usually with _severe_ performance impacts. If said features can even be disabled at all.

Whereas with these microcode patches, the OS has the option of using considerably higher-performance mitigations, if anything is needed at all.

Opt Green: KDE Eco's New Sustainable Software Project

Posted Jun 4, 2024 14:09 UTC (Tue) by pizza (subscriber, #46) [Link] (3 responses)

> Even at the OS level, these "mitigations" generally consist of completely disabling hardware features, usually with _severe_ performance impacts. If said features can even be disabled at all.
> Whereas with these microcode patches, the OS has the option of using considerably higher-performance mitigations, if anything is needed at all.

Just wanted to follow up on this -- If you have to disable SMT to mitigate against a vulnerability, that's going to result in about a 33% performance impact, meaning you'll need roughly 50% more resources [1] to achieve the same overall performance. 50% more servers, 50% more datacenter space, 50% more power (and cooling), etc.

Or you can use a combination of microcode patches (possibly in combination with OS awareness) to bring the net performance hit to ~5%. It's a win-win for everyone. [2]

[1] Assuming SMT gives you a 50% performance boost on average, losing it means your net performance will be approximately 2/3rds of what it was with SMT. (SMT gains are highly workload dependent)
[2] If you run truly private/trusted workloads, you're going to disable all of these mitigations as part of your performance tuning anyway.

Opt Green: KDE Eco's New Sustainable Software Project

Posted Jun 4, 2024 14:18 UTC (Tue) by adobriyan (subscriber, #30858) [Link]

> [1] Assuming SMT gives you a 50% performance boost on average, losing it means your net performance will be approximately 2/3rds of what it was with SMT. (SMT gains are highly workload dependent)

Kernel compile is only ~10% faster with HT.

Opt Green: KDE Eco's New Sustainable Software Project

Posted Jun 4, 2024 15:16 UTC (Tue) by farnz (subscriber, #17727) [Link]

A 50% performance boost for SMT would be very surprising on a well-designed core. 5% to 20% is a more normal range for an Out of Order Execution (OoOE) design, since a good OoOE design is set up so that one thread can utilize all of the resources available, and your workload will tend towards bottlenecking on the same resource for all threads (with SMT's performance boost coming from the fact that you hit the bottleneck at different points on different hardware threads).

Opt Green: KDE Eco's New Sustainable Software Project

Posted Jun 4, 2024 19:35 UTC (Tue) by cesarb (subscriber, #6266) [Link]

> Just wanted to follow up on this -- If you have to disable SMT to mitigate against a vulnerability, that's going to result in about a 33% performance impact, meaning you'll need roughly 50% more resources [1] to achieve the same overall performance. 50% more servers, 50% more datacenter space, 50% more power (and cooling), etc.

Most servers aren't running untrusted code, and so far I have heard of no demonstration of speculative execution vulnerabilities being exploited solely through a network connection. The impact on web browsers (which do run untrusted code) is lower, since client computers are idle most of the time and thus have resources to spare; there might be an impact on power use, but there's a difference between "the battery lasts less time" and "hopelessly insecure".

Opt Green: KDE Eco's New Sustainable Software Project

Posted Jun 4, 2024 19:49 UTC (Tue) by cesarb (subscriber, #6266) [Link]

> There's very little the browser can do given that the information being leaked isn't restricted to processes controlled by the browser. Heck, some of these attacks can leak information across *virtual machines*.

The browser is not alone, it works in concert with the kernel, and there are lots of tricks the kernel can use to mitigate these vulnerabilities (both between userspace and the kernel, and between the sandboxed JS process and the other browser processes) even without firmware help.

> Even at the OS level, these "mitigations" generally consist of completely disabling hardware features, usually with _severe_ performance impacts. If said features can even be disabled at all.

The main "completely disabling hardware features" mitigation is disabling SMT. Other than that, most non-microcode mitigations are AFAIK code to block speculation (or make it harmless) at key points, which does have some performance impact, but not severe enough to make the hardware unusable. If you can accept some performance degradation, you can have good enough security even after the hardware maker stopped support for that hardware.