22 ms·

Intel Issues Updates to Protect Systems from Security Exploits

• discreditable 9y ago
  They don't explicitly say. Is part of this a microcode update?
  • userbinator 9y ago
    If it is (very likely, because only Intel can issue them thus far), they probably figured out how to turn off the branch predictor. The performance drop will still be there, but better than the "recompile everything to not use indirect jump and call instructions"[1][2], at any rate. [1] https://news.ycombinator.com/item?id=16066968 https://news.ycombinator.com/item?id=16066968 [2] https://news.ycombinator.com/item?id=16070050 https://news.ycombinator.com/item?id=16070050
    • mozumder 9y ago
      If it's a timing attack, they probably don't need to fully turn it off, but turn it off and on randomly every now and then..
      • Skunkleton 9y ago
        That wont do it. The true data will still bias the results.
        • mozumder 9y ago
          So, Google and Apple ended up reducing precision on their web browser timing APIs to mitigate this attack.
          • Skunkleton 9y ago
            Exactly. They never expose a timer of sufficient resolution. That is different from _sometimes_ exposing a timer of sufficient resolution.
        • emn13 9y ago
          Even this PoC was limited to 2000 bytes a second; even a little noise may well render the attack largely theoretical - or at least make the attack so slow as to make it feasible to use other (expensive) mitigations only very rarely. But yeah, it's not a brilliant solution. But it would help.
          • Skunkleton 9y ago
            Even one byte per minute would be enough to cause serious issues. Imagine if some add served up by a torrent site could read information from another tab rendered by the same process?
            • emn13 9y ago
              Not good, but still thousands of times better. And don't forget that you still need to guess where to read from, which better be a very very accurate guess at that rate. Making such an accurate guess is difficult when your runtime is as complex as a browsers, and so even without that extra timing noise no PoC exists (AFAIK?) attacking browsers. But you know... you're not wrong ;-). I'm just not particularly worried about the likelihood of this attack hitting anything I care about anytime very soon.
              • Skunkleton 9y ago
                Google does have a PoC for spectre that attacks Chrome via Javascript. That said, I am not super worried either. Its not like all my personal data isn't already out there for all to see (Thanks Equifax).
      • IncRnd 9y ago
        Side-channel timing attacks work on websites by executing MANY similar requests. In a similar way, in this case, while individual requests may not appear to adhere to a timing profile, over time they likely will still be discoverable. c.f. The random number generator in "The Mythical Man Month" that only guaranteed any one number will be random, not a sequence of numbers.
        • mozumder 9y ago
          Makes sense. But man these attacks really do need lots and lots of CPU just to extract one bit of data.
    • bpye 9y ago
      Seeing Intel's patches on LKML they seem to suggest that retoline is actually preferable over disabling the branch predictor [1] [1] https://docs.google.com/document/u/2/d/e/2PACX-1vSMrwkaoSUBAFc6Fjd19F18c1O9pudkfAY-7lGYGOTN8mc9ul-J6pWadcAaBJZcVA7W_3jlLKRtKRbd/pub https://docs.google.com/document/u/2/d/e/2PACX-1vSMrwkaoSUBA...
    • tomxor 9y ago
      > they probably figured out how to turn off the branch predictor. :P I hope the fix is this crude... the performance drop would be hilarious, Apple would probably switch back to PowerPC by the summer.
      • tomxor 9y ago
        Note: I was obviously being facetious, but It made me wonder how far back branch prediction goes not being a microarchitecture expert... Surprised to find even the old 68k utilises it! not that they necessarily suffer the same fate through the concept alone of course.
    • earenndil 9y ago
      > only Intel can issue them thus far I wouldn't bet on that lasting, though. This CCC someone essentially reverse-engineered microcode on 5-10 year old amd processors. I wouldn't be surprised if they figured out how to do it on newer processors and intel processors.
      • userbinator 9y ago
        Intel's microcode updates are signed by a 2048-bit RSA key and some unknown 160-bit hash function (might be SHA-1, but none one publicly knows) for older models, with newer ones using a 256-bit hash function. Unless there's a very clever exploit, I doubt third-party microcode updates will ever be possible: http://inertiawar.com/microcode/ http://inertiawar.com/microcode/
  • dzdt 9y ago
    Cloud vendor Scaleway reports that Intel has promised them a microcode update: https://blog.online.net/2018/01/03/important-note-about-the-security-flaw-impacting-arm-intel-hardware/ https://blog.online.net/2018/01/03/important-note-about-the-... "According to the latest update from Intel, a microcode is required to completely fix the bug. The microcode release date is, at this time, scheduled for an undisclosed confidential unacceptable late date"
  • mtgx 9y ago
    They say in the post that the updates are distributed by system makers.
