5 ms·

This absolutely vindicates Xen's approach vs Linux's. Performance gained by speculative execution sadly must be given up for safety as a default, to only be re-

This absolutely vindicates Xen's approach vs Linux's. Performance gained by speculative execution sadly must be given up for safety as a default, to only be re-gained in specific cases where safety is certain. It also vindicates the naming of "Spectre", it most definitely keeps showing up. The article reads a bit too much like "I told you so", but ultimately the author is correct to say it.

plam503711 4y ago
The real golden-"I told you so" (that triggered the idea to write this very blog post) comes from a tweet of David Woodhouse last July: https://twitter.com/dwmw2/status/1549042968320811008 https://twitter.com/dwmw2/status/1549042968320811008
- eru 4y ago
  Direct link: https://lkml.org/lkml/2018/1/22/598 https://lkml.org/lkml/2018/1/22/598
- dwmw2 4y ago
  Hah, I wondered why there was an uptick of attention to that old tweet. We should be slightly careful — while I can't deny that there's a small element of "ITYS" about that tweet, should it really count if I then left it up to Intel to follow up? I whined that we hadn't shown that it was safe. The credit really does need to go to the RETbleed folks who put in the work to truly demonstrate that it wasn't.
deleted 4y ago
[deleted]
ajross 4y ago
> This absolutely vindicates Xen's approach vs Linux's Meh. It likely just points out that Xen is a much more limited software environment with much less dependence on indirect branching[1]. There are environments where IBRS has high cost and ones where it doesn't. Linux is in the former category. Xen also has the advantage of being a hypervisor, meaning that if all they do is expose IBRS to the guest, they can (somewhat cleverly) claim that any resulting vulnerabilities are the fault of the guest software not implementing them. Linux exposes a Unix userspace, and no one told userspace apps they need to use speculation barriers. Really this article is mostly just marketing. It's a win for Xen, sure, and they should crow about it. But we should recognize crowing vs. genuine security analysis, too. [1] Vs. say, Linux, which has an extremely robust polymorphic device/bus/probe model where all the methods are function pointers.
- gizmo686 4y ago
  It is easy to be fast if you are willing to ship broken software. The Linux solution was broken. People knew the Linux solution was broken when it was shipped. The Linux developers knew what a non broken solution would be because the CPU manufacturer told them. [0] Linux decided to go with the broken solution. This attitude is not specific to Linux, it is pervasive throughout the entire industry. It is the reason that few people take a security volnerability report seriously until someone turns it into a full exploit. Frankly, Xen's work here was not at all impressive; they just applied a fix that Intel told everone to apply. The fact that this is a differentiating thing for them to market with is an indictment of everyone who didn't apply it, and the industry conditions that led to them. [0] In fairness, the reason we are in this mesz is that said CPU manufacturer has been releasing broken products in the name of speed themselves.
  - ajross 4y ago
    > The Linux solution was broken. People knew the Linux solution was broken when it was shipped. That is not a fair characterization. There are endless mountains of theoretical vulnerabilities[1], and no one (certainly not including Xen) tries to mitigate them all blindly. The dwm post linked in the article explicitly says he's not losing sleep over the issue. Everyone (yes, likely including Xen) believed in good faith that this was not practically exploitable. > Frankly, Xen's work here was not at all impressive; they just applied a fix that Intel told everone to apply. And this seems like a misunderstanding too. My gathering from the linked article is that Xen virtualized the barrier mechanism such that the job could be farmed out to guest OSes. Someone running an unpatched Linux under Xen (which is, what, 90+% of the worldwide cloud?) is still vulnerable. But "Xen" is not, which seems maybe less impactful than the marketing being presented would have you believe. [1] Rowhammer says hi.
    - bonzini 4y ago
      > Xen virtualized the barrier mechanism such that the job could be farmed out to guest OSes. All hypervisors do that, including KVM. The difference is that because Xen has to let the guest control the speculation control MSRs, it has to read and write the MSR anyway on every guest<->host context switch. Using IBRS in Xen comes essentially for free. Linux on the other hand does not have to access the speculation control MSR on every userspace<->kernel context switch, and doing so would have had a bigger performance impact than retpolines. Therefore it took a different approach. Now the performance impact wasn't that bad on Skylake and it probably would have been good to use IBRS on those processors. FWIW very old versions of RHEL (6 and 7) in fact did use IBRS instead of retpoline because we had little time (there were less than two months from the time the team was put together to the time we had to have something ready to be shipped to customers) and it even took days to read people on the issue because of how secret it was. So we didn't want to put the compiler update on the critical path.
