42 ms·

More Intel speculative execution vulnerabilities

640 points by wolf550e 7y ago

deleted 7y ago
[deleted]
aeiou1234 7y ago
another 0-4% performance hit for skylake
- atq2119 7y ago
  The really damning part is that it applies even for processors that are supposedly fixed in silicon because Intel dropped the ball by playing wack-a-mole with proof of concept exploits instead of thoroughly building their chips with security in mind. If the history of Microsoft and Windows security is any indication, it'll take Intel many many years to turn that ship around. There's a question of whether AMD has been mostly unaffected only because their chips haven't received as much scrutiny, but for the time being it does seem that if you care about security, you'd better go with Epyc.
  - dannyw 7y ago
    AMD’s speculative execution design is more risk aversive and it isn’t prone to many of the bugs identified so far. Of course this may change but I think it’s more than just scrutiny: AMD speculates less. Plus, with better IPCs on Ryzen and much greater performance per dollar, why Intel?!
  - wtallis 7y ago
    I don't think anyone seriously expected Intel to be able to thoroughly harden their chips against Spectre-style attacks given just a year to tweak their existing microarchitecture. They were able to move some permissions checks ahead of some speculative actions, but they simply haven't had enough time to design an architecture that can unwind all observable side-effects of mispredictions. It was obvious that all the near-term fixes in silicon would be equivalent to or only slightly better than the microcode or OS-based mitigations.
  - to11mtm 7y ago
    > If the history of Microsoft and Windows security is any indication, it'll take Intel many many years to turn that ship around. AMD's Bulldozer debacle may be a better example, because in some ways it's a better example than Windows. By that, I mean two things. 1) Silicon typically has a pretty long up-front design phase. Meaning there's probably at least 2 upcoming generations in development at any given time. 2) Intel's marketing is somewhat coy about 'architecture' changes, but the sources I found (admittedly just an SO post and Wikipedia) indicate that the number of pipeline stages in the Core series has not changed much over the last few years. IOW it's probably not a full architecture revamp in their 3-step cycle. P6 as an Arch lasted around 15 years, when you think about it (including the original 'Core' i.e. Core 2 Duo/Solo here, as while heavily optimized and revamped, it was still P6). K7/K8 lasted about the same longer (15-ish). Netburst was a bit of an outlier, only lasting around 7 years. Same for Bulldozer. Big assumption here, but based on the pattern I'd assume that Intel originally wasn't even considering a full revamp (or, depending on how they do their iterations, it wouldn't be fully revamped) to be ready until around 2023. Because of the time involved (back to the first point,) I doubt they would be able to have the problem mitigated in silicon until 2021 at the earliest. (As a bonus, they'd probably want/have to qualify it extra well, lest they accidentally introduce a whole new class of vulnerabilities.)
- soulofmischief 7y ago
  I'm glad I started off not overclocking my 6700k with the intent of cranking up the clock over time in order to maintain the same performance with regard to software bloat and mitigations like these. I got lucky and can hit 5Ghz safely, with a base of 4Ghz. Definitely jumping to AMD next time around though. My next upgrade was originally going to be dual Xeons but those Ryzen Pro 3000s are looking nice.
  - Grangar 7y ago
    Yeah I'm looking into upgrading my 6500 to a Ryzen 3 3600. It's a shame there's no B550 boards yet.
    - ben-schaaf 7y ago
      From what we've seen so far B550 is pretty much just x470 (no PCIE4). And B450, B350 boards will do fine running a 3600. I don't really see a point waiting for B550.
      - Grangar 7y ago
        It's mostly just that I'm afraid I'll order a board that isn't on the latest bios, which will be a headache. And an excuse to postpone.
        wormslayer666 7y ago
        Some MSI motherboards (and maybe others?) have a "Flashback" feature to flash BIOS from a USB storage device without needing a CPU.
        frio 7y ago
        I was completely unaware of this feature, and blissfully saved by it when building a computer for a family member. It's a killer feature.
        soulofmischief 7y ago
- stock_toaster 7y ago
  What are we down to now? 70%? 80%? of original performance with all the mitigations added up by now? If a car was advertised as emitting 20% less pollution than it actually did, people would be pissed[1]! [1]: https://en.wikipedia.org/wiki/Volkswagen_emissions_scandal https://en.wikipedia.org/wiki/Volkswagen_emissions_scandal
foxes 7y ago
Another nail in the casket lake. Is the solution just to throw everything out and start again? Do we just abandon speculative execution?
- userbinator 7y ago
  Or we abandon sharing the same hardware for trusted and untrusted code. (Yes, that includes things like whitelisting JS.)
- wolf550e 7y ago
  AMD and others are fine. Just have security people on the team during microarchitecture design. Spectre variant 1 is probably unavoidable so security inside a single virtual address space is kinda dead. Use separate processes and mmu.