• dtx1 9y ago
  > including personal computers and servers — that render those systems immune from both exploits (referred to as “Spectre” and “Meltdown”) reported by Google Project Zero. I thought you couldn't patch out Spectre
  • space_fountain 9y ago
    You can't in conventional software, this is almost certainly a microcode update. It remaining to see at what cost. This change may well just totally disable features that normally are heavily used in pipelining.
• 317070 9y ago
  > Intel has developed and is rapidly issuing updates for all types of Intel-based computer systems — including personal computers and servers — that render those systems immune from both exploits (referred to as “Spectre” and “Meltdown”) reported by Google Project Zero. Now I really wonder how they managed to patch both? Does someone know how you could patch something like that from Intel's side of things?
  • userbinator 9y ago
    https://en.wiktionary.org/wiki/chicken_bit https://en.wiktionary.org/wiki/chicken_bit The first example usage given there is very illustrative: As an example, modules such as branch predictors and speculative execution units can be turned off with a variant of the “chicken bits”, control bits common to many design developments to control the activation of specific features.
    • Ajedi32 9y ago
      I kinda doubt they'd be able to turn off branch prediction and speculative execution entirely and still be able to claim that > the performance impact of these updates is highly workload-dependent and, for the average computer user, should not be significant
      • joeyh 9y ago
        If your workload does not branch, no performance impact AND Average user's computer is mostly idle = Above intentionally misleading PR statement.
      • bsdetector 9y ago
        All they have to do is disable memory fetching during speculative execution so there's no side effects. That probably wouldn't affect performance much, and some unusual workloads might even get faster.
  • herf 9y ago
    Lenovo released a BIOS update[1] more than two weeks ago that mentioned CVE-2017-5715 (Spectre-related CVE). [1] https://support.lenovo.com/us/en/downloads/ds035965 https://support.lenovo.com/us/en/downloads/ds035965 for example
• chrisper 9y ago
  And how do I get these firmware updates and microcode updates on Windows? Checking AsRock, there aren't any Bios updates. Also: > Customers who only install the Windows January 2018 security updates will not receive the benefit of all known protections against the vulnerabilities. In addition to installing the January security updates, a processor microcode, or firmware, update is required. This should be available through your device manufacturer. Surface customers will receive a microcode update via Windows update. From: https://support.microsoft.com/en-gb/help/4073119/windows-client-guidance-for-it-pros-to-protect-against-speculative-exe https://support.microsoft.com/en-gb/help/4073119/windows-cli... (There is also a powershell script to check if you are protected fully or not)
  • Donald 9y ago
    Microcode updates are distributed via Windows update.
    • chrisper 9y ago
      But Microsoft says they are not: >In addition to installing the January security updates, a processor microcode, or firmware, update is required. This should be available through your device manufacturer. Surface customers will receive a microcode update via Windows update. https://support.microsoft.com/en-gb/help/4073119/windows-client-guidance-for-it-pros-to-protect-against-speculative-exe https://support.microsoft.com/en-gb/help/4073119/windows-cli...
      • markphip 9y ago
        If the microcode update requires motherboard vendors to issue BIOS updates we are all doomed.
        • deleted 9y ago
          [deleted]
        • evfanknitram 9y ago
          This appears to be the case at least on my Windows 10 laptop. I've installed the hotfix for Windows, but when I run the PowerShell script to determine whether mitigation is active, the script tells me that it's not active, due to lack of hardware support. The script then goes on to give the recommendation to "Install BIOS/firmware update provided by your device OEM that enables hardware support for the branch target injection mitigation." It's a 1-year-old ASUS laptop and I would be surprised if they even give a sane response to my question to their technical support (I doubt they will even know what I'm talking about).