jscipione 4y ago
I understand why in a data center hosting VMs speculative execution would be impractical, yet on my personal computer speculative execution gives a nice performance boost copying small files.
- dontlaugh 4y ago
  Your computer also runs attacker controlled code, especially in browsers.

plam503711 4y ago

The real golden-"I told you so" (that triggered the idea to write this very blog post) comes from a tweet of David Woodhouse last July: https://twitter.com/dwmw2/status/1549042968320811008 https://twitter.com/dwmw2/status/1549042968320811008

eru 4y ago
Direct link: https://lkml.org/lkml/2018/1/22/598 https://lkml.org/lkml/2018/1/22/598
dwmw2 4y ago
Hah, I wondered why there was an uptick of attention to that old tweet. We should be slightly careful — while I can't deny that there's a small element of "ITYS" about that tweet, should it really count if I then left it up to Intel to follow up? I whined that we hadn't shown that it was safe. The credit really does need to go to the RETbleed folks who put in the work to truly demonstrate that it wasn't.

deleted 4y ago

[deleted]

ajross 4y ago

> This absolutely vindicates Xen's approach vs Linux's Meh. It likely just points out that Xen is a much more limited software environment with much less dependence on indirect branching[1]. There are environments where IBRS has high cost and ones where it doesn't. Linux is in the former category. Xen also has the advantage of being a hypervisor, meaning that if all they do is expose IBRS to the guest, they can (somewhat cleverly) claim that any resulting vulnerabilities are the fault of the guest software not implementing them. Linux exposes a Unix userspace, and no one told userspace apps they need to use speculation barriers. Really this article is mostly just marketing. It's a win for Xen, sure, and they should crow about it. But we should recognize crowing vs. genuine security analysis, too. [1] Vs. say, Linux, which has an extremely robust polymorphic device/bus/probe model where all the methods are function pointers.

gizmo686 4y ago
It is easy to be fast if you are willing to ship broken software. The Linux solution was broken. People knew the Linux solution was broken when it was shipped. The Linux developers knew what a non broken solution would be because the CPU manufacturer told them. [0] Linux decided to go with the broken solution. This attitude is not specific to Linux, it is pervasive throughout the entire industry. It is the reason that few people take a security volnerability report seriously until someone turns it into a full exploit. Frankly, Xen's work here was not at all impressive; they just applied a fix that Intel told everone to apply. The fact that this is a differentiating thing for them to market with is an indictment of everyone who didn't apply it, and the industry conditions that led to them. [0] In fairness, the reason we are in this mesz is that said CPU manufacturer has been releasing broken products in the name of speed themselves.
- ajross 4y ago
  > The Linux solution was broken. People knew the Linux solution was broken when it was shipped. That is not a fair characterization. There are endless mountains of theoretical vulnerabilities[1], and no one (certainly not including Xen) tries to mitigate them all blindly. The dwm post linked in the article explicitly says he's not losing sleep over the issue. Everyone (yes, likely including Xen) believed in good faith that this was not practically exploitable. > Frankly, Xen's work here was not at all impressive; they just applied a fix that Intel told everone to apply. And this seems like a misunderstanding too. My gathering from the linked article is that Xen virtualized the barrier mechanism such that the job could be farmed out to guest OSes. Someone running an unpatched Linux under Xen (which is, what, 90+% of the worldwide cloud?) is still vulnerable. But "Xen" is not, which seems maybe less impactful than the marketing being presented would have you believe. [1] Rowhammer says hi.
  - bonzini 4y ago
    > Xen virtualized the barrier mechanism such that the job could be farmed out to guest OSes. All hypervisors do that, including KVM. The difference is that because Xen has to let the guest control the speculation control MSRs, it has to read and write the MSR anyway on every guest<->host context switch. Using IBRS in Xen comes essentially for free. Linux on the other hand does not have to access the speculation control MSR on every userspace<->kernel context switch, and doing so would have had a bigger performance impact than retpolines. Therefore it took a different approach. Now the performance impact wasn't that bad on Skylake and it probably would have been good to use IBRS on those processors. FWIW very old versions of RHEL (6 and 7) in fact did use IBRS instead of retpoline because we had little time (there were less than two months from the time the team was put together to the time we had to have something ready to be shipped to customers) and it even took days to read people on the issue because of how secret it was. So we didn't want to put the compiler update on the critical path.

jscipione 4y ago

I understand why in a data center hosting VMs speculative execution would be impractical, yet on my personal computer speculative execution gives a nice performance boost copying small files.

dontlaugh 4y ago
Your computer also runs attacker controlled code, especially in browsers.