- nolok 7y ago
  The problem for most of these is not speculative, it's not doing proper acl during speculation. Just because the cpu is speculating doesn't mean it shouldn't check if you are allowed to access this or that, but that's what Intel did, and they only did the security check at the end before giving back the result, except at this point its too late you've already accessed it. Other manufacturers AMD included didn't get affected by those variants.
  - koheripbal 7y ago
    I wonder what the performance costs of those ACL checks are.
    - nolok 7y ago
      A single one might not be that big, but they add up (if there are several suchs checks to do in your speculated branch, instead of doing them when they appear during speculation intel chips pooled them up all at the end), and they disappear if the speculation was wrong (speculated the wrong branch ? Didn't lose any time on permission check). They're the >~10% of cpu perf intel chips have lost in the last few years with all the mitigations.
Jonnax 7y ago
So Intel failed to mitigate the vulnerability when it was first reported. Then they extended the embargo from May until November. And they still didn't fix it. What's going on with Intel? Like they're going all in with lying in benchmarks against AMD and straight up forgetting what has been reported as security issues.
- nootropicat 7y ago
  https://www.glassdoor.com/Reviews/Employee-Review-Intel-Corporation-RVW12258812.htm https://www.glassdoor.com/Reviews/Employee-Review-Intel-Corp... >Company is dying and has no way to turn itself around. >Culture is a "go along to get along" / don't rock the boat. Most workers are very passive. Inclusive culture focused on internal "networking" rather than winning. A lot of make work going on, probably 25% extra headcount >Middle and upper management are in direct revolt against CEO and his plans. During my orientation (2nd quarter 2013) my orientation meeting was about how the CEO is wrong on his plans. >Advice to Management >Not much you can do. These problems are the result of near monopoly on PC CPUs for 20 years. This place is what Hewlett-Packard was probably like in 2000 (with the printer monopoly), the collapse is coming, but without starting over there is no way to fix it.
  - wtallis 7y ago
    > This place is what Hewlett-Packard was probably like in 2000 (with the printer monopoly), the collapse is coming, but without starting over there is no way to fix it. Interestingly, that printer monopoly seems to be doing fine today, given how I have to go to hp.com to get drivers for my Samsung printer.
    - Jonnax 7y ago
      HP used to be much more. It was a real innovative company. But the interesting parts have been spun out like: Agillent and Keysight. HP Enterprise was also spun out.
      - wtallis 7y ago
iforgotpassword 7y ago
AMD is suffering much less from these flaws. Seems they didn't ignore as many security boundaries with their implementation.
- Craighead 7y ago
  or there are just as many vulnerabilities on amd but researched less
- wolf550e 7y ago
  AMD (and ARM OoO chips) are vulnerable to Spectre variant 1 (bypass in-process array bounds checking) but not to the vast majority (any?) of the other issues which are Intel-only. AMD chips don't have the feature that speculation failure is determined at instruction commit time when it is already too late, so most issues just can't happen.
  - p_l 7y ago
    > AMD (and ARM OoO chips) are vulnerable to Spectre variant 1 (bypass in-process array bounds checking) but not to the vast majority (any?) of the other issues which are Intel-only. > AMD chips don't have the feature that speculation failure is determined at instruction commit time when it is already too late, so most issues just can't happen. Putting memory permissions check in retirement stage of the pipeline couldn't be accidental, I say... Sounds like a great "efficiency hack". Till it fucks up.
    - deleted 7y ago
      [deleted]
  - paulddraper 7y ago
    AFAIK Spectre variant 1 only applies to a single address space; i.e. per process. Processes are really "meant" to be the units of security (user, files, network, memory limit, etc.); it's reasonable to need different processes for security partitions.
    - 7y ago
ageofwant 7y ago
Running the below over my machines gives me back the 8-30% cycles I originally paid for, depending on load type. This will have to do until everything is swapped to AMD. Note you only need 'mitigations=off' in later kernels. - name: Disable CPU-sapping security mitigations become: yes lineinfile: path: /etc/default/grub line: GRUB_CMDLINE_LINUX_DEFAULT="noresume noibrs noibpb nopti nospectre_v2 nospectre_v1 l1tf=off nospec_store_bypass_disable no_stf_barrier mds=off mitigations=off" - name: Update grub become: yes command: /usr/sbin/grub-mkconfig -o /boot/grub/grub.cfg No I don't give a fuck about the 'risk' this introduces, but I expect my bank to.
- wolf550e 7y ago
  Your web browser runs untrusted code. On a computer that never runs untrusted code you can do that.
  - scandinavian 7y ago
    There have been more Chrome/Firefox 0-days than speculative execution vulnerabilities exploitable in Javascript (0). Sure, there is a chance that the Chrome/Firefox teams missed something, but there have been sighted no exploits since the release (of spectrev1) and the browser fixes. It's not a crazy threat model to have on a personal PC, the risk is so very minimal. If your threat model is that strict you shouldn't be running JS anyway.
    - dijit 7y ago
      What are you even talking about? the introduction to this problem came with a proof-of-concept _IN JAVASCRIPT_.[0] Session keys, private keys, passwords and all other kinds of access tokens that your system is using, it's the next worst thing from remote code execution. Your browser runs so much untrusted code that it's really unreasonable, and yes, we should definitely be pushing back hard on this. But it's probably the most stupid thing you can do to disable these mitigations because they're not just theoretical, they're real, they're here and everyone knows about them. This is like anti-vaxx philosophy. "the risk is low"; well, maybe the risk is low because of herd immunity, it's not feasible to run these attacks as they'll be obvious to those who have the mitigations in place (100% CPU), but if there's a 0.00000001% return then it becomes profitable to exploit, just like mail spam. Do not fucking turn off these mitigations on desktop computers, they are too complex and run untrusted code all the time. Unless you can work without javascript and I doubt you can because the web today is basically unusable without it. If you have a database which is only accessible internally, you can disable the mitigations, because those things are hit hardest by the mitigations and do not run untrusted code. But really, your desktop is running untrusted code _a lot_. Please do not do this, not only for your own sake but for everyones sake. Don't make it profitable for malicious agents to run these attacks. [0]: https://www.reddit.com/r/javascript/comments/7ob6a2/spectre_and_meltdown_exploit_javascript_example/ https://www.reddit.com/r/javascript/comments/7ob6a2/spectre_...
jannemann 7y ago
To reiterate the written words from the authors: Intel prevented this particular problem gets to the public and than they flat out lied to the customer.
m_eiman 7y ago
Is it possible to apply the mitigations on an per-application level in Windows? IMHO it'd be pretty useful to be able have them on by default, but disable them for specific applications where you care about maximum performance and know that you won't be running untrusted code.
- systemdtrigger 7y ago
  Tagging on with a similar query. I am on Windows 10. If I were to run Firefox in sandboxie, would be the attacker have to deal with an extra layer of security or does it offer no help?
  - dijit 7y ago
    It will offer no help; for context, imagine that the attacker has access to all memory on the system. It's not -exactly- like that for a bunch of reasons but realistically it's very similar.
- alkonaut 7y ago
  Surely if you emulate a processor without speculative execution with good fidelity (Such as a good NES emulator) then the program running ON that emulator can't deduce anything from speculative execution? Is the answer (for home users) to just sandbox some processes under an emulator layer? I'd be happy to just sandbox some sensitive processes like my browser even if it took a huge performance hit, so long as some other apps like games did not take the same hit.
  - m_eiman 7y ago
    I suppose you could run your trusted applications in the top-most Windows instance without mitigations, and run untrusted applications in a virtualized Windows instance with mitigations enabled. Wouldn't be pretty or very practical, but I suppose it might work?
  - HelloNurse 7y ago
    Not very likely: the attacker is outside the emulated vulnerability-free sandbox, and the state of the emulator is exposed like the state of any other program. Accessing the emulator's memory means accessing the emulated program's memory, it's just slightly obfuscated.
zaphirplane 7y ago
Ok this has been bugging me for a while. How does speculative execution roll back side effect like write to disk or send a packet on the network, when the speculation is wrong. At a guess there are safe instructions that can be run when doing branch prediction?
- jfnixon 7y ago
  I/O takes seven eternities in microcode-ville. It doesn't hurt too much to wait for the speculation to be resolved before changing state visible outside the microarchitecture of the CPU.
- wolf550e 7y ago
  Nothing like that happens. Writes to dram or pcie devices or data bus cannot be rolled back. You have a misunderstanding of what speculative execution entails. The things that get rolled back are writes to general purpose registers.
  - gmueckl 7y ago
    How is this implemented? Undoing register renaming?
    - monocasa 7y ago
      Exactly. Also not committing writes that are almost in the store buffer.
- cwzwarich 7y ago
  Accesses to memory that is configured for device I/O (UnCacheable in x86 terms) are never speculated, so there’s nothing to roll back.
voidmain 7y ago
Can we please have an architectural MSR to disable TSX?
- hansendc 7y ago
  The good news: There's a new MSR which lets you do this: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c2955f270a84762343000f103e0640d29c7a96f3 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin... The less good news: as far as I can tell, Intel did not commit to how architectural this will be going forward. Considering the role TSX has played in speculation-based attacks, it appears to me to be a generic mitigation that would be great to accompany TSX wherever it is available in the future. Now that MSR_IA32_TSX_CTRL is defined, it should be easier to implement going forward. Disclaimer: I work on Linux at Intel.
  - voidmain 7y ago
    ...speculation attacks, and outright bugs in TSX, and the fact that even when everything is working it's a timing mechanism that VMX can't intercept. I really hope it becomes architectural (and gains a bit for HLE)!
  - repolfx 7y ago
    Ah, but TSX is also used to block attacks (on SGX enclaves). So just disabling it entirely seems over simple.
systemdtrigger 7y ago
One question- do these vulnerabilities , including spectre and meltdown only help in stealing information or can they also hijack your computer to do arbitrary things?
- chii 7y ago
  depends on the information you steal. If you steal passwords, then you can use said password to hijack whatever the passwords are protecting. If you steal private keys, you may be able to use said keys to impersonate the victim (like via ssh into their remote machines). But if you're asking if speculative vulns could directly lead to remote code execution, then no (since you already have given the attacker a measure of control, as they are able to execute code already).
- rocqua 7y ago
  It can be used to defeat ASLR, which is a way to make exploiting code harder. However, defeating ASLR just makes it easier to deploy an exploit against a program, but you still need the exploit. It doesn't immediately give code exec, but generally it wouldn't be very hard to turn arbitrary memory read capabilities into privilege escalation. As long as you know what the system is running.
  - systemdtrigger 7y ago
    So the sense I'm making is- that most of thesr attacks need to be supervised and need you to be a target in particular?
    - deleted 7y ago
      [deleted]
    - mrob 7y ago
      The attacker needs some way to execute code on your machine. The code doesn't need any special permissions, although attacks are more difficult (but not impossible) if it doesn't have access to high resolution timing information. You can be a target by visiting a webpage with JavaScript enabled.
xucheng 7y ago
> We are particularly worried about Intel's mitigation plan being PoC-oriented with a complete lack of security engineering and underlying root cause analysis, with minor variations in PoCs leading to new embargoes, and these "new" vulnerabilities remaining unfixed for lengthy periods. Unfortunately, until there is sufficient public / industry pressure, there seems to be little incentive for Intel to change course, leaving the public with a false sense of security. Slapping a year-long embargo after another (many news cycles apart) and keeping vulnerabilities (too) many people are aware of from the public for a long time is still a viable strategy. This is troubling.
- spookydookeedoo 7y ago
  The Deep State works in mysterious ways in plain sight. Freedom is an illusion. ;-)