• carwyn 9y ago
  They are still sticking to this line: "This is not a bug or a flaw in Intel products. These new exploits leverage data about the proper operation of processing techniques common to modern computing platforms, potentially compromising security even though a system is operating exactly as it is designed to." https://www.intel.com/content/www/us/en/architecture-and-technology/facts-about-side-channel-analysis-and-intel-products.html https://www.intel.com/content/www/us/en/architecture-and-tec...
  • swsieber 9y ago
    Well, that's true (at least for the spectre attack). It's not a bug in Intel products. It's a bug in any CPU that uses branch prediction (please correct me if I'm wrong, this is my current understanding)
    • bad_alloc 9y ago
      IF the bug is present in all processors that use speculative execution AND Intel products use speculative execution THEN it is a bug in Intel products. It would only be correct to say "This is not a bug or a flaw exclusive to Intel products"
    • betterunix2 9y ago
      The effect on Intel is far more severe than on other architectures. There were three vulnerabilities, two grouped together as "spectre" and one called "meltdown." Intel products are uniquely vulnerable to the meltdown attack, while many CPUs are vulnerable to spectre. The summary AFAIUI is that for most CPUs you can attack userspace processes with these techniques (think Javascript running in a browser), while for Intel CPUs you can also attack the kernel. Intel CPUs also seem to be somewhat easier to attack than others because of a higher-bandwidth side channel.
      • Symmetry 9y ago
        A minor correction, ARM's upcoming A75 core looks like it will be vulnerable to Meltdown too. But since it isn't intended for use on server workloads the performance impact of the fix shouldn't be very significant.
• bpye 9y ago
  It looks like they expose some MSR to control the branch predictor, see: https://twitter.com/aionescu/status/948753795105697793 https://twitter.com/aionescu/status/948753795105697793 https://twitter.com/aionescu/status/948818841747955713 https://twitter.com/aionescu/status/948818841747955713
  • cws125 9y ago
    It appears the retpoline fixes don't work in Skylake or later (it's smart enough to speculate out of it?) and will require new support for IBRS/IBPB in the microcode to mitigate. From: https://lkml.org/lkml/2018/1/4/615 https://lkml.org/lkml/2018/1/4/615
    • bpye 9y ago
      Seems that the new MSR results in worse perf than the retoline which is alarming. https://docs.google.com/document/u/2/d/e/2PACX-1vSMrwkaoSUBAFc6Fjd19F18c1O9pudkfAY-7lGYGOTN8mc9ul-J6pWadcAaBJZcVA7W_3jlLKRtKRbd/pub https://docs.google.com/document/u/2/d/e/2PACX-1vSMrwkaoSUBA...
    • cesarb 9y ago
      Interesting: > Note: IBRS is not required in order to isolate branch predictions for SMM or SGX enclaves Perhaps this microcode update exposes a feature which was originally to protect these two modes? But that would mean that Intel did think about leaks through the branch predictor, only didn't make the logical leap that this could be an issue also for normal ring0/ring3...
      • contrarian_ 9y ago
        Huh, so did Intel know about this vulnerability when they designed SGX?
        • pritambaral 9y ago
          Maybe, maybe not. I looked around a bit and found [1]"that the Intel SGX does not clear branch history when switching from enclave mode to non-enclave mode", which suggests either that the SGX designers were unaware of the dangers of not separating branch prediction between privilege levels, or that Intel intentionally weakened SGX so as to not reveal the similar flaw in their ring0/ring3 separation. 1: https://arxiv.org/abs/1611.06952 https://arxiv.org/abs/1611.06952 (Nov '16)
• lower 9y ago
  Lenovo has BIOS updates that specifically mention CVE-2017-5715 (Spectre). I wonder if this is an Intel microcode update. https://pcsupport.lenovo.com/de/en/products/laptops-and-netbooks/thinkpad-t-series-laptops/thinkpad-t470/downloads/ds120429 https://pcsupport.lenovo.com/de/en/products/laptops-and-netb...
  • reirob 9y ago
    For those like me are running Linux and asking how to update the BIOS, lenovo provides a ISO file. Quoting from [1]: "The BIOS Update CD can boot the computer disregarding the operating systems and update the UEFI BIOS (including system program and Embedded Controller program) stored in the ThinkPad computer to fix problems, add new functions, or expand functions as noted below." [1]: https://support.lenovo.com/fr/en/downloads/ds120430 https://support.lenovo.com/fr/en/downloads/ds120430
    • duozerk 9y ago
      Yeah, basically all BIOS have that. Some simply need a FAT usb key inserted with a specifically-named file that the BIOS looks for instead of a "true" bootable media.
    • confounded 9y ago
      I wonder what this means (if anything) for machines running Coreboot.
