9 ms·

ZombieLoad: Cross Privilege-Boundary Data Leakage on Intel CPUs

• spockz 7y ago
  According to their blog post[1], there is little you can do against this. Running different applications on different cpus help against them reading each other’s data but an rogue process can still read data from the “super ordinated kernel” or hypervisor.
  • rurban 7y ago
    Of course you can fix it. I fixed it in Dec 2018 for most such attacks in my safelibc memset_s implementation, but nobody wanted to use it, because securely purging the buffers with secrets via mfence was deemed to slow. So everybody can read your secrets via sidechannel attacks. These tiny MDS buffers need to be purged with verw or l1d_flush followed by an lfence. This needs to be added to memset and memset_s variants. This is much faster. But it will not happen, libc maintainers notoriously don't care, even crypto maintainers not. Only Linux does. https://software.intel.com/security-software-guidance/software-guidance/microarchitectural-data-sampling https://software.intel.com/security-software-guidance/softwa...
    • tux1968 7y ago
      > This is much faster. Hi. Am trying to understand what you meant here. That both "verw" or "l1d_flush followed by an lfence" are faster than "mfence" which you implemented in safelibc? If so, why didn't you use these faster options yourself? My understanding was that these faster options needed to be handled at the hypervisor/kernel level, rather than in libc. If so, how is the attitude of glibc maintainers relevant?
      • rurban 7y ago
        verw and l1d_fence have no costs. lfence is a bit costly, mfence is basically an lfence + sfence. it flushes both caches, load and store. safe libs need to do the right thing, not the fast thing. esp. crypto. The attitude of libc and crypto maintainers is that you cannot trust them with security. all the memzero's are insecure. besides being overly complicated and slow. Linux is a bit better, but there are still estimated 20.000 security relevant bugs.
    • gpderetta 7y ago
      What prevents the data being read before the memset is executed?
      • rurban 7y ago
        Nothing but the window of opportunity. A secure lib will zero secrets as soon as they are not needed anymore. On the fly attacks are always possible. But when you securely cleanup, the attackers has less time to extract it. the usual sidechannel attacks leak the secrets only bit by bit and need some time.
        • gpderetta 7y ago
          but mfence itself also only close a small window of opportunity on the same thread between the zeros being written and the store buffer being flushed.
• daeken 7y ago
  Pandora's box was opened with the public disclosure of Spectre and Meltdown. Security researchers will continue to find new and better ways of attacking the security boundaries in processors, and there's unlikely to be an end to this any time soon. Exciting time to be in security, not such an exciting time to be a potential victim.
  • penagwin 7y ago
    Not arguing just asking, but how has Pandora's box been opened with the discloser of Spectre and Meltdown? We've had security researchers discovering and reporting vulnerabilities since there were computers as far as I know? I do agree that this won't end soon though. It appears to me that many of the methods CPU's use for better performance are fundamentally flawed in their security, and it's not like we can expect the millions of affected machines to be upgraded to mitigate this.
    • daeken 7y ago
      Before Spectre and Meltdown were disclosed publicly, very very few security researchers were looking at the CPU level, beyond things like attacks against hardware virtualization functionality, TrustZone and friends, ME, etc. Those bugs had existed for ages and could've been found through thorough examination of the processor manuals, but nobody had really looked too hard there. These new bugs were found independently by many different researchers/groups, simply because their attention was drawn to looking at this stuff for the first time.
      • monocasa 7y ago
        But like, those bugs were there. They might have been being exploited and not been caught. Your argument sounds like an argument against responsible disclosure totally.
        • starshadowx2 7y ago
          Opening Pandora's Box is a good thing. It gets the issues out in the air and visible so you know what more to look out for and what needs to be fixed. Don't forget that Hope was also released when the box was opened.
• shereadsthenews 7y ago
  I really hate these descriptions of SMT as some kind of violation of the natural relationship between CPU frontend and backend. The idea that there is a “physical core” and a “logical core” does not map to reality.
  • xyzzyz 7y ago
    The idea that there is a “physical core” and a “logical core” does not map to reality. This is the terminology that Intel itself uses in its documentation to describe its products, though. To be fair, they say "physical processor" and "logical processor", not "core".
• jamiek88 7y ago
  9% hit potentially on performance in data center. Add in all the Spectre and meltdown mitigations and we have potentially lost nearly two generations of Intel performance increases. Just shows the hoops and tricks needed to keep making, on paper, faster processors year on year but without node shrinks to give headroom. 14nm++++ is played out.
  • faissaloo 7y ago
    I wonder at what point the hardware fix for these issues stop becoming worthwhile and if we'll see a resurgence of processors without speculative execution or any of these other speed ups.
    • shrimp_emoji 7y ago
      Or open source RISC-Vs
      • silversconfused 7y ago
        At hyper scale? Yes please!
    • gmueckl 7y ago
      My guess is that the performance loss from removing these features would make such CPUs less economical than strictly enforced separation between security domains on a hardware assignment and scheduling level. That is, just forget about having the same server run stuff from different contexts at the same time.
    • TomVDB 7y ago
      If ARM and AMD CPUs are not affected, then speculative execution in general is not the issue.
      • dfrage 7y ago
        But they are, ARM to both a Meltdown variant and Spectre, as well IBM's POWER and mainframe chips, and AMD to Spectre.