- mtgx 7y ago
  It certainly is, and that much was obvious as Intel "committed" to fixing Spectre V1 in software as opposed to hardware. Worse yet, it doesn't think a hardware solution is necessary. Except, that pretty much all recent Spectre-related bugs are variants of Spectre V1.
  - bonzini 7y ago
    They are not. They are based on leaking microarchitectural state such as the contents of the store buffer, while spectrev1 is based on leaks from the branch predictor. The difference is that the contents of e.g. the store buffer are short-lived, while branch prediction is by design learning behavior of the program for long term use. It's not a coincidence that Spectre v1 affected all processors and not just Intel x86. Also Spectre v1 still has no widely-deployed hardware mitigation, while for all other vulnerabilities the processor could be patched to add a "flush the leaked state" instruction with a microcode update.
- Mirioron 7y ago
  I wonder if it might not come to bite them though. Doing it this way means that the media will constantly keep talking about yet another vulnerability in Intel CPUs for years. There's a chance that Intel might and up picking a reputation like Flash did for being insecure.
jacquesm 7y ago
Is there a list of the exploits found 'in the wild' that depend on speculative execution?
- wnevets 7y ago
  for regular consumers, its doubtful there are any.
wyldfire 7y ago
> On July 3, 2019, we finally learned that, to our surprise, the Intel PSIRT team had missed the PoCs from our Sep 29 submission, despite having awarded a bounty for it, explaining why Intel had failed to address - or even publicly acknowledge - many RIDL-class vulnerabilities on May 14, 2019. What does this usage of the word 'missed' mean in this context? That they lost it / failed to deliver the PoC to the relevant team? Or that they released a "fix" knowing that it didn't defeat the PoC?
- nolok 7y ago
  From the way the phrase is turned, I believe they released a fix that covered all previously known PoCs but not those from that submission. Generally speaking, that really illustrate the dumb way Intel is going about it, fixing on a PoC basis rather than going after the strong underlying problem. It basically screams "there will always be issues, the question is can you find them !".