• mtgx 9y ago
  They will update 90% of the chips 5 years old or newer, which I assume includes Ivy Bridge and later. But the bug affects older chips, too. Important to keep that in mind.
  • frandroid 9y ago
    I don't know why you're being downvoted; it's crucial that Intel patches this deficiency for all CPU models which are currently in use, which is pretty much all of them, since some systems work nearly forever. We're talking about going back 15 years or so? I mean this is like the Y2K bug, in that every system needs to have its CPU verified to ensure that it's covered by the patches, otherwise the system should be shut down and a new CPU provided. Since many of these CPUs have sockets for which CPUs are not produced anymore, whole new systems will have to be purchased. Of course this might the result Intel wants to achieve.
    • frou_dh 9y ago
      I imagine most laptop and motherboard vendors have precisely zero interest in locating/dusting-off whatever toolchains are required to mint new BIOSes for long discontinued products.
  • mlvljr 9y ago
    And who of you lads downvoted this?
  • benjaminl 9y ago
    The actual quote is: > 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. The post is silent on what will be done with older chips, it didn't say that they are not going to be updated. It makes sense that Intel prioritizes the newer chips.
    • ddebernardy 9y ago
      It makes sense but 5-10 year old laptops aren't uncommon nowadays. Had this occurred 20 years ago nobody would have cared because computers would get replaced super fast anyway. Nowadays, even a geeky household can have 5+ year old CPUs lying around and still used.
• deleted 9y ago
  [deleted]
• cultureulterior 9y ago
  Has anyone written anything on how process affinity would help with Spectre/Meltdown?
  • blattimwind 9y ago
    The attacks require co-scheduling with the address space (thread/process) to be attacked. So, exclusive process affinity is a working mitigation against these attacks and other per-core micro-architectural attacks.
    • zeotroph 9y ago
      Using a thread to keep mispredicting as desired is just one (though faster) possibiliy. It can be done in single threaded mode as well. Also doing that on purpose would again worsen cache performance.
• crimsonalucard 9y ago
  noob question here. Why isn't normal data readable? Why is only predicted branch executions readable?
  • xigency 9y ago
    In at least one of the variants, I believe that the branch predictor is primed in the attacker program with some value, say 0x00ABCDEF by jumping there consistently in certain circumstances. Then the CPU switches to running another program that is allowed to access different memory. The CPU encounters a branch and predicts that it will land at 0x00ABCDEF and begins running attacker code briefly. Since it's working on the victim program, the code can access the victim program's data. After several cycles the CPU realizes it made the wrong prediction and NOPs out all of those instructions. However, the malicious code stores its results by shuffling things on the cache, which aren't rolled back because the CPU doesn't consider that to be nominal. Therefore, the exploit can access memory from other programs. This is my limited understanding of Spectre. Reading the white paper, it must be much more complicated. Apparently the CPU would normally stop accesses even speculatively when running from the malicious program (except for Meltdown, where it doesn't even stop that).
    • zeotroph 9y ago
      No, Spectre can only read its own memory, which makes it boring for programs, but interesting for stuff running interpreted code because it can suddenly peek outside, e.g. javascript. Meltdown goes one step further in that it can read kernel memory (but not memory of other processes either, unless it was explicitly mapped in).
      • deleted 9y ago
        [deleted]
      • pubby 9y ago
        Spectre allows one process to extract the memory of another process (assuming certain conditions are met). I would not call that boring.
• Taniwha 9y ago
  I wonder if an optional microcode update disabling usermode access to cache flush and rdtsc instructions would make it impossible to do the low level timings required to make the measurements (of course it would break other stuff, but maybe being able to enable these process by process might be appropriate)
  • bpye 9y ago
    There is already a mechanism to disable rdtsc in CR4, I don't know that it's used by anything though
    • Taniwha 9y ago
      I think that the intent of that was for virtualisation (before we had real virtualisation)
  • Taniwha 9y ago
    thinking about it more a patch that masks out (or sets) the N LSBs of the value returned to user space accesses to rdtsc might do the trick, it wouldn't break anything, and time would still be monotonic The recent CCC paper on how to write your own microcode (for AMD CPUs) means that AMD owners can actually experiment with a fix of this on their own CPUs ... now if only Intel would let us hack the microcode on our own CPUs too ....
    • bennofs 9y ago
      Just masking the lower bits is not enough: you can easily reconstruct a high-precision timer from that by observing the clock edges (waiting until rtdsc increases): wait for clock edge, do your experiment, increase counter until next clode edge in busy loop. the counter now correlates strongly with the amount of time taken for the experiment. Also, while cache flushes are the easiest way to trigger this, I am not convinced that there aren't other ways to do it. For example, you could attempt to clear the cache by spamming it with new data to cache, or you could try to use one of the other sidechannels (I've seen ALU ports being mentioned as one alternative: instead of accessing cache lines, you do some heavy math operations that will cause the ALU ports of the cpu to be used and then you observe how long ALU operations take in userspace)
