11 ms·

Intel CEO: Patches will come to 90% of chips in the next week

155 points by elektor 9y ago

pdelbarba 9y ago
So when will chips with a fix in silicon be available?
- ashleyn 9y ago
  I'm giving it one to two generations of CPUs before I do a new build.
  - krylon 9y ago
    But since the OS fixes to protect against meltdown come with a potential performance penalty, AMD is a better choice now than it was a week ago.
    - snuxoll 9y ago
      Been planning on buying EPYC for our upcoming OpenShift deployment already - now I’ve got a smoking gun to get management onboard.
- welder 9y ago
  Just buy an AMD chip right now.
  - privong 9y ago
    > Just buy an AMD chip right now. AMD chips are reportedly susceptible to Spectre, so that's not going to help. From https://meltdownattack.com https://meltdownattack.com: Almost every system is affected by Spectre: Desktops, Laptops, Cloud Servers, as well as Smartphones. More specifically, all modern processors capable of keeping many instructions in flight are potentially vulnerable. In particular, we have verified Spectre on Intel, AMD, and ARM processors.
    - lawrenceyan 9y ago
      Meltdown, however, is the one that results in nontrivial performance degradation in order to patch. And Meltdown specifically only affects Intel processors.
      - onedognight 9y ago
        Meltdown affects some ARM prcessors as well. https://developer.arm.com/support/security-update https://developer.arm.com/support/security-update
        lawrenceyan 9y ago
        My response was in the context of privong stating that Intel and AMD were equivalently affected, when it is specifically Intel that suffers performance degradation in patching due to their unsafe usage of speculative execution.
        privong 9y ago
        I only said they were both affected by Spectre. But it wasn't clear if the OP was worried about performance issues or security issues, so it isn't clear on what basis they were suggesting that buying AMD is a solution.
      - noselasd 9y ago
        AMD is not susceptible to Meltdown. So the issue is not inherent to the x86_64 architecture. Knowing that, can it be possible that Intel can patch their CPU via micro-code in a manner that does not affect performance to a great degree, and not require a software patch to solve the Meltdown attach ?
  - KirinDave 9y ago
    True for meltdown, not for spectre.
  - sounds 9y ago
    Specifically buy an AMD Ryzen: https://www.amd.com/en/corporate/speculative-execution https://www.amd.com/en/corporate/speculative-execution Ryzen is only affected by "Spectre variant one, Bounds Check Bypass" It's fixed by OS updates with negligible performance impact expected.
  - xioxox 9y ago
    How common is the Linux segfault problem on Ryzen now? Just reading about the horrible RMA procedure puts me off AMD unless they can clean up their terrible handling of this problem.
    - paulmd 9y ago
      It's still out there. To be clear, virtually no chips before Week 25 pass the segfault test, a large number of chips afterwards pass the segfault test. AMD clearly either upped their production standards or is binning out the worst chips. But there is still a baseline of chips failing. Some reported instances: https://community.amd.com/thread/215773?start=1635&tstart=0 https://community.amd.com/thread/215773?start=1635&tstart=0 (user jcoiner, 1726PGT) https://community.amd.com/thread/215773?start=1725&tstart=0 https://community.amd.com/thread/215773?start=1725&tstart=0 (user scorpio810, 2x 1728SUS) https://community.amd.com/thread/215773?start=1770&tstart=0 https://community.amd.com/thread/215773?start=1770&tstart=0 (user ryzlin, 1733PGT) https://community.amd.com/thread/215773?start=1785&tstart=0 https://community.amd.com/thread/215773?start=1785&tstart=0 (user flyinryzen1700, 1737SUS) https://community.amd.com/thread/215773?start=1830&tstart=0 https://community.amd.com/thread/215773?start=1830&tstart=0 (user skimba 1725PGT, user xtronom 1728PGT) https://community.amd.com/thread/215773?start=1860&tstart=0 https://community.amd.com/thread/215773?start=1860&tstart=0 (user jc_yang, 1742SUS) https://www.reddit.com/r/Amd/comments/76q7ne/got_a_defective_ryzen_7_1700_on_rma_process/dofye3u/ https://www.reddit.com/r/Amd/comments/76q7ne/got_a_defective... (user grosbof 1733SUS) https://www.reddit.com/r/Amd/comments/7ar15o/psa_amazon_is_still_selling_preweek_25_ryzens/dpc5iue/ https://www.reddit.com/r/Amd/comments/7ar15o/psa_amazon_is_s... (user triplesal, 1733PGS) https://www.reddit.com/r/Amd/comments/7ar15o/psa_amazon_is_still_selling_preweek_25_ryzens/dpcrkv0/ https://www.reddit.com/r/Amd/comments/7ar15o/psa_amazon_is_s... (user istockporno, 1726PGT) Presumably this is something that will be fixed in the Zen+ stepping/Pinnacle Ridge (Ryzen 2 - not to be confused with Zen2, which will release in 2019?, likely as the Ryzen 3 series). But for the meantime, be aware that you are absolutely buying silicon with known issues and that you should test it and RMA if necessary, and that there is fixed silicon coming within a couple months here that will probably run significantly faster due to process improvements.