annoyingnoob 7y ago
Is disabling hyper-threading a via work-around for these vulnerabilities?
- OrangeMango 7y ago
  My understanding is that this works for many (but not all) of the vulnerabilities. Interestingly, in the past few years Intel has dramatically increased the number of non-SMT processors on their product list. If that is going to be your personal way of mitigating the issue, you've got a choice of 4, 6, and 8 core parts at a significant discount compared to their HyperThreaded variants.
duxup 7y ago
I recall a Google security blog that spoke more generally that with so many layers of code that you don't know what they're doing the result is that effectively they consider any speculative execution that exists at the time of writing the blog may be a potential vulnerability.
openbsd4lyfe 7y ago
Lord Theo was right again!
TheMagicHorsey 7y ago
I worked at Intel in 1998 as a young engineer a few years out of college. Back then they were riding high on their CPU monopoly. I left in about a year and a half and moved to a startup company. My issue with Intel was that, as a monopoly, they had grown fat and complacent. I am not exaggerating when I say that in 1998-99, engineers were working maybe 4-5 productive hours in a week. Political savvy and alliance-building were the most important things for promotions and influence. Those who actually produced good work had credit for their work diluted through many layers of management. You could do something amazing and your manager's manager might present it in a powerpoint to the company without mentioning your name at all, and acting like the idea was his all along. I'm surprised the company has lasted this long. Its a place where mediocre people gather.
ksec 7y ago
And yet, despite all of its security problems and issues with Intel, server vendors are buying more Intel than ever. On one hand they complain about Intel's pricing, threatening about making their CPU with POWER or ARM, on the other hand they happily use AMD as a tool to get better pricing. The sales number dont lie, AMD doesn't even account for 10% of Server CPU shipment, and may not even happen in 2020 given Intel's new price cut.
mikorym 7y ago
What would the performance impact be if they simply took away speculative execution (but not cashing)?