• mda 7y ago
  Looks like AMD Cpus are safe again.
  • harryh 7y ago
    Note that Spectre definitely affected AMD chips and in general these sorts of side channel attacks based on speculative execution are extremely likely to be effective against any chip (including AMD manufactured ones) that employ speculative execution though the precise implementation might have to be jiggered a bit.
    • makomk 7y ago
      Not necessarily. This is more like Meltdown in that it involves one context just outright accessing data in a completely different context, and AMD chips seem to be totally immune from that attack. Any chip with a microarchitecture that actually enforces the architecturally-guaranteed checks, rather than ignoring them and fixing the results up later, can avoid such attacks. Spectre, on the other hand, is harder both to fix in hardware and to attack because the victim context is itself tricked into speculatively executing code using attacker-supplied data that leaks information - it uses inherent properties of speculative execution rather than any kind of hardware bug, but it's only exploitable if there's some victim code that does exactly the right kind of processing on attacker-supplied data.
      • kentonv 7y ago
        > This is more like Meltdown in that it involves one context just outright accessing data in a completely different context, and AMD chips seem to be totally immune from that attack. No, AMD has been largely immune to bugs involving speculating past a page fault. Both Meltdown and L1TF involved speculating past page faults, and the ZombieLoad paper also mentions exploiting bad behavior during page faults (but, disclaimer, I haven't read in enough detail yet). AMD was not immune to, for example, spectre variant 2, which very much did allow reading from other address spaces (even other VMs): https://www.amd.com/en/corporate/security-updates https://www.amd.com/en/corporate/security-updates In general it doesn't make sense to expect that any brand of processors might be vulnerable or invulnerable to all illegal memory access. There are many different components involved in handling memory access and many different ways they could go wrong.
• nine_k 7y ago
  In short: * Core and Xeon CPUs affected, others apparently not. * HT on or off, any kind of virtualization, and even SGX are penetrable. * Not OS-specific, apparently. * Sample code provided. https://www.cyberus-technology.de/posts/2019-05-14-zombieload.html https://www.cyberus-technology.de/posts/2019-05-14-zombieloa...
  • waddlesplash 7y ago
    And here's the mitigation in NetBSD: https://github.com/NetBSD/src/commit/afab82aeafd0c51afc036a8b35dd0ed428b2885b https://github.com/NetBSD/src/commit/afab82aeafd0c51afc036a8... Essentially: Intel released a microcode update which makes the `verw` instruction now magically flush MDS-affected buffers. On vulerable CPUs, this instruction now needs to be run on kernel exit; the microcode update won’t do it automatically on `sysexit`, unfortunately.
    • nine_k 7y ago
      Hopefully with this patches for other OSes should appear soon.
  • jolopy 7y ago
    many Pentiums, Celerons and Atoms are also affected.
• ksec 7y ago
  Sorry for being naive. Are these kind of CPU Securities vulnerabilities new? Why it is in the past 20 years we have had close to zero in the news ( At least I wasn't aware of any ) and ever since Spectre and Meltdown we have something new like every few months. And as far as I am aware they are mostly Intel CPU only. Why? And Why not AMD? Something in the Intel design process went wrong? And yet all the Cloud Vendor are still buying Intel and giving very little business to AMD.
  • wmf 7y ago
    I think it is definitely worth introspecting about the history. It has been known for over 20 years that sharing pretty much anything creates side channels but nobody knew how to reliably exploit them and it was assumed that side channels might never be exploitable. In recent years there has been massive progress in practical data extraction using side channels.
    • philsnow 7y ago
      Theo (of OpenBSD) famously ranted about Intel's implementation of SMT/hyperthreading ~12 years ago https://marc.info/?l=openbsd-misc&m=118296441702631&w=2 https://marc.info/?l=openbsd-misc&m=118296441702631&w=2
      • jawnv6 7y ago
        you sure about that link? he's talking about a core that didn't have SMT and is ranting, in general, about errata existing and wildly misrepresenting their impact never mind that most errata are conditional until the ucode patch load, but that particular rant has nothing to do with HT
    • altfredd 7y ago
      It have always been known how to exploit them. But doing so used to be slower and there have been fewer opportunities for attacks. OS kernels used to have Big Locks (AFAIK, OpenBSD still does), that significantly deterred programs from messing with kernel code and CPU caches. Things have changed a lot since then: OS kernels became faster by eliminating a lot of unnecessary (?) cross-process overhead; browser makers made a number of potentially problematic decisions ("let's allow Javascript to create CPU threads — what could possibly go wrong?"); Linux kernel developers made few potentially problematic decisions ("let's allow unprivileged processes to invoke arbitrary BPF bytecode — that worked for Java, so what could possibly go wrong?") A lot of small security lapses added up until it became viable to use CPU flaws to actually target ordinary users. To add insult to injury, certain corporations started spreading myth, that well-known insecure practices — such as knowingly running local software from questionable authors — are "safe enough" for general population. Topic web page even talks about running untrusted Android software, as if Android had some kind of impenetrable security boundary around untrusted apps.
• gmueckl 7y ago
  These CPU flaws make it seem as if virtualization in the data center is becoming really, really dangerous. If these exploits continue to appear, the only way forward would be dedicated machines for each application of each customer. Essentially, this might be killing the cloud by 1000 papercuts because it loses efficiency and cost effectiveness and locally hosted hardware does not necessarily have to have all mitigations applied (no potential of a unknown 3rd party code deployed to the same server).
  • ljlolel 7y ago
    it increases cloud revenues because of slow downs in CPU, and people can't move off cloud because they're locked in and can't hire datacenter engineers anyway
    • gnode 7y ago
      Ultimately cloud providers don't want revenue, they want profit. Except in some perverse cases (like cost-plus-percentage contracts), it's not generally in a business's interests for their costs to go up. Even if there's no opportunity to switch away, eventually you bleed your customers dry and put them out of business. You will typically always aim to price your offering at the equilibrium point where loss of custom increases faster than the increase in profit, and vice versa. One situation in which an increase in your costs can be good, is if the same increase applies more to your competition. But, in this case multi-tenant cloud is hit harder than the competing alternative of private infrastructure.
    • chatmasta 7y ago
      This is an important point that I noticed around the time of Spectre/Meltdown as well. The mitigation for those bugs caused an average of 30% CPU slowdown, meaning it took 30% more CPU cycles to perform the same work as it did prior to the mitigation. If a cloud provider rolls that out to every server, then every customer's bill for CPU usage should increase by roughly 30%. Am I totally misunderstanding this? Someone please correct me if I'm wrong.
  • gnode 7y ago
    > dedicated machines for each application of each customer. I don't think you don't need to go this far. You can probably get away with circuit switching small blocks of hardware, and fully resetting them between handovers. Although you'd have to ensure sufficient randomisation / granularity to destroy side channels in the switching logic.
• mr_overalls 7y ago
  At what point do we simply revert to using typewriters for authoring sensitive documents, and pneumatic tubes (couriers for WAN) for networking? https://www.theguardian.com/world/2014/jul/15/germany-typewriters-espionage-nsa-spying-surveillance https://www.theguardian.com/world/2014/jul/15/germany-typewr...
  • gambler 7y ago
    We don't need to revert to typewriters. We just need computers designed with a real security model in mind, instead of piles of ah-hoc mitigations. However, I bet no one will invest in it until one of these exploits bring down AWS, take over Google's crawlers or something else of that sort.
    • nickpsecurity 7y ago
      There's smaller companies that keeps designing them. Nobody buys them for the most part. One example that can handle lots of security policies is CoreGuard. It's based on work at crash-safe.org. https://www.dovermicrosystems.com/ https://www.dovermicrosystems.com/ Academics keep coming up with stuff for timing channels like partitioning, masking, and randomizing components. Personally, if not physical separation, I'd just do SMP with secret parts on different CPU that untrusted parts. Both memory safe on a separation kernel to isolate them. One design used different DIMM's, too.
    • icelancer 7y ago
      >> We just need computers designed with a real security model in mind These are already options, as another commenter pointed out. If you need this kind of protection, it is available, at significant cost.
  • criley2 7y ago
    Long ago? https://www.theguardian.com/world/2013/jul/11/russia-reverts-paper-nsa-leaks https://www.theguardian.com/world/2013/jul/11/russia-reverts... (also https://www.cia.gov/library/readingroom/document/cia-rdp78-04718a000800290072-5 https://www.cia.gov/library/readingroom/document/cia-rdp78-0...) But assuming a typewriter has no attack vectors is just as foolish as insecure networks IMO. https://arstechnica.com/information-technology/2015/10/how-soviets-used-ibm-selectric-keyloggers-to-spy-on-us-diplomats/ https://arstechnica.com/information-technology/2015/10/how-s... Also: detecting text through keystrokes previously discussed here https://news.ycombinator.com/item?id=7448976 https://news.ycombinator.com/item?id=7448976 (https://people.eecs.berkeley.edu/~tygar/papers/Keyboard_Acoustic_Emanations_Revisited/tiss.preprint.pdf https://people.eecs.berkeley.edu/~tygar/papers/Keyboard_Acou...) Heck while I can't find a quick source, I remember a story about how the CIA designs rooms/walls and buildings to prevent sound from predictably bouncing through rooms in ways that could be captured from afar. Spooks are usually 10 steps ahead of the public common sense this sense.
• S_A_P 7y ago
  This sentence killed me: "Daniel Gruss, one of the researchers who discovered the latest round of chip flaws, said it works “just like” it PCs and can read data off the processor. That’s potentially a major problem in cloud environments where different customers’ virtual machines run on the same server hardware." What are they saying here?
  • jcoffland 7y ago
    It should read: > ...said it works “just like” in PCs The number of mistakes in the Techcrunch article is atrocious.
    • ficklepickle 7y ago
      I found two and emailed the author. It's my sad little hobby. He replied promptly and they all should be fixed now. In fact, he found a third that I missed. Keep in mind, this article was posted at 3am pacific, 6am eastern. Assuming the author is in North America, he was probably under a deadline and rather tired. I have found similar typos from prominent writers. Sometimes they email me back, which I appreciate. I found one in an article by Cory Doctorow on boingboing. I checked on builtwith.com, and they use WordPress/Jetpack. Jetpack has a feature that will warn you if you try and publish something with spelling mistakes, it is just not enabled by default. I let Mr Doctorow know all this, in a very polite manner, and he responded with "many thanks". I'm not big on celebrity worship, but it still made my day.
      • toomuchtodo 7y ago
        Thank you for your service!
        • xondono 7y ago
          I know this comment adds nothing of value but I have to quote it anyway “Service guarantees citizenship, want to know more?”
      • jcims 7y ago
• tosh 7y ago
  This looks like it is from the same TU Graz people who also worked on Meltdown & Spectre https://meltdownattack.com/ https://meltdownattack.com/
• deleted 7y ago
  [deleted]
• dschuetz 7y ago
  It takes one rouge/unpatched VM to run and scan threads randomly, undetected over a longer period of time, if not patched. With HT disabled potential hits become less likely, but still possible given time. Is virtualization on Intel dead now? Perhaps not. But, it's increasingly dangerous to use Intel for cloud services.
  • nnx 7y ago
    Interestingly AWS released a bulletin about MDS vulnerability but nothing about ZombieLoad yet. https://aws.amazon.com/security/security-bulletins/AWS-2019-004/ https://aws.amazon.com/security/security-bulletins/AWS-2019-...
    • scandinavian 7y ago
      CVE-2018-12130 is in the list of CVE's in your link. That is the ZombieLoad CVE. I hate these stupid names, they only confuse as shown by your comment.
• dang 7y ago
  Url changed from https://zombieloadattack.com https://zombieloadattack.com, which points to this. There is a home page about today's vulnerability disclosures at https://news.ycombinator.com/item?id=19911715 https://news.ycombinator.com/item?id=19911715. We're disentangling these threads so discussion can focus on what's specific about the two major discoveries. At least I think there are two.
  • makomk 7y ago
    I think there's two seperate branded annoucemenst of three or four different vulnerabilities depending on how you count. (There are four CVEs and Intel lists four, but the researchers announced three.) Haven't seen much discussion of the specific differences between them, probably because they're subtle and not terribly relevant to most folks - they all involve one process speculatively reading memory it shouldn't be able to access via the memory access buffers within Intel CPUs, they just vary in which parts of the memory access machinery they use and how exactly they're exploited.
• polskibus 7y ago
  Can this attack allow the attacker to escape public cloud isolation methods and break into the control plane or other VMs?
  • readams 7y ago
    It would have, but it's likely the cloud vendors have already deployed defenses.
    • mattashii 7y ago
      Today's AWS[1] and Google Cloud[2] security bulletin notes that all their host infrastucture (read: cpu firmware/microcode) has been updated to mitigate the issues disclosed today by Intel[3]. I could not find anything for Azure yet. I also note that the provided OSes are being updated with mitigations as well, so for complete mitigation of the issue you'll probably need to update your OS. [1] https://aws.amazon.com/security/security-bulletins/AWS-2019-004/ https://aws.amazon.com/security/security-bulletins/AWS-2019-... [2] https://cloud.google.com/compute/docs/security-bulletins#20190514 https://cloud.google.com/compute/docs/security-bulletins#201... [3] https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00233.html https://www.intel.com/content/www/us/en/security-center/advi...
  • robmccoll 7y ago
    That depends on what you mean by "break into". If you mean sample data (read) from the control plane or other VMs, then yes; however, the attacker may have difficulty targeting which data is read. The attacker would not be able to write to that memory or gain any sort of execution privilege using this method alone.
• Fej 7y ago
  What is the recommended course of action? Stop buying Intel products, and devices which contain them? What about devices with older processors? I'm still running a Sandy Bridge rig and it works fine, except for the side channel vulnerablities. It's probably not going to be patched. I also have a cheaper computer with a Skylake processor, which is newer yet still vulnerable! It's only a matter of time until something really nasty comes along, making all these PCs dangerous to use. What then? Lawsuits? My questions are only partially rhetorical.
  • cfallin 7y ago
    The stream of critical CPU vulnerabilities starting with Spectre/Meltdown last year are related to speculative execution, not just Intel. (AMD and ARM CPUs are also vulnerable to Spectre, for example.) Intel CPUs are sometimes vulnerable to additional attacks because they speculate in more scenarios than other designs. But fundamentally, as long as multiple different trust domains are sharing one CPU that speculates at all, or has any microarchitectural state (e.g., caches), there are likely to be some side-channel attacks that are possible. The important thing to realize is that speculation and caching and such were invented for performance reasons, and without them, modern computers would be 10x-100x slower. There's a fundamental tradeoff where the CPU could wait for all TLB/permissions checks (increased load latency!), deterministically return data with the same latency for all loads (no caching!), never execute past a branch (no branch prediction!), etc., but it historically has done all these things because the realistic possibility of side-channel attacks never occurred to most microarchitects. Everyone considered designs correct because the architectural result obeyed the restrictions (the final architectural state contained no trace of the bad speculation). Spectre/Meltdown, which leak the speculative information via the cache side-channel, completely blindsided the architecture community; it wasn't just one incompetent company. The safest bet now for the best security is probably to stick to in-order CPUs (e.g., older ARM SoCs) -- then there's still a side-channel via cache interference, but this is less bad than all the intra-core side channels.
    • ct520 7y ago
      Sounds a lot like something a intel core architect would say ;)
• IgorPartola 7y ago
  So at what point do we start producing CPUs specifically aimed at running a kernel/userland? Why don't we have a CPU architecture where a master core is dedicated to running the kernel and a bunch of other cores run userland programs? I am genuinely curious. I understand that x86 is now the dominant platform in cloud computing. But it's not like virtualization needs to be infinitely nested, right? Why not have the host platform run a single CPU to manage virtual machines, which each get their own core or 20? Would the virtual machines care that they don't have access to all the hardware, just most of it?
  • deleted 7y ago
    [deleted]
  • founderling 7y ago
    You cannot give each VM their own core. The business model of the cloud is that multiple VMs with virtual cores run on a single real core.
    • derefr 7y ago
      At the low end, sure. At the medium-to-high end, each VM is bound to one or more physical cores of the host, or sometimes an entire host ("dedicated instances.") I don't know enough about the IaaS market to know what the relative revenues of low-end compute vs. medium-to-high-end compute are for your average vendor, though. Is most of the profit in the low end? I'm also curious on what the impact on margins would be if IaaS vendors decided to switch away from serving the low-end compute demand with "a few expensive high-power Intel cores per board, each multitasking many vCPUs", to serving the demand with "tons of cheap low-power ARM cores per board (per die?) with each core bound to one vCPU."
      • aflag 7y ago
        The low end compute must be a substantial amount of revenue.
    • LASR 7y ago
      Very little of the cloud compute business actually involves compute. Businesses move to the cloud for lower TCO compared to solutions they would have to hire entire teams of engineers to deploy and manage. Something like AWS, the CPU cores account for a small percentage of the revenues they make. The vast majority of their EC2 instance types have dedicated CPU cores. This may not necessarily mean that VMs are pinned to cores, but just that the overall compute power available is pretty tightly segmented. But regardless, as a technical decision maker, I’ll move my organization to the cloud because of scalability, fault-tolerance, reliability & security - things that would be impossible or prohibitively expensive to do on-prem. CPU cores are rounding errors in comparison.
• justryry 7y ago
  Do cloud providers commonly float cores between VMs? I could see instances like the AWS T family (burstable) sharing, but I had always assumed that most instance types don't over-provision CPU. If that's the case, my CPUs are likely pinned to my VM. I could still have evil userland apps spying on my own VM, but I would not expect this to allow other VMs to spy on mine.
  • jupp0r 7y ago
    Sharing CPUs is not the point, as long as you are sharing physical memory with other tenants, you are vulnerable (although exploits are much harder when attackers have to cross privilege boundaries).
    • srfilipek 7y ago
      > Sharing CPUs is not the point, as long as you are sharing physical memory with other tenants, you are vulnerable Not to these vulnerabilities. These are attacking memory that is "in flight" within a processor.
  • bayindirh 7y ago
    I don't think many cloud providers explicitly pin the VMs to the cores even if they don't over provision the servers.
• INTPenis 7y ago
  So I'd love to post an Ask HN: Which AMD Laptops would you recommend for work, alternatives to Thinkpads? I've noticed some Thinkpads with AMD CPUs but I feel like I'm on virgin ground when it comes to AMD and their integrated GPU offerings.
  • strmpnk 7y ago
    I've been eyeing more release details on the ThinkPad X395 which was recently announced. "Coming Soon" is probably means early June for some select configurations. I think these will fit in the premium/professional laptop space better than some of the bargain laptops that carried AMD chips in the past. I believe others OEMs are developing similar offerings as well but I can't find any quick links for newer SKUs like the Ryzen 7 3700U which offers the improved Zen+ revisions which will specifically improve battery life and heat issues.
    • chx 7y ago
      Yes the T495 and the X395 ought to be the best ones.
  • Shelnutt2 7y ago
    If you don't need a dedicated GPU, the APU offers from AMD are great. They have native linux drivers for everything (on the AMD side, double check the nic/touchscreen/touchpad). I'm using an HP envy x360 15z with a AMD Ryzen 2700u running gentoo and love it. The HP envy has a weird keyboard, but it was a good tradeoff for the AMD setup when I bought it last year. There is a much larger market in 2019 for AMD laptops, so you should be able to find something to suite your needs.
    • akvadrako 7y ago
      It's not that large yet. There are sadly still no options with HiDPI screens (200+ dpi) or discrete AMD GPUs. Next year with the 7nm mobile chips will probably be much better.
  • bitL 7y ago
• fakwandi_priv 7y ago
  Apparently Intel attempted to play down the issue by trying to award the researchers with the 40,000 dollar tier reward and a separate 80,000 dollar reward as a "gift" (which the researchers kindly denied) instead of the maximum 100,000 reward for finding a critical vulnerability. Intel was also planning to wait for at least another 6 months before bringing this to light if it wasn't for the researchers threatening to release the details in May. Source in the dutch interview: https://www.nrc.nl/nieuws/2019/05/14/hackers-mikken-op-het-intel-hart-a3960208 https://www.nrc.nl/nieuws/2019/05/14/hackers-mikken-op-het-i...
  • easytiger 7y ago
    You have to admire the complex complicity. Someone smart enough to understand the depths of the problem had to guide that conversation
    • btown 7y ago
      Or just someone paranoid enough that this would be their standard response if they poll the researchers and one of them says "this could be New York Times big"
  • close04 7y ago
    > Intel was also planning to wait for at least another 6 months before bringing this to light Of course, until the legally agreed date when they can dump shares so there’s no obvious proof that it’s insider trading. Isn’t that what (then) Intel CEO Brian Krzanich did after Meltdown/Spectre?
    • nullwasamistake 7y ago
      Not sure why down voted, this sounds like the most logical reason
      • cududa 7y ago
        Because they’d eventually have to disclose when the vulnerability was discovered and that’d be extremely obvious what they’re doing?
• yalok 7y ago
  > macOS performance: Testing conducted by Apple in May 2019 showed as much as a 40% reduction in performance with tests that include multithreaded workloads and public benchmarks. Performance tests are conducted using specific Mac computers. Actual results will vary based on model, configuration, usage, and other factors. from here: https://support.apple.com/en-us/HT210107 https://support.apple.com/en-us/HT210107
  • ynnn 7y ago
    Yeah, if you choose to turn off hyperthreading. Pretty expected tbh - hyperthreading helps quite a bit for some things.
    • yalok 7y ago
      but I don't see Intel mentioning this 40% anywhere... by Intel words, the worst degradation is 9%, and it creates an impression that it's with HT off. If you choose not to disable HT, you stay vulnerable even with updated microcode, right? In any case, Apple's stats are much more gruesome...
      • FluffyKitty 7y ago
        It really is going to depend on what test you are running. HT has the greatest effect when the running process has a lot of "downtime" for things like memory retrieval or any I/O as it allows for other processes to make use of this downtime. So if your tests are just doing calculations with very little file/network I/O it could very well be in the 9% range.
        • ct520 7y ago
          The best of the worst case. Gotta love that Intel spin machine working in overdrive
• deleted 7y ago
  [deleted]
• jniedrauer 7y ago
  What impact does this have in a multi-tenant cloud environment? I'm legitimately considering moving my security critical EC2 instances over to AMD-backed instance types right now.
  • scandinavian 7y ago
    I doubt that you both manage critical infrastructure on AWS and haven't read the AWS security bulletin. https://aws.amazon.com/security/security-bulletins/AWS-2019-004/ https://aws.amazon.com/security/security-bulletins/AWS-2019-...
• mettamage 7y ago
  I just want to plug their course hardware security (at the VU University Amsterdam). It's an amazing course and it costs 1200 euro's for students who need to pay full price. I've learned a lot about Spectre, Meltdown and novel forms of cache attacks and Rowhammer when I took it.
  • 1Y3 7y ago
    Offtopic: Are you familiar with the AI departments/ courses (master) at VU? I have the opportunity to go but haven't decided yet. (Interested in human-centred and modern ML with neural networks)
    • mettamage 7y ago
      Hey, yea I do have some familiarity. Send me an email to have a conversation, it's in my profile.
• bigmattystyles 7y ago
  Why doesn't this type of news cause INTC to tank - they're up today. I know the market is up today, but (and it's probably my innate overreaction) I would think this sort of news would cause its stock to suffer.
  • mda 7y ago
    I think there is an expectation that Intel's new generation CPUs wont have these vulnerabilities and they will sell these a lot more to replace the piece of crap they have sold for ridiculous prices. Intel is actually probably happy about these, because no one cares.
    • groovylick 7y ago
      Intel have not been able to produce 10nm chips for 2 years now and they don't expect them until 2020. If the Ryzen 3000 leaks of a 15% IPC gain are proven to be true in a couple weeks then Intel is in real trouble. Add on additional performance losses with this mitigation and Intel is very likely to lose the top end of the CPU market for at least 2 years. INTC might look very different come the end of the month.
  • ct520 7y ago
    It should take a couple of days, also Intel is coming off continuous losses.
  • nodesocket 7y ago
    I follow the market and tech stocks pretty closely and it is extraditionary rate for breaches, vulnerabilities, or exploits to affect the stock price of companies despite the outrage from the tech community.
  • neop1x 7y ago
    Because it depends on customer behavior. Intel has a strong name and people know their CPUs are fast. We see various IT security problems almost daily and most people don't care... It would probably require some massive exploits, data leaks, identity thefts in cloud providers and following lawsuits againts Intel to see some significant stock price change. :)
• cesarb 7y ago
  Some information for Linux, from LWN.net (https://lwn.net/Articles/788381/ https://lwn.net/Articles/788381/): "See this page from the kernel documentation (https://www.kernel.org/doc/html/latest/x86/mds.html#mds https://www.kernel.org/doc/html/latest/x86/mds.html#mds) for a fairly detailed description of the problem, and this page (https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/mds.html https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/m...) for mitigation information."
• morpheuskafka 7y ago
  Is there any clear source of info for sysadmins responding to the many CPU-level vulns in the past year? It's very difficult to keep track of whether fixes are needed at ucode, OS, and/or application level, and what version numbers fix each bug.
• p1necone 7y ago
  I'm sure I remember a post on here (or possibly /r/programming) a couple of years ago from an Intel employee mentioning that Intel was cutting a lot of QA staff, and that we should expect more bugs in the future. I could be imagining things though.
  • ahartmetz 7y ago
    I remember a leak about a call to become "more agile" like some ARM designers, implying less time spent on verification.
    • redrabbyte 7y ago
      verification wouldn't catch any of this, the processors operate correctly on an architectural level most of this seems to be behaving as intended, they just didn't foresee the side channels this opens up
• deleted 7y ago
  [deleted]
• guido_vongraum 7y ago
  People should realize that ancient Chinese were onto something when they told that all phenomena shall evolve only so much before they tip over the peak of maximum development and inevitably rumble downhill into overdevelopment. P.S. Wow, hit a soft spot. Flagging this for what? For being unloyal to the ideology of everlasting growth? Try again as much as you can.
  • TACIXAT 7y ago
    Downvoted for the frothy edit. Chill out there ya toughy. Someone clearly hit a soft spot on you.
    • deleted 7y ago
      [deleted]
    • deleted 7y ago
      [deleted]
• deleted 7y ago
  [deleted]
• deleted 7y ago
  [deleted]
• deleted 7y ago
  [deleted]
• deleted 7y ago
  [deleted]
• deleted 7y ago
  [deleted]
• deleted 7y ago
  [deleted]
• deleted 7y ago
  [deleted]
• guido_vongraum 7y ago
  People should realize that ancient Chinese were оnto something when they told that all phenomena shall evolve only so much before they tip over the peak of maximum development and inevitably rumble downhill into overdevelopment. P.S. the Holy Church of Progress keeps flagging the herecy of I-Ching out of existence, may it prevail in its glorious ways. Curious fact: expressing your disagreement in written form takes more neurons than flagging reflex does. Try and ye shall succeed!
  • dang 7y ago
    I like the I Ching too but could you please stop posting these and then deleting them? It's an abuse of the site.
    • guido_vongraum 7y ago
      I'll stop as soon as dysgraphic flaggers stop. The true abuse is muting a comment that doesn't offend anyone, just calling to contemplate a philosophy so different from the current mainline it hurts. Or does it? Are they triggered by 'people should'? Yeah, they should, but don't have to. Is the very notion of impossibility to improve things forever without changing their essence offensive? Any other reason, could you explain it, please?
• deleted 7y ago
  [deleted]
• robdachshund 7y ago
  Hooray, yet another vulnerability caused by the speculative hacks Intel implemented instead of investing in research and development. We have had the same basic architecture since 2011's Sandy Bridge. That's 8 years of die shrinks and speculation hacks. This is what happens when you have only 2 players in a major industry and one of them slips away from parity. AMD failed to compete with Bulldozer, so Intel hasn't had to innovate for nearly a decade. As a result, Intel cpus are now all slower than they were on release and Intel may have to disable hyperthreading for their patches. This is utterly pathetic. Between this, the other exploits, the shameless price gouging and removal of features, the utter failure of their 10nm process, and the appeal of Ryzen, I think Intel is screwed. They've been selling us the same crap for 8 straight years. Moore's law isn't dead, Intel just tossed it aside when they realized they didn't have to lift a finger to keep raking in cash. Can't wait for zen2 and to say bye bye to Intel for a long time.
• flattone 7y ago
  crucial (for me anyway) summary of relevant events of the day https://twitter.com/IanColdwater/status/1128395135702585347?s=20 https://twitter.com/IanColdwater/status/1128395135702585347?...
• userbinator 7y ago
  An unprivileged attacker with the ability to execute code That sounds like a contradiction --- if you can already execute code, I'd say you're quite privileged. It's unfortunate that their demo doesn't itself run in the browser using JS (I don't know if it's possible), because that's closer to what people might think of as "unprivileged". The attacker has no control over the address from which data is leaked, therefore it is necessary to know when the victim application handles the interesting data. This is a very important point that all the Spectre/Meltdown-originated side-channels have in common, so I think it deserves more attention: there's a huge difference between being able to read some random data (theoretically, a leak) and it being actionable (practically, to exploit it); of course as mentioned in the article there are certain data which has patterns, but things like encryption keys tend to be pretty much random --- and then there's the question of what exactly that key is protecting. Let's say you did manage to correctly read a whole TLS session key --- what are you going to do with it? How are you going to get access to the network traffic it's protecting? You have just as much chance that this same exploit will leak the bytes of that before it's encrypted, so the ability to do something "attackful" is still rather limited. Even the data which has patterns, like the mentioned credit card numbers, still needs some other associated data (cardholder name, PIN, etc.) in order to actually be usable. The unpredictability of what you get, and the speed at which you can read (the demo shows 31 seconds to read 12 bytes), IMHO leads to a situation where getting all the pieces to line up just right for one specific victim is a huge effort, and because it's timing-based, any small change in the environment could easily "shift the sand" and result in reading something entirely different from what you had planned with all the careful setup you did. Using ZombieLoad as a covert channel, two VMs could communicate with each other even in scenarios where they are configured in a way that forbids direct interaction between them. IMHO that example is stretching things a bit, because it's already possible to "signal" between VMs by using indicators as crude as CPU or disk usage --- all one VM has to do to "write" is "pulse" the CPU or disk usage in whatever pattern it wants, modulating it with the data it wants to send, and the other one can "read" just by timing how long operations take. Anyone who has ever experienced things like "this machine is more responsive now, I guess the build I was doing in the background is finished" has seen this simple side-channel in action.
  • shittyadmin 7y ago
• nodesocket 7y ago
  If using a cloud provider with Intel processors: > The safest workaround to prevent this extremely powerful attack is running trusted and untrusted applications on different physical machines. Nope! > If this is not feasible in given contexts, disabling Hyperthreading completely represents the safest mitigation. Nope! Shrugs?
• zelon88 7y ago
  So far there seem to be far more of these vulnerabilities in Intel CPUs. Is that a reflection of engineering differences or a statistical byproduct of the market share of Intel CPUs? I run AMD not because of the security implications but because I feel every dollar that goes to Intel competition will push Intel and thus the entire industry forward.
  • dfrage 7y ago
    Market share is a good answer, in x86 space alone per https://www.extremetech.com/computing/291032-amd-gains-market-share-in-desktop-and-laptop-slips-in-servers https://www.extremetech.com/computing/291032-amd-gains-marke... which I found without putting much effort into it, AMD's share in servers is negligible and even dropped in the last quarter. On the other hand mobile and especially desktop are rising smartly, but still somewhat modest. IoT is excluded, and AMD could be doing well there to the extent anyone's using x86 for that, and there's also (quasi) embedded like network gear. So the cloud vendors are 97% minimum Intel, they're exquisitely vulnerable both technically and reputationally to these bugs, the stakes are existential for them and they have a lot of money they can throw at the problem, whereas the users of notebooks and desktops are a much more diffuse interest. As I've mentioned many times in these discussions today, everyone had Spectre issues, and everyone but AMD has Meltdown ones. The more recent vulnerabilities are Intel only because they're using what was learned from those first two to attack Intel specific features like the SGX enclave.
  • repolfx 7y ago
    Probably both - AMD chips have lower market share because they have lower performance, and they have lower performance (maybe) because they speculate less aggressively. Intel did these optimisations for a reason after all; the market rewards them.
• guido_vongraum 7y ago
  It's about time to realize that ancient Chinese were оnto something when they told that all phenomena shall evolve only so much before they tip over the peak of maximum development and inevitably rumble downhill into overdevelopment.
• rhabarba 7y ago
  Another non-issue on non-Intel CPUs, like SPARC. Lovely.
• clarry 7y ago
  The best defense against all these CPU vulns is to stop running malicious code. And that means getting off of shared VMs (and similar) where someone could run malicious code in your stead. Stop running any script your browser gets handed. Isolation was always a great idea, poor man's isolation (VMs, processes, ...) is only useful for isolation against non-malicios accidental interference. You want physical isolation between applications and services.
• fdfdde3 7y ago
  OpenBSD was right and disabled HT for Intel CPUs in June 2018 ago due to concerns of more such CPU bugs coming up. There we go ... https://news.ycombinator.com/item?id=17350278 https://news.ycombinator.com/item?id=17350278
  • fluffything 7y ago
    This. I remember people laughing at this decision back then, and flaming on OpenBSD policies to handling security vulnerabilities, to the point where they aren't informed anymore. Yet OpenBSD is the only major OS taking these issues seriously instead of believing whatever Intel marketing department yells every other day.
• nathan_long 7y ago
  These style of exploits remind me of "The Free Lunch Is Over: A Fundamental Turn Toward Concurrency in Software" (2005) - http://www.gotw.ca/publications/concurrency-ddj.htm http://www.gotw.ca/publications/concurrency-ddj.htm > Chip designers are under so much pressure to deliver ever-faster CPUs that they’ll risk changing the meaning of your program, and possibly break it, in order to make it run faster. > ... > applications will increasingly need to be concurrent if they want to fully exploit CPU throughput gains that have now started becoming available and will continue to materialize over the next several years. For example, Intel is talking about someday producing 100-core chips; a single-threaded application can exploit at most 1/100 of such a chip’s potential throughput. It seems the trend in programming languages is towards better concurrency support. But why don't we yet see 100-core chips? If chip makers had to forego all speculative execution and similar tricks, would that push us toward the many-core future?