glandium 9y ago
I thought they already provided a microcode update?
- nickysielicki 9y ago
  Latest version on downloadcenter.intel.com is 20171117; no microcode update has been published since Spectre/Meltdown have been disclosed. edit: see below, not true; they haven't published it on their own site but have pushed microcode updates to redhat.
  - kzrdude 9y ago
    There's a partial update package debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=886367#22 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=886367#22 Seems to be taken from redhat updates. It's floating around unseriously in debian unstable instead of being a security update, I guess Debian's FOSS imperative doesn't mix so well with non-free (intel-microcode) updates. > Anyway, uploading a partial, unofficial set of updates to unstable to close the bug. Several processors are still missing. I expect an official release from Intel soon, hopefully with updates for everything. > Implements IBRS and IBPB support via new MSR (Spectre variant 2 mitigation, indirect branches). Support is exposed through cpuid(7).EDX. > LFENCE terminates all previous instructions (Spectre variant 2 mitigation, conditional branches).
  - muppetman 9y ago
    Found via @grsecurity about 15 minutes ago: https://downloadcenter.intel.com/download/27431/Linux-Processor-Microcode-Data-File?product=122139 https://downloadcenter.intel.com/download/27431/Linux-Proces...
  - deleted 9y ago
    [deleted]
  - deleted 9y ago
    [deleted]
y3sh 9y ago
At what performance cost?
dooglius 9y ago
If Intel knew about the issues on June 1, why are the patches only appearing now? I thought the point of an embargo was to let the fixes come first.
- dm319 9y ago
  It was meant to be embargoed til today, but the news came out earlier than expected. Sounds like people have been working round the clock since the discovery to patch this.
maltalex 9y ago
How does one patch a CPU? Does the update come in the form of a BIOS update? If so, then the patch still has to travel through the PC manufacturers, like when Google patches Android. Or can it be somehow applied directly? Edit: Apparently the OS can update the CPU's microcode. No need for BIOS updates. It was even done in the past. For instance, an unrelated Windows Vista update that updates microcode: https://support.microsoft.com/en-us/help/936357/a-microcode-reliability-update-is-available-that-improves-the-reliabil https://support.microsoft.com/en-us/help/936357/a-microcode-...
- nickysielicki 9y ago
  https://wiki.debian.org/Microcode https://wiki.debian.org/Microcode The real news here is that Intel thinks they can fix this via microcode. This is surprising because initially there were some strong arguments that this wouldn't be possible.
  - maltalex 9y ago
    Yeah, well, let's not break out the champagne yet. According to your link: > The BIOS (or UEFI) updates the CPU microcode during boot, however most of the time either the motherboard vendor won't issue frequent BIOS/UEFI updates, or the user won't install such updates. For these reasons, the system processor is likely to be running with outdated microcode on a vast number of systems. We still need the various manufacturers to release a BIOS version for a bunch of hardware they manufactured years ago. I'm not sure that's going to happen, at least not quickly.
    - herpderperator 9y ago
      Microcode is updated by OSes as well as BIOSes. I explained this in a previous thread: https://news.ycombinator.com/item?id=16075376 https://news.ycombinator.com/item?id=16075376
      - zerocrates 9y ago
        Microsoft is still saying that users need firmware/BIOS updates to be protected. Their messaging is at best confusing on this if they're going to apply microcode updates themselves. In the early days after disclosure at least, a BIOS/firmware update for my machine (from Dell) was required to provide the necessary hardware support for their branch target injection mitigation. As far as I can tell, that's still the case today. Perhaps they're waiting for the updates to be available for more processors before pushing an update?
jokoon 9y ago
I wonder what will the next big security hole. I'm becoming very pessimistic about how I can trust computers. Computers can do amazing thing, but software seems fragile, unreliable and untrustworthy. I have been keeping notes on paper for years now, and it doesn't look like it's going to change.
- sigmar 9y ago
  Internet-connected computers are more secure now than they ever have been. Just take the standard precautions: update your OS and don't install untrusted apps.
  - jacquesm 9y ago
    And do not visit untrusted webpages with javascript enabled? And how do you know which pages you can trust?
    - flukus 9y ago
      Even trusted webpages pull in crap from all sorts of places that I don't trust, the way the web is structured is a disaster. My public news provider for instance (http://www.abc.net.au/news/ http://www.abc.net.au/news/) has all sorts of shit broken when you run ublock or noscript. There "live breaking news feeds" that are rather important may as well be a blank page because it just reposts twitter messages. And they're one of the better sites with no advertising.
    - pstuart 9y ago
      They'll tell you if they're ok. /s
  - jokoon 9y ago
    I think it's actually the opposite. Internet is still growing, and so is the computer security economy. Look at all the data breaches and leaks.
- wott 9y ago
  It's been a while I don't bother much about security any more, because I consider everything insecure. So I just do not put all my eggs in the same basket, I do not store much personal information on my computer, I store even less online, I do not store any money/payment related information, and I just admit I will however sometimes get my butt kicked here or there. It is like my house. Anyone can break in at any time, and steal my belongings. Do I install an armoured door? Do I build grids on windows? Do I install an alarm with a direct link to a security company? No, no, and no. I just lock my front door. It only protects from a part of opportunity robberies and that's enough for me. I won't take measures to prevent all other possibilities. They can happen at any time, with no difficulty. And so what? Back to computers. So this very basic mitigation, very limited damage control is enough to make me feel OK. It feels better to admit insecurity as a given, than to constantly fight for a false feeling of security I cannot achieve anyway.
dm319 9y ago
Surely he is talking about the Win/Mac/Linux kernel patches? Would seem bizarre for all the work to go on the kernels when Intel had some firmware patches up their sleeve? Also I thought Spectre is something that is unlikely to be patched in the near future.
- rocqua 9y ago
  I believe there are microcode patches that help make spectre harder. I also have a vague recollection of the fix for meltdown on the newest CPUs requiring a microcode patch for complete protection.