640 points by wolf550e 7y ago

deleted 7y ago

[deleted]

aeiou1234 7y ago

another 0-4% performance hit for skylake

atq2119 7y ago
The really damning part is that it applies even for processors that are supposedly fixed in silicon because Intel dropped the ball by playing wack-a-mole with proof of concept exploits instead of thoroughly building their chips with security in mind. If the history of Microsoft and Windows security is any indication, it'll take Intel many many years to turn that ship around. There's a question of whether AMD has been mostly unaffected only because their chips haven't received as much scrutiny, but for the time being it does seem that if you care about security, you'd better go with Epyc.
- dannyw 7y ago
  AMD’s speculative execution design is more risk aversive and it isn’t prone to many of the bugs identified so far. Of course this may change but I think it’s more than just scrutiny: AMD speculates less. Plus, with better IPCs on Ryzen and much greater performance per dollar, why Intel?!
- wtallis 7y ago
  I don't think anyone seriously expected Intel to be able to thoroughly harden their chips against Spectre-style attacks given just a year to tweak their existing microarchitecture. They were able to move some permissions checks ahead of some speculative actions, but they simply haven't had enough time to design an architecture that can unwind all observable side-effects of mispredictions. It was obvious that all the near-term fixes in silicon would be equivalent to or only slightly better than the microcode or OS-based mitigations.
- to11mtm 7y ago
  > If the history of Microsoft and Windows security is any indication, it'll take Intel many many years to turn that ship around. AMD's Bulldozer debacle may be a better example, because in some ways it's a better example than Windows. By that, I mean two things. 1) Silicon typically has a pretty long up-front design phase. Meaning there's probably at least 2 upcoming generations in development at any given time. 2) Intel's marketing is somewhat coy about 'architecture' changes, but the sources I found (admittedly just an SO post and Wikipedia) indicate that the number of pipeline stages in the Core series has not changed much over the last few years. IOW it's probably not a full architecture revamp in their 3-step cycle. P6 as an Arch lasted around 15 years, when you think about it (including the original 'Core' i.e. Core 2 Duo/Solo here, as while heavily optimized and revamped, it was still P6). K7/K8 lasted about the same longer (15-ish). Netburst was a bit of an outlier, only lasting around 7 years. Same for Bulldozer. Big assumption here, but based on the pattern I'd assume that Intel originally wasn't even considering a full revamp (or, depending on how they do their iterations, it wouldn't be fully revamped) to be ready until around 2023. Because of the time involved (back to the first point,) I doubt they would be able to have the problem mitigated in silicon until 2021 at the earliest. (As a bonus, they'd probably want/have to qualify it extra well, lest they accidentally introduce a whole new class of vulnerabilities.)
soulofmischief 7y ago
I'm glad I started off not overclocking my 6700k with the intent of cranking up the clock over time in order to maintain the same performance with regard to software bloat and mitigations like these. I got lucky and can hit 5Ghz safely, with a base of 4Ghz. Definitely jumping to AMD next time around though. My next upgrade was originally going to be dual Xeons but those Ryzen Pro 3000s are looking nice.
- Grangar 7y ago
  Yeah I'm looking into upgrading my 6500 to a Ryzen 3 3600. It's a shame there's no B550 boards yet.
  - ben-schaaf 7y ago
    From what we've seen so far B550 is pretty much just x470 (no PCIE4). And B450, B350 boards will do fine running a 3600. I don't really see a point waiting for B550.
    - Grangar 7y ago
      It's mostly just that I'm afraid I'll order a board that isn't on the latest bios, which will be a headache. And an excuse to postpone.
      - wormslayer666 7y ago
        Some MSI motherboards (and maybe others?) have a "Flashback" feature to flash BIOS from a USB storage device without needing a CPU.
        frio 7y ago
        I was completely unaware of this feature, and blissfully saved by it when building a computer for a family member. It's a killer feature.
        soulofmischief 7y ago
stock_toaster 7y ago
What are we down to now? 70%? 80%? of original performance with all the mitigations added up by now? If a car was advertised as emitting 20% less pollution than it actually did, people would be pissed[1]! [1]: https://en.wikipedia.org/wiki/Volkswagen_emissions_scandal https://en.wikipedia.org/wiki/Volkswagen_emissions_scandal

foxes 7y ago

Another nail in the casket lake. Is the solution just to throw everything out and start again? Do we just abandon speculative execution?