• gaius 9y ago
  It’s interesting to see what companies choose to work on instead of security. With Intel it’s speed, with Apple it’s the animated poop icon.
  • donarb 9y ago
    Like Intel didn't spend tons of money over the past 20 years on TV commercials playing a unique set of musical tones to convince you to buy a computer with a flawed chip inside.
    • softawre 9y ago
      > inside
  • evilduck 9y ago
    Apple fixed the KPTI bug in 10.13.2 which they released over a month ago.
• oh-kumudo 9y ago
  Any idea how would they fix Spectre with this update? Or tries to make it harder to exploit?
• chrononaut 9y ago
  > that render those systems immune from both exploits (referred to as “Spectre” and “Meltdown”) The language used seems to imply that they have patched all three identified vulnerabilities. Is it possible that if this update is applied to a system running an unpatched Linux kernel on an Intel CPU that the system is no longer vulnerable to Meltdown? Or does this microcode update complement work done by the kernel developers implementing KPTI as well as by the browser developers mitigating some portion of Spectre? (My initial take is that the efforts by CPU manufacturers and OS/Software developers are orthogonal to provide better coverage to affected parties, such as those on CPUs where no update exists yet)
  • space_fountain 9y ago
    I'd also be interested in an answer here. Right now it seems like this might even just add support for OS vendors and software developers to mitigate this down the road by selectively disabling pipelining features in their code or at least that's what I'm reading seems to imply.
  • gcbirzan 9y ago
    https://newsroom.intel.com/wp-content/uploads/sites/11/2018/01/Intel-Analysis-of-Speculative-Execution-Side-Channels.pdf https://newsroom.intel.com/wp-content/uploads/sites/11/2018/... - basically, you need software updates for variant 1 and 3, and both software and microcode update for 2 for certain CPUs. Bullshit doesn't even begin to describe that sentence...