- deleted 9y ago
  [deleted]
dmitrygr 9y ago
Keep in mind, they did NOT say patches with no cost. Mostly they are adding ways to disable speculation on indirect branches. This has a cost.
maltalex 9y ago
Any guesses as to which vulnerabilities they're going to patch? Some of them? All of them?
- pizlonator 9y ago
  Just the indirect branch bug. That’s “half” of Spectre. IMO the harder to exploit half.
bcantrill 9y ago
This is only Spectre, not Meltdown. Meltdown requires KPTI, which depends on your OS. For OSs that did not enjoy months of advanced disclosure (which is: any OS that isn't Windows, MacOS or mainline Linux), that work is ongoing and will depend on the OS. (Speaking for SmartOS/illumos, that work is reasonably far along and making promising progress -- but we don't yet have a functional prototype.) As for Spectre, these are just the microcode updates that have the additional MSRs that allow system software to mitigate certain variants of Spectre attack against the system software itself. They are necessary, but emphatically not sufficient -- and it would disingenuous for Intel to pretend that this in any way means that 90% of systems are protected from Meltdown and Spectre.
- cryptonector 9y ago
  What's the story for Illumos as to Meltdown and Spectre? I expect KPTI for Meltdown and then the same disable-speculation-for-indirect-call-in-kernel fix that everyone else is applying. With KVM the Illumos hypervisor should be free of attack, so maybe Joyent needs nothing more. EDIT: thanks for the update (or did I misread earlier?).
- shirian 9y ago
  For reference, I received this email before today: By now, we're sure most everyone have heard of the Meltdown and Spectre attacks. If not, head over to https://meltdownattack.com/ https://meltdownattack.com/ and get an overview. Additional technical details are available from Google Project Zero. https://googleprojectzero.blogspot.com/2018/01/reading-privileged-memory-with-side.html https://googleprojectzero.blogspot.com/2018/01/reading-privi... The FreeBSD Security Team was notified of the issue in late December and received a briefing under NDA with the original embargo date of January 9th. Since we received relatively late notice of the issue, our ability to provide fixes is delayed. Meltdown (CVE-2017-5754) ~~~~~~~~~~~~~~~~~~~~~~~~ In terms of priority, the first step is to mitigate against the Meltdown attack (CVE-2017-5754, cited as variant 3 by Project Zero). Work for this is ongoing, but due to the relatively large changes needed, this is going to take a little while. We are currently targeting patches for amd64 being dev complete this week with testing probably running into next week. From there, we hope to give it a short bake time before pushing it into the 11.1-RELEASE branch. Additional work will be required to bring the mitigation to 10.3-RELEASE and 10.4-RELEASE. The code will be selectable via a tunable which will automatically turn on for modern Intel processors and off for AMD processors (since they are reportedly not vulnerable). Since the fix for Meltdown does incur a performance hit for any transition between user space and kernel space, this could be rather impactful depending on the workload. As such, the tunable can also be overridden by the end-user if they are willing to accept the risk. Initial work can be tracked at https://reviews.freebsd.org/D13797 https://reviews.freebsd.org/D13797. Please note this is a work in progress and some stuff is likely to be broken. Spectre (CVE-2017-5753 and CVE-2017-5715) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ When it comes to the Spectre vulnerabilities, it is much harder to sort these out. Variant 1 (CVE-2017-5753) is going to require some static analysis to determine vulnerable use cases that will require barriers to stop speculation from disclosing information it shouldn't. While we haven't done the analysis to determine where we are vulnerable, the number of cases here are supposed to be pretty small. Apparently there have been some Coverity rules developed to help look for these, but we are still evaluating what can be done here. The other half of Spectre, variant 2 (CVE-2017-5715) is a bit trickier as it affects both normal processes and bhyve. There is a proposed patch for LLVM (https://reviews.llvm.org/D41723 https://reviews.llvm.org/D41723) that introduces a concept called 'retpoline' which mitigates this issue. We are likely to pull this into HEAD and 11-STABLE once it hits the LLVM tree. Unfortunately, the currently supported FreeBSD releases are using older versions of LLVM for which we are not sure the LLVM project will produce patches. We will be looking at the feasibility to backport these patches to these earlier versions. There are CPU microcode fixes coming out when in concert with OS changes would also help, but that's a bit down the road at the moment. If anything significantly changes I will make additional posts to clarify as the information becomes available. Best regards, Gordon Tetlow with security-officer hat on
guelo 9y ago
What I'm worried about is that it will be hard to avoid these security patches when you don't need them. Say you have a non-virtualized, non-shared server that only runs your own trusted code. I don't want to be forced to pay the performance penalty but it might be unavoidable without resorting to maintaining your own linux fork.
- dakerfp 9y ago
  that should be enabled by a boot flag
- zorked 9y ago
  What happens when your trusted code gets exploited? That's also the reason why we have overhead in the form of ACLs, memory protection, ASLR, packet filtering, deprivileged processes, seccomp sandboxes, etc. even though in principle we're all running "trusted code". Not saying that there isn't a scenario where it would be ok to turn that off, but it's the exception.