userbinator 7y ago
Or we abandon sharing the same hardware for trusted and untrusted code. (Yes, that includes things like whitelisting JS.)
wolf550e 7y ago
AMD and others are fine. Just have security people on the team during microarchitecture design. Spectre variant 1 is probably unavoidable so security inside a single virtual address space is kinda dead. Use separate processes and mmu.
nolok 7y ago
The problem for most of these is not speculative, it's not doing proper acl during speculation. Just because the cpu is speculating doesn't mean it shouldn't check if you are allowed to access this or that, but that's what Intel did, and they only did the security check at the end before giving back the result, except at this point its too late you've already accessed it. Other manufacturers AMD included didn't get affected by those variants.
- koheripbal 7y ago
  I wonder what the performance costs of those ACL checks are.
  - nolok 7y ago
    A single one might not be that big, but they add up (if there are several suchs checks to do in your speculated branch, instead of doing them when they appear during speculation intel chips pooled them up all at the end), and they disappear if the speculation was wrong (speculated the wrong branch ? Didn't lose any time on permission check). They're the >~10% of cpu perf intel chips have lost in the last few years with all the mitigations.

Jonnax 7y ago

So Intel failed to mitigate the vulnerability when it was first reported. Then they extended the embargo from May until November. And they still didn't fix it. What's going on with Intel? Like they're going all in with lying in benchmarks against AMD and straight up forgetting what has been reported as security issues.

nootropicat 7y ago
https://www.glassdoor.com/Reviews/Employee-Review-Intel-Corporation-RVW12258812.htm https://www.glassdoor.com/Reviews/Employee-Review-Intel-Corp... >Company is dying and has no way to turn itself around. >Culture is a "go along to get along" / don't rock the boat. Most workers are very passive. Inclusive culture focused on internal "networking" rather than winning. A lot of make work going on, probably 25% extra headcount >Middle and upper management are in direct revolt against CEO and his plans. During my orientation (2nd quarter 2013) my orientation meeting was about how the CEO is wrong on his plans. >Advice to Management >Not much you can do. These problems are the result of near monopoly on PC CPUs for 20 years. This place is what Hewlett-Packard was probably like in 2000 (with the printer monopoly), the collapse is coming, but without starting over there is no way to fix it.
- wtallis 7y ago
  > This place is what Hewlett-Packard was probably like in 2000 (with the printer monopoly), the collapse is coming, but without starting over there is no way to fix it. Interestingly, that printer monopoly seems to be doing fine today, given how I have to go to hp.com to get drivers for my Samsung printer.
  - Jonnax 7y ago
    HP used to be much more. It was a real innovative company. But the interesting parts have been spun out like: Agillent and Keysight. HP Enterprise was also spun out.
    - wtallis 7y ago

iforgotpassword 7y ago

AMD is suffering much less from these flaws. Seems they didn't ignore as many security boundaries with their implementation.

Craighead 7y ago
or there are just as many vulnerabilities on amd but researched less
wolf550e 7y ago
AMD (and ARM OoO chips) are vulnerable to Spectre variant 1 (bypass in-process array bounds checking) but not to the vast majority (any?) of the other issues which are Intel-only. AMD chips don't have the feature that speculation failure is determined at instruction commit time when it is already too late, so most issues just can't happen.
- p_l 7y ago
  > AMD (and ARM OoO chips) are vulnerable to Spectre variant 1 (bypass in-process array bounds checking) but not to the vast majority (any?) of the other issues which are Intel-only. > AMD chips don't have the feature that speculation failure is determined at instruction commit time when it is already too late, so most issues just can't happen. Putting memory permissions check in retirement stage of the pipeline couldn't be accidental, I say... Sounds like a great "efficiency hack". Till it fucks up.
  - deleted 7y ago
    [deleted]
- paulddraper 7y ago
  AFAIK Spectre variant 1 only applies to a single address space; i.e. per process. Processes are really "meant" to be the units of security (user, files, network, memory limit, etc.); it's reasonable to need different processes for security partitions.
  - 7y ago

ageofwant 7y ago

Running the below over my machines gives me back the 8-30% cycles I originally paid for, depending on load type. This will have to do until everything is swapped to AMD. Note you only need 'mitigations=off' in later kernels. - name: Disable CPU-sapping security mitigations become: yes lineinfile: path: /etc/default/grub line: GRUB_CMDLINE_LINUX_DEFAULT="noresume noibrs noibpb nopti nospectre_v2 nospectre_v1 l1tf=off nospec_store_bypass_disable no_stf_barrier mds=off mitigations=off" - name: Update grub become: yes command: /usr/sbin/grub-mkconfig -o /boot/grub/grub.cfg No I don't give a fuck about the 'risk' this introduces, but I expect my bank to.

wolf550e 7y ago
Your web browser runs untrusted code. On a computer that never runs untrusted code you can do that.
- scandinavian 7y ago
  There have been more Chrome/Firefox 0-days than speculative execution vulnerabilities exploitable in Javascript (0). Sure, there is a chance that the Chrome/Firefox teams missed something, but there have been sighted no exploits since the release (of spectrev1) and the browser fixes. It's not a crazy threat model to have on a personal PC, the risk is so very minimal. If your threat model is that strict you shouldn't be running JS anyway.
  - dijit 7y ago
    What are you even talking about? the introduction to this problem came with a proof-of-concept _IN JAVASCRIPT_.[0] Session keys, private keys, passwords and all other kinds of access tokens that your system is using, it's the next worst thing from remote code execution. Your browser runs so much untrusted code that it's really unreasonable, and yes, we should definitely be pushing back hard on this. But it's probably the most stupid thing you can do to disable these mitigations because they're not just theoretical, they're real, they're here and everyone knows about them. This is like anti-vaxx philosophy. "the risk is low"; well, maybe the risk is low because of herd immunity, it's not feasible to run these attacks as they'll be obvious to those who have the mitigations in place (100% CPU), but if there's a 0.00000001% return then it becomes profitable to exploit, just like mail spam. Do not fucking turn off these mitigations on desktop computers, they are too complex and run untrusted code all the time. Unless you can work without javascript and I doubt you can because the web today is basically unusable without it. If you have a database which is only accessible internally, you can disable the mitigations, because those things are hit hardest by the mitigations and do not run untrusted code. But really, your desktop is running untrusted code _a lot_. Please do not do this, not only for your own sake but for everyones sake. Don't make it profitable for malicious agents to run these attacks. [0]: https://www.reddit.com/r/javascript/comments/7ob6a2/spectre_and_meltdown_exploit_javascript_example/ https://www.reddit.com/r/javascript/comments/7ob6a2/spectre_...

jannemann 7y ago

To reiterate the written words from the authors: Intel prevented this particular problem gets to the public and than they flat out lied to the customer.

m_eiman 7y ago

Is it possible to apply the mitigations on an per-application level in Windows? IMHO it'd be pretty useful to be able have them on by default, but disable them for specific applications where you care about maximum performance and know that you won't be running untrusted code.

systemdtrigger 7y ago
Tagging on with a similar query. I am on Windows 10. If I were to run Firefox in sandboxie, would be the attacker have to deal with an extra layer of security or does it offer no help?
- dijit 7y ago
  It will offer no help; for context, imagine that the attacker has access to all memory on the system. It's not -exactly- like that for a bunch of reasons but realistically it's very similar.
alkonaut 7y ago
Surely if you emulate a processor without speculative execution with good fidelity (Such as a good NES emulator) then the program running ON that emulator can't deduce anything from speculative execution? Is the answer (for home users) to just sandbox some processes under an emulator layer? I'd be happy to just sandbox some sensitive processes like my browser even if it took a huge performance hit, so long as some other apps like games did not take the same hit.
- m_eiman 7y ago
  I suppose you could run your trusted applications in the top-most Windows instance without mitigations, and run untrusted applications in a virtualized Windows instance with mitigations enabled. Wouldn't be pretty or very practical, but I suppose it might work?
- HelloNurse 7y ago
  Not very likely: the attacker is outside the emulated vulnerability-free sandbox, and the state of the emulator is exposed like the state of any other program. Accessing the emulator's memory means accessing the emulated program's memory, it's just slightly obfuscated.

zaphirplane 7y ago

Ok this has been bugging me for a while. How does speculative execution roll back side effect like write to disk or send a packet on the network, when the speculation is wrong. At a guess there are safe instructions that can be run when doing branch prediction?

jfnixon 7y ago
I/O takes seven eternities in microcode-ville. It doesn't hurt too much to wait for the speculation to be resolved before changing state visible outside the microarchitecture of the CPU.
wolf550e 7y ago
Nothing like that happens. Writes to dram or pcie devices or data bus cannot be rolled back. You have a misunderstanding of what speculative execution entails. The things that get rolled back are writes to general purpose registers.
- gmueckl 7y ago
  How is this implemented? Undoing register renaming?
  - monocasa 7y ago
    Exactly. Also not committing writes that are almost in the store buffer.
cwzwarich 7y ago
Accesses to memory that is configured for device I/O (UnCacheable in x86 terms) are never speculated, so there’s nothing to roll back.

voidmain 7y ago

Can we please have an architectural MSR to disable TSX?

hansendc 7y ago
The good news: There's a new MSR which lets you do this: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c2955f270a84762343000f103e0640d29c7a96f3 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin... The less good news: as far as I can tell, Intel did not commit to how architectural this will be going forward. Considering the role TSX has played in speculation-based attacks, it appears to me to be a generic mitigation that would be great to accompany TSX wherever it is available in the future. Now that MSR_IA32_TSX_CTRL is defined, it should be easier to implement going forward. Disclaimer: I work on Linux at Intel.
- voidmain 7y ago
  ...speculation attacks, and outright bugs in TSX, and the fact that even when everything is working it's a timing mechanism that VMX can't intercept. I really hope it becomes architectural (and gains a bit for HLE)!
- repolfx 7y ago
  Ah, but TSX is also used to block attacks (on SGX enclaves). So just disabling it entirely seems over simple.

systemdtrigger 7y ago

One question- do these vulnerabilities , including spectre and meltdown only help in stealing information or can they also hijack your computer to do arbitrary things?

chii 7y ago
depends on the information you steal. If you steal passwords, then you can use said password to hijack whatever the passwords are protecting. If you steal private keys, you may be able to use said keys to impersonate the victim (like via ssh into their remote machines). But if you're asking if speculative vulns could directly lead to remote code execution, then no (since you already have given the attacker a measure of control, as they are able to execute code already).
rocqua 7y ago
It can be used to defeat ASLR, which is a way to make exploiting code harder. However, defeating ASLR just makes it easier to deploy an exploit against a program, but you still need the exploit. It doesn't immediately give code exec, but generally it wouldn't be very hard to turn arbitrary memory read capabilities into privilege escalation. As long as you know what the system is running.
- systemdtrigger 7y ago
  So the sense I'm making is- that most of thesr attacks need to be supervised and need you to be a target in particular?
  - deleted 7y ago
    [deleted]
  - mrob 7y ago
    The attacker needs some way to execute code on your machine. The code doesn't need any special permissions, although attacks are more difficult (but not impossible) if it doesn't have access to high resolution timing information. You can be a target by visiting a webpage with JavaScript enabled.

xucheng 7y ago

> We are particularly worried about Intel's mitigation plan being PoC-oriented with a complete lack of security engineering and underlying root cause analysis, with minor variations in PoCs leading to new embargoes, and these "new" vulnerabilities remaining unfixed for lengthy periods. Unfortunately, until there is sufficient public / industry pressure, there seems to be little incentive for Intel to change course, leaving the public with a false sense of security. Slapping a year-long embargo after another (many news cycles apart) and keeping vulnerabilities (too) many people are aware of from the public for a long time is still a viable strategy. This is troubling.

spookydookeedoo 7y ago
The Deep State works in mysterious ways in plain sight. Freedom is an illusion. ;-)
mtgx 7y ago
It certainly is, and that much was obvious as Intel "committed" to fixing Spectre V1 in software as opposed to hardware. Worse yet, it doesn't think a hardware solution is necessary. Except, that pretty much all recent Spectre-related bugs are variants of Spectre V1.
- bonzini 7y ago
  They are not. They are based on leaking microarchitectural state such as the contents of the store buffer, while spectrev1 is based on leaks from the branch predictor. The difference is that the contents of e.g. the store buffer are short-lived, while branch prediction is by design learning behavior of the program for long term use. It's not a coincidence that Spectre v1 affected all processors and not just Intel x86. Also Spectre v1 still has no widely-deployed hardware mitigation, while for all other vulnerabilities the processor could be patched to add a "flush the leaked state" instruction with a microcode update.