• swasheck 9y ago
  So just to be clear, I'd need to install the OS patch as well as the OEM update (to BIOS? Processor?) in order to mitigate both Meltdown and Spectre. Additionally, how does this interact with VMs? It makes the most sense to me that I'd need to microcode patch the hosts, but what about the guests?
  • tomxor 9y ago
    > Additionally, how does this interact with VMs? It makes the most sense to me that I'd need to microcode patch the hosts, but what about the guests? microcode is for the physical CPU, it is ultimately stored in on die volatile memory in CPU. microcode can be delivered to the CPU on boot by the BIOS/UEFI (stored in it's firmware) and/or by the host OS on boot (doesn't even matter what the OS is, windows, linux etc), this is secure because microcode is cryptographically signed. As for software, the OS kernel and hypervisor patches for VMs... From everything that has been said so far, it sounds like these bugs can't be solved entirely in microcode, so software patches are needed as well i believe. [amended for correctness as per child comments]
    • bayindirh 9y ago
      IIRC uCode updates are volatile. You re-install them to CPU on every boot. OS actually does this for you.
      • burnte 9y ago
        You are correct. uCode is installed by the BIOS, and then again later by the OS if there's more recently updated code.
        • tomxor 9y ago
          Out of interest, do you know if the process of uploading the microcode via the OS independent of the BIOS? ... e.g on something with an unusual boot ROM like a mac or a Pi (pretend it had an x86) would the kernel not care? i.e it's just a CPU instruction?
• bitL 9y ago
  Can we avoid Windows 10 update? Frankly, I don't want to have my gaming & machine learning rigs slowed down (whatever you may say about negligible impact) and would like to opt out of this update on some of my systems. Is it possible? Or am I forced to just waste at worst 30% of my CPU cycles on mitigating this issue, even if my computer never gets into browser for more than a few seconds on very specific trusted domains?
  • esMazer 9y ago
    I have no idea when people started saying is a 30% hit on the cpu! In reality is average of <=5% : https://www.reddit.com/r/pcgaming/comments/7o2ctw/benchmarked_intel_security_patch_impact_on/ https://www.reddit.com/r/pcgaming/comments/7o2ctw/benchmarke... EDIT: found it! 5-30% as reported by theregister : https://www.theregister.co.uk/2018/01/02/intel_cpu_design_flaw/ https://www.theregister.co.uk/2018/01/02/intel_cpu_design_fl...
    • the8472 9y ago
      That's just the PTI fix. On top of that runtimes recompiled with the retpoline. The question is whether the microcode update contributes an additional slowdown once used or makes the other mitigations cheaper.
  • bennofs 9y ago
    These patches should only affect syscall entry/exit performance. So if you're not doing things that do enormous amounts of syscalls, you should be more at the 3% end of the scale. The 30% number comes from doing things like calculating the file sizes of a directory with a lot of very small files, where the performance overhead of a single syscall matters. In most performance sensitive applications like games, you probably won't see any syscalls in a hot loop since that'd be too slow anyway. Even if you're doing heavy IO, then that is most likely also done in batch and blocked on disk IO speed, not on syscall overhead.
    • bitL 9y ago
      There are reports on Reddit that NVidia's driver is affected due to heavier usage of patched functionality which would mess with both gaming and Deep Learning. In both, 5-10% drop is pretty unacceptable as that is often basically performance offset to lower-tier card (e.g. non-Ti vs Ti card).
• lifeformed 9y ago
  If it was kept secret, what would the value of this zero day exploit have been on the black market?
  • beamatronic 9y ago
    This is a fantastic question and should be higher.
    • Sohcahtoa82 9y ago
      This isn't reddit. Written upvotes like this are highly frowned upon.
      • thiagocsf 9y ago
        I like your username.
  • kakarot 9y ago
    I'd be surprised if Meltdown was worth less than $2B. And I wouldn't be surprised if it was worth over $100B. Of course that is raw value, however in practice it would be EXTREMELY hard to launder such a large amount of money into and out of an online transaction. The question then becomes, what kind of person is the hacker? Are they in a position where they can wait and find a good deal or would they rather wash their hands of it over $100M or so?
    • tomschlick 9y ago
      For this kind of exploit, I don't think you'd have to worry about the transaction. The NSA/(insert spy agency here) would gladly send a truck full of cash to your house for it (assuming they didn't know about it already).
      • PuffinBlue 9y ago
        I like to think the NSA/TLA folks are sitting in an office somewhere incredulous that someone found this bug they'd never have even dreamed up, whilst a catalogue of simple buffer overflows and mandated backdoors that no one has yet found sits on the shelf ready for offensive use.
• mtgx 9y ago
  I wonder what Linus thinks about all of this. Does he still believe this is no different than a random UI bug, as he used to say not too long ago about security bugs?
  • colonelpopcorn 9y ago
    He's pretty pissed, actually. https://lkml.org/lkml/2018/1/3/797 https://lkml.org/lkml/2018/1/3/797
    • code_duck 9y ago
      I think that only scratches the surface of pissed for Linus. He barely even swore.
  • pixl97 9y ago
    You missed the Linus post where he said Intel should stop selling shit processors I see.
• bluefox 9y ago
  So this was reported half a year ago and only now after publication Intel releases updates?
  • chrisper 9y ago
    The Embargo was until January 4th.
• beamatronic 9y ago
  I just did a "sudo yum update" on CentOs and I see a slew of firmware/microcode packages. Are these security patches ready to go already?
• tasty_freeze 9y ago
  I'm disheartened by the number of comments here who are taking the stance that Intel has idiot designers or that management doesn't care about security. This attack is very clever and unexpected. Even though side-channel attacks have been talked about for awhile, even the guy who developed Meltdown was surprised that it worked. It just seemed like an "in theory" security hole, not an exploitable one. AMD isn't vulnerable to Meltdown not because they foresaw this issue, but probably because they simply weren't as aggressive as Intel in allowing speculative execution. For years people have preferred Intel over AMD cpus due to their performance advantage, due in part to that higher sophistication of their pipeline. Or to recast it, nobody is hating on AMD right now, but AMD CPUs do allow a user process to learn some things about the kernel via timing attacks. If next month a researcher develops Meltdown2 for AMD, are AMDs designers now suddenly idiots for missing an obvious security hole?
  • mellow_ 9y ago
    I mean... yes? Why would it be any different?
  • lawrenceyan 9y ago
    AMD did things the right way competing for performance without sacrificing security. What's happening right now are the consequences of Intel's actions.
    • chirau 9y ago
      I think you are missing the point. What the commenter is saying is this... right now you are saying AMD did things the right way, but if a loophole is exposed next month, will you say the same thing? I'm neither supporting or refuting the commenter. Just explaining to you the meaning of the comment.
    • thecompilr 9y ago
      AMD did things the "right" way, not because they understood the security implication, but because it was very hard to achieve such high level of speculation, and I think the performance gains didn't justify the effort for them.
• orblivion 9y ago
  Oh nice. I know the average user is going to go right ahead and update their CPU microcode.
  • mrunseen 9y ago
    whats wrong about it? im gonna buy new laptop and it will be intel powered (dont kill me noob at intel cpus)
    • orblivion 9y ago
      I'm not sure I'm following you, but I'm saying they're releasing a fix, as if that really deals with the problem. How many people are actually going to install the fix? How many people out there even know about these issues? Going forward there need to be easy ways to update all of this stuff. These flaws won't stop coming out. It would be great if they got installed with OS updates, but I can understand if there's a security problem there.
      • angelsl 9y ago
        Microcode updates are distributed as OS updates.
        • orblivion 9y ago
          Maybe I'm using big words I don't understand. What is it that Lenovo and such are distributing as part of this? I know they're labeled as BIOS updates but I assumed it's more than that since the BIOS is a different component. EDIT: So looking into it, it seems that CPU microcode is indeed the firmware, and I presume that the firmware is where a fix such as the one released here would be. Somebody mentioned a Lenovo update elsewhere in comments. The recent ME updates required an update from Lenovo. I assumed the same would apply here but thankfully not. I wonder why the OS can't update ME firmware the same way.
          • AnssiH 9y ago
• ahmgeek 9y ago
  I can say developers are the new type of whores, except we rent our brains, not our holes. But the guys behind intel rented there butt hole tho..
  • sctb 9y ago
    This type of comment doesn't belong on Hacker News. Could you please re-read the guidelines and post civilly and substantively instead? https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
• m3kw9 9y ago
  Funny that nowhere to be found: the actual link to the fix and how to patch it.
  • mathpay 9y ago
    Indeed, the latest linux microcode package has yet to be updated: https://downloadcenter.intel.com/download/27337/Linux-Processor-Microcode-Data-File?product=873 https://downloadcenter.intel.com/download/27337/Linux-Proces... . Are they shipping specific CPU fixes to vendors first before updating the full package?
• dreamcompiler 9y ago
  These exploits are the result of the games we play to get high performance when memory is slow but processors are fast (speculative execution; caches). It's time to figure out how to make RAM dense, cheap, AND fast, so we can finally eliminate the cache layer from the ridiculous hierarchy of storage technologies.
  • mort96 9y ago
    It will take a LONG time before we have tens of gigabytes of memory running with the same bandwidth and latency as L1 cache. According to a StackOverflow question [1], an L1 cache hit takes just over 2 nanoseconds, while RAM takes upwards of 100 nanoseconds. [1] https://stackoverflow.com/questions/4087280/approximate-cost-to-access-various-caches-and-main-memory https://stackoverflow.com/questions/4087280/approximate-cost...
  • elihu 9y ago
    I don't think that's realistic; registers and SRAM are a lot more expensive than DRAM and consume a lot more power. I think having some combination of fast, expensive RAM and slow, cheap RAM in any system larger than a tiny microcontroller is just a fact of life. A different way to attack this problem is to make timing attacks harder by disallowing programs from reading the current time or inferring the passage of time by monitoring non-deterministic interactions between threads. Pure Haskell code (i.e. code that runs outside the IO monad) is an example of an execution environment that conceals timing from the running code. There are certain kinds of problems that aren't amenable to running in a completely side-effect and non-determinism free sandbox, but maybe for some applications it's a viable solution.
  • ahh 9y ago
    Flops are cheap. Bandwidth is expensive. Latency is physics. We aren't at full lightspeed latencies ram technologies, but we're closer than you may realize, and it's unlikely we can do substantially better any time soon without revolutionary advances.
    • dreamcompiler 9y ago
• dreamcompiler 9y ago
  It's easy to fix Meltdown with a microcode update. Do we know if Intel (or AMD or ARM for that matter) are also attempting to fix Spectre? Spectre seems much more difficult.
• BuildTheRobots 9y ago
  I noticed a microcode update which was expected, but there's also been firmware updates for Intel WiFi cards - which I wasn't expecting. I don't suppose anyone can comment on why the WiFi update?
  • AnssiH 9y ago
    AMD CPU microcode is contained in the linux-firmware package/repository ( https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/amd-ucode https://git.kernel.org/pub/scm/linux/kernel/git/firmware/lin... ) which also contains Intel WiFi card firmware. So if your Linux distribution provides a new release of linux-firmware package, you may get new versions of WiFi firmware packages as well with no actual changes to those. This seems to be the case with at least RHEL: https://access.redhat.com/errata/RHSA-2018:0015 https://access.redhat.com/errata/RHSA-2018:0015 The RHEL linux-firmware update contains an AMD microcode update that involves Spectre mitigations. AMD microcode is mentioned at https://access.redhat.com/articles/3311301 https://access.redhat.com/articles/3311301 and the linux-firmware package changelog says: * Wed Dec 27 2017 Rafael Aquini <aquini@redhat.com> - 20170606-57.gitc990aae - Add amd-ucode for fam17h (Intel CPU microcode is part of microcode_ctl package, updated separately)
    • BuildTheRobots 9y ago
      Thank you very much for the response; I didn't realize RHEL would every version-bump a package without anything actually changing! For the sake of my own sanity, i tested the iwlwifi-1000 firmware package iwl1000-firmware-39.31.5.1-57 and "-58" and can see no changes when hashing the files.
• illumin8 9y ago
  Why did CERT modify their vulnerability disclosure to remove the text: > Fully removing the vulnerability requires replacing vulnerable CPU hardware. Proof: https://webcache.googleusercontent.com/search?q=cache:rzc6iQmgrIcJ:https://www.kb.cert.org/vuls/id/584653+&cd=4&hl=en&ct=clnk&gl=us https://webcache.googleusercontent.com/search?q=cache:rzc6iQ... This smells really bad to me, as if Intel pressured CERT into removing language that could have caused their market value to instantly vaporize as every consumer for the last 20 years joins a class action suit...
  • deleted 9y ago
    [deleted]
  • weavejester 9y ago
    It could just be that the statement is incorrect or misleading.
    • tbodt 9y ago
      Yes. Spectre2 can be and is being patched with a microcode update that partially disables branch prediction.
      • wasx 9y ago
        What about meltdown?
        • anifal 9y ago
          Meltdown is mitigated by kernel page table isolation. See patch notes/ the attack paper
          • geezerjay 9y ago
            That says nothing about the need to fully replace defective hardware to avoid the hardware problem.
• ConcernedCoder 9y ago
  I see quite a bit of back and forth around Intel vs. AMD when it comes to Engineers, Architectures and so forth... even some 'name calling' if you will, around AMD architectures being 'too dumb' to be vulnerable to this type of attack. What ever happened to the mantra of Keep It Simple Stupid?
• narrator 9y ago
  So is this the first year that computers will actually get slower vs. the year before?
  • leni536 9y ago
    Yeah, also it's not about new computers. It's a huge portion of all existing computers. Even my 10 years old Core 2 Duo laptop will get slower after I update it (I'm not too happy about it).
• dmateos 9y ago
  With these fixes and the performance losses, does that stack? IE if you have a Server on amazon running a newer kernel with the patches but then that underlying hardware is also running the newer kernel?
• fulafel 9y ago
  I wonder if the terminology of blocking specific exploits vs fixing vulnerabilities is intentional. Even the "facts" page consistently uses "these exploits" and says stuff like: "These exploits, when used for malicious purposes, have the potential to improperly gather sensitive data. Intel believes these exploits do not have the potential to corrupt, modify or delete data." Is this lawyering so they can say they never claimed to have addressed the vulnerabilities?