- jacquesm 9y ago
  Do you trust all of the userland? Is your machine internet connected? Do you have any open ports? Do you run everything as root? If your answers are yes, no, no, and yes than it likely will make no difference. Otherwise (and the last one is just for fun to attempt to show you this is probably not a wise decision) you probably would do better to take this serious.
  - berkut 9y ago
    For private servers that are totally not connected to the internet in any way and don't need to be, run self-developed code on data which is mainly CPU-bound but also need a lot of disk IO for reading files and memory mapping data, I'm pretty certain it'll make a noticeable difference, for no security benefit.
    - appleflaxen 9y ago
      but isn't it pretty easy to avoid the security update on those machines?
zeep 9y ago
10% equals how many billions of chips?
donaldihunter 9y ago
https://support.apple.com/en-us/HT208394 https://support.apple.com/en-us/HT208394
flukus 9y ago
According to last weeks press release, they mean 90% of recent chips, which is far less than 90% of intel CPU's out in the wild: https://newsroom.intel.com/news-releases/intel-issues-updates-protect-systems-security-exploits/ https://newsroom.intel.com/news-releases/intel-issues-update... > Intel has already issued updates for the majority of processor products introduced within the past five years. By the end of next week, Intel expects to have issued updates for more than 90 percent of processor products introduced within the past five years It's also unclear what they mean by "introduced within" Does it mean when the product was first developed? First on sale? If I bought a new computer 3 years ago what is the likely-hood that it's CPU was "introduced" much earlier?
- petascale 9y ago
  Presumably the launch date, Intel lists launch dates for all of their processors on ark.intel.com [1] 5 years is Haswell, so Haswell and newer should get the microcode fix. A 3 year old computer is likely to have a CPU no more than 4 years old, but you can look it up to verify. (Both Windows and Linux can show the CPU model, and Intel's Ark site gives the release date.) [1] https://ark.intel.com/products/series/75023/4th-Generation-Intel-Core-i7-Processors https://ark.intel.com/products/series/75023/4th-Generation-I...
  - flukus 9y ago
    Thanks. My work computer is in the legacy section (release Q4'11), so it looks like I might be getting a new one. A shame really, it's still mostly adequate, the only thing making it age are the continued bloat from Visual Studio.
lifeformed 9y ago
Have there been any reports of exploits using Meltdown/Spectre in the wild yet?
- Tom4hawk 9y ago
  https://meltdownattack.com/ https://meltdownattack.com/ > FAQ > Has Meltdown or Spectre been abused in the wild? > We don't know. So probably no reports ;)
kyledrake 9y ago
This is how this terrible CEO tells us about microcode fixes, at a CES speech? Or is he even talking about a microcode update, or about the patches everybody else has been losing their lives working on? What a crap response to such a huge and existential issue. Make a web page on the Intel site with concise, real information on what's going on and what to do. We're a week into disclosure and there's still no patch for most people's servers. A patch that takes up to a 30% performance hit but may not be necessary if there's going to be a microcode fix? I know this is just a cute speech and debate practice session for the Intel execs, but I have servers that will have to get trashed because of the slowdown patch, they will be too slow to function in their current role and will need to be replaced. This is seriously affecting my life, my work schedule and my wallet. Please have real engineers provide real information here.
- sounds 9y ago
  Let me break down what the article really says (it's pretty short): > He also said that Intel expects to issue updates > to its processors soon. More than 90 percent will be > getting them within the week, and the rest by the end > of January. Intel expects 90 percent will "get an update." 90 percent of what? It should be self-evident that Intel means 90 percent in whichever way gives them the largest percentage. I expect this means Intel discounts "older CPUs" that are "probably not in use." In other words, 90 percent of CPUs sold in the last N years for whatever N makes the percentage largest (5 years [1]) "The rest by the end of January" can be taken with a huge grain of salt. Intel is documenting and exposing an MSR to flush the [ed] branch predictor, but only for recent CPUs, and admits they aren't able to do so in a timely manner, or they would have said "100 percent." [1] https://newsroom.intel.com/news-releases/intel-issues-updates-protect-systems-security-exploits/ https://newsroom.intel.com/news-releases/intel-issues-update... "Intel has already issued updates for the majority of processor products introduced within the past five years. By the end of next week, Intel expects to have issued updates for more than 90 percent of processor products introduced within the past five years" Edit: I incorrectly stated the MSR was for the TLB, it is not. It is for the branch predictor.
  - vardump 9y ago
deleted 9y ago
[deleted]
phkahler 9y ago
I half thought he was going to talk about using ME to push updates to Intel-based machines. Thank god they have a backdoor to fix security issues! ;-)
quadcore 9y ago
How do you patch a CPU remotely? Are the instructions programmable?
- InclinedPlane 9y ago
  CPUs have code that runs code, essentially. Think of a modern CPU as like a collection of micro-controllers. You have micro-controllers which reads a stream of machine code instructions for a particular instruction set (e.g. x86-64) translates that code into "micro-ops" (RISC-like fine grained instructions) that are then re-ordered and so forth and fired off into the CPU core(s) proper. That whole process relies on a ton of code that exists as essentially "firmware" (microcode) within the processor. Things like translation tables for architecture level instructions (x86-64) to micro-ops as well as code for the scheduler, the branch predictor, and various other micro-architectural parts of the CPU. Some of these elements are hardwired into the silicon, some are controlled via decode tables, and some are controlled via flags and perhaps even instructions running on different components of the CPU, all of that together is grouped under the heading "microcode". A modern CPU is not infinitely programmable because a lot of functionality is hardwired (for example, what each micro-op does) but there's still a great deal of flexibility in how things work (such as exactly how the branch predictor and scheduler work, the translation of instructions to micro-ops, etc.)

155 points by elektor 9y ago

pdelbarba 9y ago

So when will chips with a fix in silicon be available?

ashleyn 9y ago
I'm giving it one to two generations of CPUs before I do a new build.
- krylon 9y ago
  But since the OS fixes to protect against meltdown come with a potential performance penalty, AMD is a better choice now than it was a week ago.
  - snuxoll 9y ago
    Been planning on buying EPYC for our upcoming OpenShift deployment already - now I’ve got a smoking gun to get management onboard.
welder 9y ago
Just buy an AMD chip right now.
- privong 9y ago
  > Just buy an AMD chip right now. AMD chips are reportedly susceptible to Spectre, so that's not going to help. From https://meltdownattack.com https://meltdownattack.com: Almost every system is affected by Spectre: Desktops, Laptops, Cloud Servers, as well as Smartphones. More specifically, all modern processors capable of keeping many instructions in flight are potentially vulnerable. In particular, we have verified Spectre on Intel, AMD, and ARM processors.
  - lawrenceyan 9y ago
    Meltdown, however, is the one that results in nontrivial performance degradation in order to patch. And Meltdown specifically only affects Intel processors.
    - onedognight 9y ago
      Meltdown affects some ARM prcessors as well. https://developer.arm.com/support/security-update https://developer.arm.com/support/security-update
      - lawrenceyan 9y ago
        My response was in the context of privong stating that Intel and AMD were equivalently affected, when it is specifically Intel that suffers performance degradation in patching due to their unsafe usage of speculative execution.
        privong 9y ago
        I only said they were both affected by Spectre. But it wasn't clear if the OP was worried about performance issues or security issues, so it isn't clear on what basis they were suggesting that buying AMD is a solution.
    - noselasd 9y ago
      AMD is not susceptible to Meltdown. So the issue is not inherent to the x86_64 architecture. Knowing that, can it be possible that Intel can patch their CPU via micro-code in a manner that does not affect performance to a great degree, and not require a software patch to solve the Meltdown attach ?
- KirinDave 9y ago
  True for meltdown, not for spectre.
- sounds 9y ago
  Specifically buy an AMD Ryzen: https://www.amd.com/en/corporate/speculative-execution https://www.amd.com/en/corporate/speculative-execution Ryzen is only affected by "Spectre variant one, Bounds Check Bypass" It's fixed by OS updates with negligible performance impact expected.
- xioxox 9y ago
  How common is the Linux segfault problem on Ryzen now? Just reading about the horrible RMA procedure puts me off AMD unless they can clean up their terrible handling of this problem.
  - paulmd 9y ago
    It's still out there. To be clear, virtually no chips before Week 25 pass the segfault test, a large number of chips afterwards pass the segfault test. AMD clearly either upped their production standards or is binning out the worst chips. But there is still a baseline of chips failing. Some reported instances: https://community.amd.com/thread/215773?start=1635&tstart=0 https://community.amd.com/thread/215773?start=1635&tstart=0 (user jcoiner, 1726PGT) https://community.amd.com/thread/215773?start=1725&tstart=0 https://community.amd.com/thread/215773?start=1725&tstart=0 (user scorpio810, 2x 1728SUS) https://community.amd.com/thread/215773?start=1770&tstart=0 https://community.amd.com/thread/215773?start=1770&tstart=0 (user ryzlin, 1733PGT) https://community.amd.com/thread/215773?start=1785&tstart=0 https://community.amd.com/thread/215773?start=1785&tstart=0 (user flyinryzen1700, 1737SUS) https://community.amd.com/thread/215773?start=1830&tstart=0 https://community.amd.com/thread/215773?start=1830&tstart=0 (user skimba 1725PGT, user xtronom 1728PGT) https://community.amd.com/thread/215773?start=1860&tstart=0 https://community.amd.com/thread/215773?start=1860&tstart=0 (user jc_yang, 1742SUS) https://www.reddit.com/r/Amd/comments/76q7ne/got_a_defective_ryzen_7_1700_on_rma_process/dofye3u/ https://www.reddit.com/r/Amd/comments/76q7ne/got_a_defective... (user grosbof 1733SUS) https://www.reddit.com/r/Amd/comments/7ar15o/psa_amazon_is_still_selling_preweek_25_ryzens/dpc5iue/ https://www.reddit.com/r/Amd/comments/7ar15o/psa_amazon_is_s... (user triplesal, 1733PGS) https://www.reddit.com/r/Amd/comments/7ar15o/psa_amazon_is_still_selling_preweek_25_ryzens/dpcrkv0/ https://www.reddit.com/r/Amd/comments/7ar15o/psa_amazon_is_s... (user istockporno, 1726PGT) Presumably this is something that will be fixed in the Zen+ stepping/Pinnacle Ridge (Ryzen 2 - not to be confused with Zen2, which will release in 2019?, likely as the Ryzen 3 series). But for the meantime, be aware that you are absolutely buying silicon with known issues and that you should test it and RMA if necessary, and that there is fixed silicon coming within a couple months here that will probably run significantly faster due to process improvements.

glandium 9y ago

I thought they already provided a microcode update?

nickysielicki 9y ago
Latest version on downloadcenter.intel.com is 20171117; no microcode update has been published since Spectre/Meltdown have been disclosed. edit: see below, not true; they haven't published it on their own site but have pushed microcode updates to redhat.
- kzrdude 9y ago
  There's a partial update package debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=886367#22 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=886367#22 Seems to be taken from redhat updates. It's floating around unseriously in debian unstable instead of being a security update, I guess Debian's FOSS imperative doesn't mix so well with non-free (intel-microcode) updates. > Anyway, uploading a partial, unofficial set of updates to unstable to close the bug. Several processors are still missing. I expect an official release from Intel soon, hopefully with updates for everything. > Implements IBRS and IBPB support via new MSR (Spectre variant 2 mitigation, indirect branches). Support is exposed through cpuid(7).EDX. > LFENCE terminates all previous instructions (Spectre variant 2 mitigation, conditional branches).
- muppetman 9y ago
  Found via @grsecurity about 15 minutes ago: https://downloadcenter.intel.com/download/27431/Linux-Processor-Microcode-Data-File?product=122139 https://downloadcenter.intel.com/download/27431/Linux-Proces...
- deleted 9y ago
  [deleted]
- deleted 9y ago
  [deleted]

y3sh 9y ago

At what performance cost?

dooglius 9y ago

If Intel knew about the issues on June 1, why are the patches only appearing now? I thought the point of an embargo was to let the fixes come first.

dm319 9y ago
It was meant to be embargoed til today, but the news came out earlier than expected. Sounds like people have been working round the clock since the discovery to patch this.

maltalex 9y ago

How does one patch a CPU? Does the update come in the form of a BIOS update? If so, then the patch still has to travel through the PC manufacturers, like when Google patches Android. Or can it be somehow applied directly? Edit: Apparently the OS can update the CPU's microcode. No need for BIOS updates. It was even done in the past. For instance, an unrelated Windows Vista update that updates microcode: https://support.microsoft.com/en-us/help/936357/a-microcode-reliability-update-is-available-that-improves-the-reliabil https://support.microsoft.com/en-us/help/936357/a-microcode-...

nickysielicki 9y ago
https://wiki.debian.org/Microcode https://wiki.debian.org/Microcode The real news here is that Intel thinks they can fix this via microcode. This is surprising because initially there were some strong arguments that this wouldn't be possible.
- maltalex 9y ago
  Yeah, well, let's not break out the champagne yet. According to your link: > The BIOS (or UEFI) updates the CPU microcode during boot, however most of the time either the motherboard vendor won't issue frequent BIOS/UEFI updates, or the user won't install such updates. For these reasons, the system processor is likely to be running with outdated microcode on a vast number of systems. We still need the various manufacturers to release a BIOS version for a bunch of hardware they manufactured years ago. I'm not sure that's going to happen, at least not quickly.
  - herpderperator 9y ago
    Microcode is updated by OSes as well as BIOSes. I explained this in a previous thread: https://news.ycombinator.com/item?id=16075376 https://news.ycombinator.com/item?id=16075376
    - zerocrates 9y ago
      Microsoft is still saying that users need firmware/BIOS updates to be protected. Their messaging is at best confusing on this if they're going to apply microcode updates themselves. In the early days after disclosure at least, a BIOS/firmware update for my machine (from Dell) was required to provide the necessary hardware support for their branch target injection mitigation. As far as I can tell, that's still the case today. Perhaps they're waiting for the updates to be available for more processors before pushing an update?

jokoon 9y ago

I wonder what will the next big security hole. I'm becoming very pessimistic about how I can trust computers. Computers can do amazing thing, but software seems fragile, unreliable and untrustworthy. I have been keeping notes on paper for years now, and it doesn't look like it's going to change.

sigmar 9y ago
Internet-connected computers are more secure now than they ever have been. Just take the standard precautions: update your OS and don't install untrusted apps.
- jacquesm 9y ago
  And do not visit untrusted webpages with javascript enabled? And how do you know which pages you can trust?
  - flukus 9y ago
    Even trusted webpages pull in crap from all sorts of places that I don't trust, the way the web is structured is a disaster. My public news provider for instance (http://www.abc.net.au/news/ http://www.abc.net.au/news/) has all sorts of shit broken when you run ublock or noscript. There "live breaking news feeds" that are rather important may as well be a blank page because it just reposts twitter messages. And they're one of the better sites with no advertising.
  - pstuart 9y ago
    They'll tell you if they're ok. /s
- jokoon 9y ago
  I think it's actually the opposite. Internet is still growing, and so is the computer security economy. Look at all the data breaches and leaks.
wott 9y ago
It's been a while I don't bother much about security any more, because I consider everything insecure. So I just do not put all my eggs in the same basket, I do not store much personal information on my computer, I store even less online, I do not store any money/payment related information, and I just admit I will however sometimes get my butt kicked here or there. It is like my house. Anyone can break in at any time, and steal my belongings. Do I install an armoured door? Do I build grids on windows? Do I install an alarm with a direct link to a security company? No, no, and no. I just lock my front door. It only protects from a part of opportunity robberies and that's enough for me. I won't take measures to prevent all other possibilities. They can happen at any time, with no difficulty. And so what? Back to computers. So this very basic mitigation, very limited damage control is enough to make me feel OK. It feels better to admit insecurity as a given, than to constantly fight for a false feeling of security I cannot achieve anyway.

dm319 9y ago

Surely he is talking about the Win/Mac/Linux kernel patches? Would seem bizarre for all the work to go on the kernels when Intel had some firmware patches up their sleeve? Also I thought Spectre is something that is unlikely to be patched in the near future.

rocqua 9y ago
I believe there are microcode patches that help make spectre harder. I also have a vague recollection of the fix for meltdown on the newest CPUs requiring a microcode patch for complete protection.
deleted 9y ago
[deleted]

dmitrygr 9y ago

Keep in mind, they did NOT say patches with no cost. Mostly they are adding ways to disable speculation on indirect branches. This has a cost.

maltalex 9y ago

Any guesses as to which vulnerabilities they're going to patch? Some of them? All of them?

pizlonator 9y ago
Just the indirect branch bug. That’s “half” of Spectre. IMO the harder to exploit half.

bcantrill 9y ago

This is only Spectre, not Meltdown. Meltdown requires KPTI, which depends on your OS. For OSs that did not enjoy months of advanced disclosure (which is: any OS that isn't Windows, MacOS or mainline Linux), that work is ongoing and will depend on the OS. (Speaking for SmartOS/illumos, that work is reasonably far along and making promising progress -- but we don't yet have a functional prototype.) As for Spectre, these are just the microcode updates that have the additional MSRs that allow system software to mitigate certain variants of Spectre attack against the system software itself. They are necessary, but emphatically not sufficient -- and it would disingenuous for Intel to pretend that this in any way means that 90% of systems are protected from Meltdown and Spectre.

cryptonector 9y ago
What's the story for Illumos as to Meltdown and Spectre? I expect KPTI for Meltdown and then the same disable-speculation-for-indirect-call-in-kernel fix that everyone else is applying. With KVM the Illumos hypervisor should be free of attack, so maybe Joyent needs nothing more. EDIT: thanks for the update (or did I misread earlier?).
shirian 9y ago
For reference, I received this email before today: By now, we're sure most everyone have heard of the Meltdown and Spectre attacks. If not, head over to https://meltdownattack.com/ https://meltdownattack.com/ and get an overview. Additional technical details are available from Google Project Zero. https://googleprojectzero.blogspot.com/2018/01/reading-privileged-memory-with-side.html https://googleprojectzero.blogspot.com/2018/01/reading-privi... The FreeBSD Security Team was notified of the issue in late December and received a briefing under NDA with the original embargo date of January 9th. Since we received relatively late notice of the issue, our ability to provide fixes is delayed. Meltdown (CVE-2017-5754) ~~~~~~~~~~~~~~~~~~~~~~~~ In terms of priority, the first step is to mitigate against the Meltdown attack (CVE-2017-5754, cited as variant 3 by Project Zero). Work for this is ongoing, but due to the relatively large changes needed, this is going to take a little while. We are currently targeting patches for amd64 being dev complete this week with testing probably running into next week. From there, we hope to give it a short bake time before pushing it into the 11.1-RELEASE branch. Additional work will be required to bring the mitigation to 10.3-RELEASE and 10.4-RELEASE. The code will be selectable via a tunable which will automatically turn on for modern Intel processors and off for AMD processors (since they are reportedly not vulnerable). Since the fix for Meltdown does incur a performance hit for any transition between user space and kernel space, this could be rather impactful depending on the workload. As such, the tunable can also be overridden by the end-user if they are willing to accept the risk. Initial work can be tracked at https://reviews.freebsd.org/D13797 https://reviews.freebsd.org/D13797. Please note this is a work in progress and some stuff is likely to be broken. Spectre (CVE-2017-5753 and CVE-2017-5715) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ When it comes to the Spectre vulnerabilities, it is much harder to sort these out. Variant 1 (CVE-2017-5753) is going to require some static analysis to determine vulnerable use cases that will require barriers to stop speculation from disclosing information it shouldn't. While we haven't done the analysis to determine where we are vulnerable, the number of cases here are supposed to be pretty small. Apparently there have been some Coverity rules developed to help look for these, but we are still evaluating what can be done here. The other half of Spectre, variant 2 (CVE-2017-5715) is a bit trickier as it affects both normal processes and bhyve. There is a proposed patch for LLVM (https://reviews.llvm.org/D41723 https://reviews.llvm.org/D41723) that introduces a concept called 'retpoline' which mitigates this issue. We are likely to pull this into HEAD and 11-STABLE once it hits the LLVM tree. Unfortunately, the currently supported FreeBSD releases are using older versions of LLVM for which we are not sure the LLVM project will produce patches. We will be looking at the feasibility to backport these patches to these earlier versions. There are CPU microcode fixes coming out when in concert with OS changes would also help, but that's a bit down the road at the moment. If anything significantly changes I will make additional posts to clarify as the information becomes available. Best regards, Gordon Tetlow with security-officer hat on

guelo 9y ago

What I'm worried about is that it will be hard to avoid these security patches when you don't need them. Say you have a non-virtualized, non-shared server that only runs your own trusted code. I don't want to be forced to pay the performance penalty but it might be unavoidable without resorting to maintaining your own linux fork.

dakerfp 9y ago
that should be enabled by a boot flag
zorked 9y ago
What happens when your trusted code gets exploited? That's also the reason why we have overhead in the form of ACLs, memory protection, ASLR, packet filtering, deprivileged processes, seccomp sandboxes, etc. even though in principle we're all running "trusted code". Not saying that there isn't a scenario where it would be ok to turn that off, but it's the exception.
jacquesm 9y ago
Do you trust all of the userland? Is your machine internet connected? Do you have any open ports? Do you run everything as root? If your answers are yes, no, no, and yes than it likely will make no difference. Otherwise (and the last one is just for fun to attempt to show you this is probably not a wise decision) you probably would do better to take this serious.
- berkut 9y ago
  For private servers that are totally not connected to the internet in any way and don't need to be, run self-developed code on data which is mainly CPU-bound but also need a lot of disk IO for reading files and memory mapping data, I'm pretty certain it'll make a noticeable difference, for no security benefit.
  - appleflaxen 9y ago
    but isn't it pretty easy to avoid the security update on those machines?

zeep 9y ago

10% equals how many billions of chips?

donaldihunter 9y ago

https://support.apple.com/en-us/HT208394 https://support.apple.com/en-us/HT208394

flukus 9y ago

According to last weeks press release, they mean 90% of recent chips, which is far less than 90% of intel CPU's out in the wild: https://newsroom.intel.com/news-releases/intel-issues-updates-protect-systems-security-exploits/ https://newsroom.intel.com/news-releases/intel-issues-update... > Intel has already issued updates for the majority of processor products introduced within the past five years. By the end of next week, Intel expects to have issued updates for more than 90 percent of processor products introduced within the past five years It's also unclear what they mean by "introduced within" Does it mean when the product was first developed? First on sale? If I bought a new computer 3 years ago what is the likely-hood that it's CPU was "introduced" much earlier?

petascale 9y ago
Presumably the launch date, Intel lists launch dates for all of their processors on ark.intel.com [1] 5 years is Haswell, so Haswell and newer should get the microcode fix. A 3 year old computer is likely to have a CPU no more than 4 years old, but you can look it up to verify. (Both Windows and Linux can show the CPU model, and Intel's Ark site gives the release date.) [1] https://ark.intel.com/products/series/75023/4th-Generation-Intel-Core-i7-Processors https://ark.intel.com/products/series/75023/4th-Generation-I...
- flukus 9y ago
  Thanks. My work computer is in the legacy section (release Q4'11), so it looks like I might be getting a new one. A shame really, it's still mostly adequate, the only thing making it age are the continued bloat from Visual Studio.

lifeformed 9y ago

Have there been any reports of exploits using Meltdown/Spectre in the wild yet?

Tom4hawk 9y ago
https://meltdownattack.com/ https://meltdownattack.com/ > FAQ > Has Meltdown or Spectre been abused in the wild? > We don't know. So probably no reports ;)

kyledrake 9y ago

This is how this terrible CEO tells us about microcode fixes, at a CES speech? Or is he even talking about a microcode update, or about the patches everybody else has been losing their lives working on? What a crap response to such a huge and existential issue. Make a web page on the Intel site with concise, real information on what's going on and what to do. We're a week into disclosure and there's still no patch for most people's servers. A patch that takes up to a 30% performance hit but may not be necessary if there's going to be a microcode fix? I know this is just a cute speech and debate practice session for the Intel execs, but I have servers that will have to get trashed because of the slowdown patch, they will be too slow to function in their current role and will need to be replaced. This is seriously affecting my life, my work schedule and my wallet. Please have real engineers provide real information here.

sounds 9y ago
Let me break down what the article really says (it's pretty short): > He also said that Intel expects to issue updates > to its processors soon. More than 90 percent will be > getting them within the week, and the rest by the end > of January. Intel expects 90 percent will "get an update." 90 percent of what? It should be self-evident that Intel means 90 percent in whichever way gives them the largest percentage. I expect this means Intel discounts "older CPUs" that are "probably not in use." In other words, 90 percent of CPUs sold in the last N years for whatever N makes the percentage largest (5 years [1]) "The rest by the end of January" can be taken with a huge grain of salt. Intel is documenting and exposing an MSR to flush the [ed] branch predictor, but only for recent CPUs, and admits they aren't able to do so in a timely manner, or they would have said "100 percent." [1] https://newsroom.intel.com/news-releases/intel-issues-updates-protect-systems-security-exploits/ https://newsroom.intel.com/news-releases/intel-issues-update... "Intel has already issued updates for the majority of processor products introduced within the past five years. By the end of next week, Intel expects to have issued updates for more than 90 percent of processor products introduced within the past five years" Edit: I incorrectly stated the MSR was for the TLB, it is not. It is for the branch predictor.
- vardump 9y ago

deleted 9y ago

[deleted]

phkahler 9y ago

I half thought he was going to talk about using ME to push updates to Intel-based machines. Thank god they have a backdoor to fix security issues! ;-)

quadcore 9y ago

How do you patch a CPU remotely? Are the instructions programmable?

InclinedPlane 9y ago
CPUs have code that runs code, essentially. Think of a modern CPU as like a collection of micro-controllers. You have micro-controllers which reads a stream of machine code instructions for a particular instruction set (e.g. x86-64) translates that code into "micro-ops" (RISC-like fine grained instructions) that are then re-ordered and so forth and fired off into the CPU core(s) proper. That whole process relies on a ton of code that exists as essentially "firmware" (microcode) within the processor. Things like translation tables for architecture level instructions (x86-64) to micro-ops as well as code for the scheduler, the branch predictor, and various other micro-architectural parts of the CPU. Some of these elements are hardwired into the silicon, some are controlled via decode tables, and some are controlled via flags and perhaps even instructions running on different components of the CPU, all of that together is grouped under the heading "microcode". A modern CPU is not infinitely programmable because a lot of functionality is hardwired (for example, what each micro-op does) but there's still a great deal of flexibility in how things work (such as exactly how the branch predictor and scheduler work, the translation of instructions to micro-ops, etc.)