Mirioron 7y ago
I wonder if it might not come to bite them though. Doing it this way means that the media will constantly keep talking about yet another vulnerability in Intel CPUs for years. There's a chance that Intel might and up picking a reputation like Flash did for being insecure.

jacquesm 7y ago

Is there a list of the exploits found 'in the wild' that depend on speculative execution?

wnevets 7y ago
for regular consumers, its doubtful there are any.

wyldfire 7y ago

> On July 3, 2019, we finally learned that, to our surprise, the Intel PSIRT team had missed the PoCs from our Sep 29 submission, despite having awarded a bounty for it, explaining why Intel had failed to address - or even publicly acknowledge - many RIDL-class vulnerabilities on May 14, 2019. What does this usage of the word 'missed' mean in this context? That they lost it / failed to deliver the PoC to the relevant team? Or that they released a "fix" knowing that it didn't defeat the PoC?

nolok 7y ago
From the way the phrase is turned, I believe they released a fix that covered all previously known PoCs but not those from that submission. Generally speaking, that really illustrate the dumb way Intel is going about it, fixing on a PoC basis rather than going after the strong underlying problem. It basically screams "there will always be issues, the question is can you find them !".

annoyingnoob 7y ago

Is disabling hyper-threading a via work-around for these vulnerabilities?

OrangeMango 7y ago
My understanding is that this works for many (but not all) of the vulnerabilities. Interestingly, in the past few years Intel has dramatically increased the number of non-SMT processors on their product list. If that is going to be your personal way of mitigating the issue, you've got a choice of 4, 6, and 8 core parts at a significant discount compared to their HyperThreaded variants.

duxup 7y ago

I recall a Google security blog that spoke more generally that with so many layers of code that you don't know what they're doing the result is that effectively they consider any speculative execution that exists at the time of writing the blog may be a potential vulnerability.

openbsd4lyfe 7y ago

Lord Theo was right again!

TheMagicHorsey 7y ago

I worked at Intel in 1998 as a young engineer a few years out of college. Back then they were riding high on their CPU monopoly. I left in about a year and a half and moved to a startup company. My issue with Intel was that, as a monopoly, they had grown fat and complacent. I am not exaggerating when I say that in 1998-99, engineers were working maybe 4-5 productive hours in a week. Political savvy and alliance-building were the most important things for promotions and influence. Those who actually produced good work had credit for their work diluted through many layers of management. You could do something amazing and your manager's manager might present it in a powerpoint to the company without mentioning your name at all, and acting like the idea was his all along. I'm surprised the company has lasted this long. Its a place where mediocre people gather.

ksec 7y ago

And yet, despite all of its security problems and issues with Intel, server vendors are buying more Intel than ever. On one hand they complain about Intel's pricing, threatening about making their CPU with POWER or ARM, on the other hand they happily use AMD as a tool to get better pricing. The sales number dont lie, AMD doesn't even account for 10% of Server CPU shipment, and may not even happen in 2020 given Intel's new price cut.

mikorym 7y ago

What would the performance impact be if they simply took away speculative execution (but not cashing)?