32 ms·

Intel Confronts Potential ‘PR Nightmare’ With Reported Chip Flaw

1026 points by el_duderino 9y ago

pavel_lishin 9y ago
> AMD shares surged as much as 7.2 percent to $11.77 Wednesday. Intel fell as much as 3.8 percent, the most since April, to $45.05. An Intel spokesman declined to comment. I have no real context for this, but is 7.2% considered a "soar"? And a 3.8% decrease seems like kind of not a lot, considering what's fucking happening here.
- haltingthoughts 9y ago
  The stock price is the present value of the future profits. Since this shouldn't have a huge effect beyond 4 years, that's saying profits for Intel in the short term would be down by 20 percent.
- hbosch 9y ago
  A 7.2% rise intraday is pretty big, especially for traders holding leveraged positions. If you're comparing to crypto markets then no, but generally speaking yes.
  - pavel_lishin 9y ago
    Thanks!
Havoc 9y ago
As a shareholder that's great. Concerned that this is a very fragile win though. I don't think there will be much real world fall out.
- db48x 9y ago
  If all Intel CPUs get 30% slower overnight, then there will be some fallout in the real world.
  - FBISurveillance 9y ago
    They might be 30% slower in virtualization and should be about 5-7% slower in real world usage. As a heavy user of the cloud I'm worried about my infra more than about my laptop: if my cloud setup gets even 7% slower overnight it won't be good to say the least, especially with lower-clock 2Ghz Skylake GCP CPUs. Those 5--7% will make me feel like I'm powered by Atom and it will be even worse for single-core bounded workloads in the cloud.
    - python-guy-vt 9y ago
      >They might be 30% slower in virtualization and should be about 5-7% slower in real world usage. Virtualization IS real-world-usage. This is going to damage Intel where it will hurt the most, the datacenter (which is largely virtualized using VMware, or Hyper-V). The Xeon CPU's have some of the best profit margins for Intel. If they erode away to Epyc (which is finally becoming available) this could be pretty good for AMD's, espically since AMD has said the the past few years there strategy is to go after the datacenter market.
    - tetraodonpuffer 9y ago
      there's other real world usage (DAWs, for example, where there is a ton of I/O for sample-based virtual instruments) which will likely be as significantly impacted as virtualization likely...
- swarnie_ 9y ago
  How you hold this stock is a mystery to me. With it bouncing between $10 and $15 constantly last year it just seems far to volatile. I'd be panic buying / selling every day to adjust which seems stressful... Maybe why its a favorite of /r/wallstreetbets
  - InTheArena 9y ago
    I bought a ton at 9 before the Ryzen announcement. The oscillation in the stock drove me up the wall, and I came to the conclusion that it’s just stupid to track single stocks, even when you know they have a great product, because the market is so irrational.
  - kongbtc 9y ago
    try trading crypto
    - swarnie_ 9y ago
      Ill stick to blue chips and paper trading. The NHS can only hand out so much heart medication...
  - Havoc 9y ago
    >/r/wallstreetbets Guilty as charged. >I'd be panic buying / selling every day to adjust which seems stressful... Just treat it as numbers on a screen rather than money. Keeps the emotions at bay.
    - deleted 9y ago
      [deleted]
  - meddlepal 9y ago
    You're doing it wrong if you're day trading stocks... dollar cost averaging is your friend when it comes to volatility and well if you're investing you're doing so because of long term belief in the company so it should be easy to hold and not worry about it.
- betterunix2 9y ago
  I am not so sure. Cloud providers will probably want to get this fixed and AMD would be a convenient alternative in the short term. I think the bigger risk is that rather than going with AMD, cloud providers will pursue a different CPU architecture altogether, especially in the long-term. There were plenty of things to dislike about x86 virtualization etc. before this mess.
NinjaKitten 9y ago
"Intel has a bug that lets some software gain access to parts of a computer’s memory that are set aside to protect things like passwords." Seems like very little got through to the media about the details regarding this flaws effects and costly workaround.
- grigjd3 9y ago
  Bloomberg is not going to focus on technical detail too much (at all) given their readership. Follow the link to the register for more detail.
  - Dotnaught 9y ago
    https://www.theregister.co.uk/2018/01/02/intel_cpu_design_flaw/ https://www.theregister.co.uk/2018/01/02/intel_cpu_design_fl...
- willvarfar 9y ago
  in this particular case, will the generalization help their readership? I actually think it will - it would be easy to give more accurate details that cause many readers to glaze over.
  - marmaduke 9y ago
    That was my reaction. How to ELI5 the risk in multitenant VM environment? It could steal passwords
    - blattimwind 9y ago
      > How to ELI5 the risk in multitenant VM environment? Some other guy paying EC2 steals your customers passwords by sheer force of will > How to ELI5 the risk in desktop PC? A piece of JavaScript in some 0x0 pixel iframe in a tab you're not even looking at stealing your passwords and SSH keys (Although nothing is proven in the latter regard, I wouldn't be per se surprised to see something in that direction once the exact nature of the issue is more widely known)
rwmj 9y ago
AMD must be pretty happy about this patch: https://lkml.org/lkml/2017/12/27/2 https://lkml.org/lkml/2017/12/27/2
- ihsw2 9y ago
  Not quite -- without his patch, the performance penalty will hit them too. Tom is proposing to be excluded from the proposed solution as it would hit AMD with collateral damage from the `X86_BUG_CPU_INSECURE` fix. I'm sure there are frantic emails claiming that AMD shouldn't be punished for Intel's mistake. EDIT: actually the fix will go out with 4.14.12 and 4.15rc7, both `X86_BUG_CPU_INSECURE` and AMD's addendum to be protected from the collateral damage.
  - dingo_bat 9y ago
    Maybe it's just me but that name is just too general. Is there no other conceivable way an x86 CPU can ever be "insecure"? Why'd they use something so vague? Is this part of the redaction?
- sena 9y ago
  Tom Lendacky works at AMD, so yes... :)
- hvindin 9y ago
  As long as the patch is all anyone notices then it looks great from AMD marketing. But I'm fairly confident (and a quick browse through the patched in the latest RC confirms at least one instance of this) where comments call out that AMD CPUs do things that should be considered bugs, so there's probably not going to be a lot of PR people telling the masses to read the source code. It's not exactly flattering to anyone. One thing I can definitely respect about the kernel developers is that they don't seem to make any effort to be nice about the fact that they need to deal with undocumented nonsense from vendors all round.
- uniformlyrandom 9y ago
  Not so sure about that. I am reading the merge commit, and comments are pretty interesting: --- a/arch/x86/include/asm/processor.h +++ b/arch/x86/include/asm/processor.h + * On Intel CPUs, if a SYSCALL instruction is at the highest canonical + * address, then that syscall will enter the kernel with a + * non-canonical return address, and SYSRET will explode dangerously. + * We avoid this particular problem by preventing anything executable + * from being mapped at the maximum canonical address. + * + * On AMD CPUs in the Ryzen family, there's a nasty bug in which the + * CPUs malfunction if they execute code from the highest canonical page. + * They'll speculate right off the end of the canonical space, and + * bad things happen. This is worked around in the same way as the + * Intel problem.
cma 9y ago
This isn't really too far out of proportion with normal daily fluctuations of AMD stock this year.
- zelos 9y ago
  Quiet, you're spoiling the narrative we're imposing on semi-random, chaotic events.
  - cma 9y ago
    To add another point: NVDA is up 5% and doesn't have the same direct competitive narrative. If money has to be spent rectifying the issue with new or more CPUs due to performance loss, that's less money available for spending on Nvidia GPUs. It might tip a few marginal applications in favor of eating the development costs to migrate to GPGPU, but that effect isn't likely nearly as high, especially if applications with lots of system calls are affected the most.
    - tedunangst 9y ago
      Chipotle is also up 5%. All these engineers are going to need lots of burritos to eat.
      - jabl 9y ago
        You're saying that gas in the cleanroom caused the chips to behave incorrectly? Excuse me while I go and invest in a company making rubber underwear.
        adjkant 9y ago
        Someone's gotta sell Burger King sesame seeds...
  - nopriorarrests 9y ago
    +8.79% AMD & -4.44% INTC does not look like a semi-random event anymore. Seems like wider audience is waking up to the news.
toyg 9y ago
This piece should be used in journalism schools. > Advanced Micro Devices Inc. surged [...] after a report that Intel Corp., its only remaining rival in the market for personal computer processors Ahh, so Intel is the only holdout against the dominant wave of AMD processors, right? facepalm.jpg
littlestymaar 9y ago
Interestingly enough, Intel and AMD market values are affected by this but the cloud provider aren't, which I find surprising.
- nomercy400 9y ago
  Do you pay for computing cycles or for a computing instance? If your cloud provider lowers its performance/efficiency by 30%, isn't it up to its customers to switch? But where to switch too? There's no choice among the big cloud providers. They all use Intel and AMD in varying amounts. As a cloud user you are stuck with Intel or AMD chips. Demand doesn't change, supply is lowered. Looking at it like this, it is more likely that demand for cloud resources will rise, and as such revenue of the cloud providers will as well.
  - FollowSteph3 9y ago
    My guess is that it will help cloud providers. In most cases they don’t guarantee x operations per second but rather the type of cpu you get. If that type now gets 30% less performance you’re most likely going to have to pay 30% more. Again the guarantee is not on operations per second but either exact processor, class of processor, or processor units.
- Waterluvian 9y ago
  Hm. Do cloud providers need to provide up to 30% more capacity for the same price, or do customers need to purchase up to 30% more capacity to get the same speed?
  - BoorishBears 9y ago
    This bug doesn’t magically chop all CPU performance down by almost a third.
    - cjbprime 9y ago
      What does it do, then? That is approximately what the mitigation patch does, according to early averages of perf changes.
dsign 9y ago
This is a clusterf/big deal. Beyond the security implications, it means that all companies paying for computing resources will have to pay roughly 30% more overnight on cloud expenses for the same amount of CPU, assuming that they can just scale up their infrastructure. I know that bugs happen and that there was nothing intentional on this one, but at times like this is hard to held at bay the temptation of claiming for a class lawsuit against Intel....
- wyager 9y ago
  > I know that bugs happen This isn’t an excuse for Intel consistently having terrible verification practices and shipping horrendous hardware bugs. From 2015: https://danluu.com/cpu-bugs/ https://danluu.com/cpu-bugs/ There have been more since then. I’ve talked to multiple people who work in intel’s testing division and think “verification” means “unit tests”. The complexity of their CPUs has far surpassed what they know how to manage.
  - zouhair 9y ago
    This is typically what happens when you go for a long time without real competition. You get way too comfortable and bad habits start to pile up.
    - spdy 9y ago
      Isn't why this problem even exits the exact opposite? Intel was losing on the mobile market and changed internal testing to iterate faster by cutting corners. Found a quote: "We need to move faster. Validation at Intel is taking much longer than it does for our competition. We need to do whatever we can to reduce those times… we can’t live forever in the shadow of the early 90’s FDIV bug, we need to move on. Our competition is moving much faster than we are".
      - mannykannot 9y ago
        That is a very interesting perspective, and as far as I know it is correct, though perhaps Intel's situation in the mobile market was exacerbated by complacency?
dzink 9y ago
Didn’t the Intel CEO just sell half of his shares/options? If he knew about these issues isn’t that illegal?
- mizzack 9y ago
  Looks like Krzanich sold $39.4M of stock on 11/28. Hard to say when the top brass knew about this flaw. https://finance.yahoo.com/quote/INTC/insider-transactions?p=INTC https://finance.yahoo.com/quote/INTC/insider-transactions?p=...
  - ehsankia 9y ago
    I don't understand this attitude that "top brass might not know about it". He's the CEO, isn't his entire job to know what's going on in the company? I know we get this idea that rich people just sit back and take in the money, but isn't the reason they are paid so much in the first place because they have in theory a big responsibility on what happens in the company?
    - mizzack 9y ago
      You're putting words in my mouth. I didn't say he didn't know about it. I said we don't know WHEN he first knew about it, which is important in the context of insider trading.
      - philipov 9y ago
        Even if he knew about it, if it was more than 6 months in advance and he follows all the legally-mandated protocols for setting up a regulated stock trade, isn't he safe? The marvel is that somehow the news was kept from hitting the media until he had finished his trade, and then was revealed immediately after the transaction was complete. I wonder how that coincidence happened.
        mizzack 9y ago
        The SEC would need to be able to show that Krzanich initiated that rather large selloff based on this inside, privileged info. Given the short document retention policies in place at most companies, this would presumably prove pretty difficult.
emn13 9y ago
This piece is (IMNSHO) trash. It's trying to stare into some crystal ball guessing at the cause of market fluctuations; but there's no real evidence they're right. Not to mention it's pretty misleading about technical stuff, saying e.g. "Chip design errors are exceedingly rare. More than 20 years ago, a college professor discovered a problem with how early versions of Intel’s Pentium chip calculated numbers." So, they imply that chip design errors are once in a few decades kind of things; that's just complete nonsense. Chip design errors are common most just aren't this bad. Furthermore, they imply this stock change is anything more than temporary volatility; given the tiny, tiny changes so far that's just premature. Perhaps the stocks will adjust more in the future - we'll see. But as of now, this piece is financially and technically pretty misleading.
- mikeokner 9y ago
  Bloomberg? Trash? I'm shocked (I'm not).
- grendelt 9y ago
  > It's trying to stare into some crystal ball guessing at the cause of market fluctuations; but there's no real evidence they're right. Welcome to the world of business reporting.
  - dnautics 9y ago
    I think it's pretty clear in this case. Plenty of people here in hn-land were talking about Intel/AMD short/long positions starting in the afternoon yesterday and word has gotten around.
    - emn13 9y ago
      Talk is cheap; investing perhaps less so. The asserted "soaring" stock price simply hasn't happened. The 7% rise they name as "soaring" is not a soar for a stock this volatile: https://www.bloomberg.com/quote/AMD:US https://www.bloomberg.com/quote/AMD:US - just look at the graph over the past year; value changes in excess of 50% happened several times. To be clear; I'm not saying this increase won't stick, just that bloomberg is pretending they're reading this from the numbers, not merely expecting it to occur. It'd be fine to say you might expect the stock to trend higher. But pretending you can look at that noisy line and say the current 7% increase is statistically significantly higher in a humanly relevant way is just hogwash. Obviously you might expect the stock to soar. It may well happen. It just isn't visible in the data they present; the article is simply click bait (or worse, market manipulation).
cesarb 9y ago
This article appears to be jumping the gun. It presents the defect as a fact, but aren't we still in the "rumor" phase (other than perhaps the few who have early access to embargoed details)?
- bryanlarsen 9y ago
  Stocks tend to move a lot more on rumour than they do on fact.
  - blackflame7000 9y ago
    Trading would be a lot easier if you could wait till the facts come out
- pixl97 9y ago
  https://twitter.com/brainsmoke/status/948561799875502080 https://twitter.com/brainsmoke/status/948561799875502080 Doesn't seem to be much of a rumor.
lafar6502 9y ago
But is the security Bug exploitable in any realistic way?
- blattimwind 9y ago
  https://twitter.com/brainsmoke/status/948561799875502080 https://twitter.com/brainsmoke/status/948561799875502080
  - cypherpunks01 9y ago
    What does that output mean? He was able to look up an address that was used in a speculative execution or something?
    - blattimwind 9y ago
      He successfully read from kernel memory, the first two bytes from the syscall table to be precise. The first entry is sys_read (on x86-64 anyway) and the first field is the address. That's why he shows the full address in the next line; the PoC exploit read the lower 2 bytes of that address.
blattimwind 9y ago
And we got a bingo https://news.ycombinator.com/item?id=16061364 https://news.ycombinator.com/item?id=16061364
dsign 9y ago
Here are some numbers quantifying the problem. Big caveats apply as they are very preliminary, but the hit due to the software patches looks extremely significant: https://www.phoronix.com/scan.php?page=article&item=linux-415-x86pti&num=2 https://www.phoronix.com/scan.php?page=article&item=linux-41...
- 0xcde4c3db 9y ago
  Superficially, it seems like the performance hit mostly scales with IOPS or transactions per second, which might have some pretty serious implications for performance/dollar in the kinds of intensive back-end applications where Intel currently dominates and AMD is trying to make inroads with EPYC.
  - mtanski 9y ago
    As I mentioned in the other thread yesterday database and database like applications are going to be hit particular hard. Even more so on fast flash storage. Double whammy compared to apps just doing network IO. And while databases try to minimize the number of syscalls they still end up doing a lot of them for read, writeout, flush.
    - surajrmal 9y ago
      Don't flash devices use nvme (eg userspace queues) now and avoid the kernel all together for read and write operations? Shouldn't they have no impact?
      - kllrnohj 9y ago
        Not by default they don't. That only works if you're willing to dedicate that entire physical drive to a single application anyway.
        mtanski 9y ago
        In the future this possible on Linux with the filesystems that support DAX. Currently this all pretty experimental with lots of work being done in this space in the last two years. But this will require you to have the right kind of flash storage, right kind of fs, right kind mount options, and probably a different code path in userspace for DAX vs traditional storage. So we're a little ways away from this.
rayiner 9y ago
Can someone help me understand why this is such a big deal? This doesn’t seem to be a flaw in the sense of the Pentium FDIV bug where the processor returned incorrect data. It doesn’t even seem to be a bug at all, but a side channel attack that would be almost expected in a processor with speculative execution unless special measures were taken to prevent it. And it doesn’t seem like it can be used for privilege escalation, only reading secret data out of kernel memory. It seems pretty drastic to impose a double-digit percentage performance hit on every Intel processor to mitigate this.
- mikeash 9y ago
  If “reading secret data out of kernel memory” translates into “read the page cache from a stranger’s VM that happens to be on the same cloud server” then this could be worse than Heartbleed.
  - 0x0 9y ago
    Or maybe random javascript in the browser can stroll upon your ssh private key in the kernel's file cache... and so on.
    - mikeash 9y ago
      Excellent point, I didn't think about the implications for stuff like JavaScript.
  - deleted 9y ago
    [deleted]
- lmm 9y ago
  If you can read kernel (and hypervisor) memory then it seems like a very small step from that to a local root vulnerability - e.g. forge some kind of security token by copying it. There's an embargoed Xen vulnerability that may be related to or combine with this one to mean that anyone running in a VM can break out and access other VMs on the same physical host. That would be a huge issue for cloud providers.
rietta 9y ago
Just built a new Linux workstation the day after Christmas with a 4.2 Ghz i7. In hindsight I should have bought a AMD Ryzen! Glad the computer I built my dad was an AMD.
- bandris 9y ago
  The following story might comfort you somewhat. Someone had bad luck with Ryzen: http://erlang.org/pipermail/erlang-questions/2018-January/094580.html http://erlang.org/pipermail/erlang-questions/2018-January/09...
tapoxi 9y ago
I don't know much about CPUs, so what prevents a fix via microcode update?
- db48x 9y ago
  No one outside of Intel knows enough about Intel's microcode to answer that question, especially since we don't know the full details of the problem.
- dannyw 9y ago
  The bug seems to be revolving around speculative execution. It seems like that is a silicon thing, not a microcode thing.
  - zimmerfrei 9y ago
    The bug seems to be about the processor leaving speculatively read privileged data in some of the caches, even if execution failed [1]. If so, clearing all caches upon a failed privilege check sounds like something within the capabilities of microcode and without unreasonable performance penalties. Unfortunately, that would not explain the complex in-kernel fix... [1] https://plus.google.com/+KristianK%C3%B6hntopp/posts/Ep26AoAZxxd https://plus.google.com/+KristianK%C3%B6hntopp/posts/Ep26AoA... EDIT: what remains in cache is not "speculatively read privileged data" but more "unprivileged data whose address is correlated to speculatively read privileged data". Retrieving later such address allows one to infer what the privileged data was. Still, the point about clearing all caches as countermeasure holds...
  - rphlx 9y ago
    It's likely they could disable speculative execution in its entirety, either in ucode or UEFI, but that would harm many compute-intensive workloads by 5-10% or more, so my guess is that somebody decided to push this page table mitigation instead, taking the hit on the syscall/hypercall side as that's perceived as "less bad overall".
- fulafel 9y ago
  We don't know if anything does, but it could be that an effective microcode update (eg turning OOO off) would slow down the CPU more than the software fix.
AnIdiotOnTheNet 9y ago
Honest question, does the performance hit from this patch actually hit Intel's best processors enough to make them perform worse than AMD's best? I don't keep up on these kinds of metrics, but I'm under the impression that Intel still dominated CPU benchmarks berfore this issue, so if this question is answered in the negative then I doubt it will affect Intel very much.
- Symmetry 9y ago
  Intel hasn't been dominating in CPU benchmarks since AMD's new Zen architecture came out. They still have a ~10% lead for gaming but there are as many usecases where AMD is the best choice as there are where Intel is. So if this bug is slowing down Intel but not AMD servers by 10% then suddenly choosing AMD is a no-brainer.
- db48x 9y ago
  It depends on what your program is doing. If your program uses a lot of syscalls, then it'll be slower. If it hardly uses them at all, then it won't be as affected.
  - AnIdiotOnTheNet 9y ago
    Yes, but that wasn't the question.
- deleted 9y ago
  [deleted]
- BuckRogers 9y ago
  It's too soon to say. There's still variants Meltdown/Spectre that aren't fixed yet. The other guy was correct that it probably depends on your workload, but in a couple months after all the dust has settled on this and we have a comprehensive review, my guess is yes AMD is going to take a commanding lead. Spectre affects every modern CPU, and performance impact will be marginal. Meltdown affects Intel-only, and the performance impact will be significant. Here's Fortnight's preliminary server results[0]. Once everything[1] is patched up it's just going to get worse for Intel. Ryzen was already fast though and had superior SMT (Hyperthreading) efficiency than Intel prior to this bug (~10%). This is going to take a serious toll on Intel's single-threaded performance advantage (~10% from IPC, 25% clock frequency advantage). My advice is to stick with Ryzen/Threadripper/Epyc. [0]https://www.epicgames.com/fortnite/forums/news/announcements/132642-epic-services-stability-update https://www.epicgames.com/fortnite/forums/news/announcements... [1]https://gist.github.com/woachk/2f86755260f2fee1baf71c90cd6533e9 https://gist.github.com/woachk/2f86755260f2fee1baf71c90cd653...
bla2 9y ago
The bottom of https://danluu.com/cpu-bugs/ https://danluu.com/cpu-bugs/ suggests that AMD isn't any better, so this is likely just short term.
- mtgx 9y ago
  Since that article came out, AMD built a whole new CPU architecture, with the help of the guy that designed the K8, too.
- dboreham 9y ago
  They don't have to be better to benefit from purchasers wanting to diversify their plant across two rather than one CPU vendors.
- yborg 9y ago
  This specific issue is very relevant to cloud providers, who are the guys that buy thousands of CPUs, and doesn't affect AMD's current generation. I don't know what Intel's profit breakdown is, but I suspect it is heavily weighted to the high-end server chips where they have had no real competition for many years.
hungerstrike 9y ago
So is today a good day to buy Intel stock?
- jacksmith21006 9y ago
  Would say no. INTC has not been hit yet from this. Cramer this morning indicated the issue is unsubstantiated.
- chasd00 9y ago
  don't try to catch a falling knife. Let it settle, give it a week or so then see where it is.
Abishek_Muthian 9y ago
I'm worried about the performance impact on low end intel chips like Atom/Celeron found in Chromebooks.30% hit will make computing on those platforms miserable. Talking about chromeOS, is there any speculation about the impact of bug? Does it's hardened sand-boxing techniques put it in a better position even if KASLR is compromised?
- mtgx 9y ago
  Honestly, that serves Google right. I've been saying it for years how stupid Google is for encouraging 99% of Chromebooks to be powered by Intel chips (even more than Windows machines), when the Chrome OS itself is architecture-agnostic (for the most part). It was just stupid through and through. Even today we see ARM coming to full versions of Windows, but Google is still kicking it with Intel CPUs.
- dannyw 9y ago
  The bug isn't really KASLR, it's more about reading kernel memory from userspace through side channel attacks of speculative execution. KASLR is/was the cover for the kernel patches, to avoid disclosing the real bug.
  - Abishek_Muthian 9y ago
    The comment in linux kernel mailing list, does pin point attacks using 'speculative execution' but isn't access to kernel memory space by any means a potential hazard to the security depending upon KASLR?
  - svet_0 9y ago
    Indeed, kernel memory read seems more likely than address only read, the memory probably needs to be cached (in L1 maybe?). Attack is a timing attack as can be seen in this very interesting tweet - https://twitter.com/brainsmoke/status/948561799875502080 https://twitter.com/brainsmoke/status/948561799875502080
jamisteven 9y ago
Literally just read here yesterday how the CEO dumped majority of his shares. So Shiesty. https://news.ycombinator.com/item?id=16055851 https://news.ycombinator.com/item?id=16055851
- prewett 9y ago
  Don't be so quick to blame. You might have read it yesterday, but he reported it on Nov 29, which means that the transaction happened either within two days prior or about a month, depending on if you believe the SEC's website or NASDAQ's website. But the question isn't when he sold his shares, the question is when did he put in the order to sell those shares. Those guys put their buy/sell orders in months in advance because of exactly this problem. Or maybe he had a limit order in--the beginning of November was a 2-year high, so you could easily imagine a limit order executing about then.
  - joncrane 9y ago
    Evidence shows this bug was known in November. It only blew up this week.
    - jacksmith21006 9y ago
      Probably even earlier.
- matt4077 9y ago
  Don't spread conspiracy theories. It's absolutely impossible for the most visible executive of one of the largest firms to engage in insider trading in such an obvious fashion and get away with it. At this level, there is always a paper trail of who knew what when. There are internal and external audits if any suspicions arise. Plus there are sever penalties, both civil (in the employment contract) as well as criminal. Intel's CEO is without a doubt in the 9- or 10-digit range of personal wealth. Risking time in jail to avoid a 10% loss on his stock holdings would be a terrible decision even if they considered the chance of being caught was low.
TheSwordsman 9y ago
I wonder what implications this will have on those who run Intel in their gaming rigs. I'm due to refresh, and _was_ gonna invest in Intel as my CPU. But this seems pretty damning for that. I assume the system calls to interact with the GPU, or to do any sort of I/O, are going to incur the performance overhead. So rendering frames, reading/writing from the network, and loading assets from the disk could all cause issues. And this is just for gaming. Anyone using a cloud provider that's running on Intel needs to worry about similar things. What a nightmare...
- a_humean 9y ago
  Apparently zero effect: https://www.phoronix.com/scan.php?page=news_item&px=x86-PTI-Initial-Gaming-Tests https://www.phoronix.com/scan.php?page=news_item&px=x86-PTI-...
  - QShift 9y ago
    Well, that's for Linux. We don't exactly know what effects such patches would have on other platforms yet. (do we?)
- rnhmjoj 9y ago
  To make things worse there is an increasing number of games running DRMs like Denuvo and VMProtect that cause a significant performance hit. I think these will be more heavily affected by the patch.
  - obscurantist 9y ago
    I don't get why more developers don't take notes from CD Projekt.
- chrisper 9y ago
  Sadly I just bought an 8700k last week. Great CPU until next Tuesday? (Windows Patch Day) Though even if I lose some percentage, it will still outrun AMD on single core applications (and probably also multi core ones).
teekert 9y ago
Perhaps a bit off topic but I have an (Asus) laptop with a recent Intel chip running Linux (Solus) and I have no idea how I am to deal with all these CPU bugs... Any pointers?
- marcolussetti 9y ago
  The patch isn't out yet. Once it's merged in, your distribution will release patches you can install on the normal way you update your distribution.
  - teekert 9y ago
    Ah, ok, so Intel Management engine patches are also distributed in the Linux Kernel then?
- dna_polymerase 9y ago
  Just sit and wait, it's all too fresh to make solid statements on this. Maybe aside from, think twice before buying Intel again.
  - teekert 9y ago
    Definitely, sadly the new AMD Ryzen's were not in laptops at the moment I needed one. To be honest, a high end ARM laptop would also have been nice, but as it is, Intel is king on >8 hrs battery life machines with decent performance.
GuB-42 9y ago
It seems like it is all thanks to this patch: https://lkml.org/lkml/2017/12/27/2 https://lkml.org/lkml/2017/12/27/2 If I understand well, there may be a serious bug in some x86 CPUs but nothing is known publicly. Presumably, all current Intel CPUs are affected and none by AMD but we can't really be sure, it is still a secret. It is impressive how a simple, yet to be justified patch has so much influence. It opens up new ways of manipulating the market...
- markonen 9y ago
  But it's not just a random patch posted to LKML, it has also been reviewed and merged to tip. That means it has been justified, just not to you.
runesoerensen 9y ago
Related discussion https://news.ycombinator.com/item?id=16052451 https://news.ycombinator.com/item?id=16052451
throwawazqq 9y ago
AMD stock price was higher in July and October. It increased a tiny bit and does not constitute “soaring”.
- take4 9y ago
  It's currently +10%, which absolutely is "soaring".
chrisper 9y ago
If you look here: https://www.computerbase.de/2018-01/intel-cpu-pti-sicherheitsluecke/ https://www.computerbase.de/2018-01/intel-cpu-pti-sicherheit... (Sorry it is German) But if you scroll down to "Windows-Benchmarks: Anwendungen" you can see that most applications do not have any performance hit with the Windows patch. Only M.2 SSD seem to be affected.
- nopriorarrests 9y ago
  All their tests are CPU-bound, not IO-bound, namely -- archiving, rendering, encoding video. Performance degradation happens with transactional, IO-bound tasks (think noSQL databases, ad serving, trading)
- dingo_bat 9y ago
  It is possible Microsoft has mitigated the issue in a way that has much lesser performance impact. Maybe they had a highly tuned feature to enable kernel page separation already coded but disabled. I won't be surprised if even the Linux implementation is tuned to the absolute limit in the coming months.
  - chrisper 9y ago
    I think so too. It also seems the Linux version right now is in a "get it to work, optimize later" state.
    - amluto 9y ago
      If you know how to materially optimize it, I'm all ears.
  - pvdebbe 9y ago
    > I won't be surprised if even the Linux implementation is tuned to the absolute limit in the coming months. To me, this sounds like unnecessary work if Intel is coming up with a microcode patch within a few months.
secfirstmd 9y ago
I wonder what the value of this chip flaw would be to the NSA?
moomin 9y ago
"Chip design flaws are exceedingly rare." Writes someone who's never seen an errata.
kylehotchkiss 9y ago
Does anybody know if the 30% performance reduction would apply to Macbook pros from within the past 2 years?
- Brockenstein 9y ago
  They run Intel CPUs made within the last ten years so would be subject to this issue. But the performance hit is really dependent on the computing that you're doing. It's not a guaranteed 30% or a guaranteed 5%. Are you doing a lot of really CPU intensive tasks that make a lot of syscalls? Most people aren't. If you are, you'll probably feel that pain. And if you're not, you probably won't notice a difference. And if you don't know you can either research if what you're doing typically is going to be affected, or wait and see.
  - cookiecaper 9y ago
    > They run Intel CPUs made within the last ten years so would be subject to this issue. Do we know that? There is a lot of speculation but the embargo is not lifted yet afaik. There are obviously elements of this that are remaining intentionally obscured pending embargo expiry (redacted comments), so it could be that a smaller contingent of chips are affected and no one is bothering to correct the damage/limit the patch only to applicable components so that the cat doesn't get out of the bag too soon (side benefit: so that an extensive emergency fix like this can be widely tested before it's applied to a relatively limited set of hardware). Seems just as valid as any other speculation to me.
  - bluedonuts 9y ago
    Do we know that the kernel used in OSX is vulnerable at all? I haven’t found any discussion of it.
aeleos 9y ago
What started as speculation about recent kernel developments has really turned into a shitshow for Intel. I can't imagine they thought that these massive changes would get through without anyone finding out. However, there really isn't any other better option for Intel, so it seems they are in a lose lose situation with no way out. Or at least a way out that doesn't involve them going bankrupt trying to repair the damage.
- mandeepj 9y ago
  > going bankrupt trying to repair the damage. I think you took it a bit too far. May be, I am missing something. Is it really that bad?
  - agumonkey 9y ago
    Bankrupt might be a wild guess, but it is one of the largest blunder I can recall. 12 years lineup affected, large penalty fix, hardwired. Intel is gonna enjoy a healthier diet for a while.
  - aeleos 9y ago
    There are at least tens of thousands, possibly hundreds of thousands of Intel CPUs in just datacenters around the globe. Most of which are controlled by companies that make a lot of money and paid a lot of money to intel for their CPUs. And I doubt that they will just take this kind of hit to their performance sitting down. And thats just datacenters, not to mention all the personal computers (mine included) that will suffer. At this point, if this is real, its not a question of if it will cost them, its how much. And considering the sheer numbers of the products affected, I can't imagine it will be cheap. I am not saying that I think they are going to go bankrupt, and I would be surprised if they did, but a 30% percent performance hit is multiple generations of fallback, and considering the importance of computing today (and the number of different entities that are affected by this) I find it hard to imagine that it will be just taken sitting down.
johnjones4 9y ago
So is this sort of issue more likely to occur on a non-RISC chip because of added complexity? I know extremely little about microprocessor design beyond the 101 knowledge from college so forgive my ignorance.
- amaranth 9y ago
  I think this could occur on any CPU that doesn't have a separate TLB for kernel mode and has speculative execution. So far it looks like it only occurs on Intel's CPUs but I don't think that has anything to do with RISC vs CISC. I believe Linux was at least looking at applying this change to arm64 as well and this is likely going to lead to a design change in RISC-V to avoid having issues like this so it can happen to RISC designs as well.
gagabity 9y ago
Is there any real danger for desktop users? We should be allowed to skip this patch if we dont want it, I would rather take the risk than the performance hit.
- zzzcpan 9y ago
  For desktop users there should not be any noticeable performance degradation. But they are also likely the ones in the most danger, since they execute random code in their web browsers.
  - blackflame7000 9y ago
    I might be wrong, but shouldn't browser makers be able to prevent executing scripts from exploiting the low level memory manipulation this requires?
  - Dylan16807 9y ago
    Random code that makes direct kernel calls? Or is that not necessary?
hellbanner 9y ago
This is different from the intentional backdoor, Management Engine?
- chrisper 9y ago
  Yes. This is far worse.
  - hellbanner 9y ago
    I see - so this is more accessible? We're all fucked, then?
    - chrisper 9y ago
      The "fear" with ME is more that governments or someone like that could spy on us... (not really a "threat" to most people in Western Countries). But still better to get rid of it. Not an imminent threat per se. This bug is a true security bug that has been lurking around for 10 years... and it could have been already abused. This is double scary because this attack does not leave any traces behind and it allows any application to pretty much enter God Mode (this is the worst case scenario of a security situation (hence the name meltdown (like nuklear meltdown is the worst case situation in a nuclear power plant)). This bug is also bad because in certain situations the fix of this bug causes severe peformance penatlty. You are only fucked if you don't update your OS.
      - hellbanner 9y ago
        OS updates will fix this - but the bug remains on the chip, right? Hm, I guess I'll check for updates =)
joering2 9y ago
It must be serious when stock of this size goes 5% down now... https://www.google.com/search?q=intel+stock https://www.google.com/search?q=intel+stock Edit: AMD 8% up: https://www.google.com/search?q=amd+stock https://www.google.com/search?q=amd+stock
pashabitz 9y ago
I just read yesterday that the CEO sold all his stock except for what he's required to hold by corporate bylaws, a short while ago.
- pas 9y ago
  it was an automated sale
newtanjoy 9y ago
I request all my friends. Search my web site at NFL. I will be of great benefit to you for a search. Kindly you search once. You will not have any problem. There are site security. https://livesporthdtv.com https://livesporthdtv.com
microcolonel 9y ago
This is not a PR nightmare, it's a technical competitive nightmare. For many workloads, last-gen AMD server chips are now competitive with current-gen Intel server chips; and the current generation already had a lot in its favour. There's no amount of PR fluff that can save Intel from this, they can only release a new design with this fixed and hope they don't lose too much ground in the mean time.
throwaway613834 9y ago
Will there be any way to disable or block the upcoming patches and keep the performance for those of us who really just don't have any reason to care about inter-process information leakage on our personal computers? Edit: I'm (also) wondering about Windows, in case anyone knows yet.
- JoachimSchipper 9y ago
  Yes, the work-around can be disabled via a boot-time argument.
  - throwaway613834 9y ago
    Thank you! Do you know if this will be true for Windows as well, or just Linux?
- pixl97 9y ago
  Just don't do this if you have PII, HIPAA, or PCI data on your computer.
  - deleted 9y ago
    [deleted]
  - stusmall 9y ago
    Even then and if they don't care about their own safety, they should patch for the rest of us. Who knows how long until their unpatched system will get pwned from some other vulnerability and end up in some botnet just spreading the pain.
- uniformlyrandom 9y ago
  From the merge commit: +#ifdef CONFIG_PAGE_TABLE_ISOLATION +# define DISABLE_PTI 0 +#else +# define DISABLE_PTI (1 << (X86_FEATURE_PTI & 31)) +#endif PS - MSFT has not published relnotes, so we do not know yet. We'll find out soon enough.
  - 9y ago
nopriorarrests 9y ago
Can anyone with better knowledge ELI5 to me -- to fix this bug, are cloud providers have to patch only hypervisor machines, or guest boxes as well? And if fix is applied to hypervisor, will performance degrade on guest boxes as benchmark suggests? Thanks!
- dingo_bat 9y ago
  Guest OS shouldn't be an issue, from what I understand. As long as the hypervisor memory is separated, you're good.
- chrisper 9y ago
  Yes it will affect your VM as it's the host CPU that's affected.
qubex 9y ago
I’m not (yet) clear on if/how this impacts aarch64 (ARM architecture) chips, the distinction between how it affects Intel vs. doesn’t affect AMD reminds us of a fundamental lesson we seem to have conveniently forgotten: monocultures of anything are bad. We need diversity and diversification in order to have reasonable amount of robustness in the face of unknowable, unpredictable risks. I’m wondering whether ARM chips are affected if they are whether they are uniformly affected or whether it depends on vendor implementation choices.
- thraweigh666 9y ago
  >We need diversity and diversification in order to have reasonable amount of robustness Ironically, in human populations it produces the opposite effect.
  - adornedCupcake 9y ago
    Why?
    - edraferi 9y ago
      More diverse population—> lower trust —> less social will to support each other.
      - crimethink2017 9y ago
        This might well be true, see e.g. [1]. An obvious irony is that those who are most happy with Intel's "velocity"-led culture, and the more general lack of diversity in the x86 CPU market, are probably also the most likely to reject this idea (that human diversity might have negative effects) outright. ____ [1] https://www.mpg.de/19440/Diversity_interaction_solidarity https://www.mpg.de/19440/Diversity_interaction_solidarity
      - cryptonector 9y ago
        So we should be tribal societies, then? (I.e., endogamous. As in cousin marriage.)
troncd 9y ago
My hot take is that we will see a Mirai / qbot variant targeting consumer laptops and VPSs very, very soon with this exploit. Could cause a lot more trouble than baby monitors.
cyberpimp 9y ago
Intel went wrong when it invested in building factories in a zionist nation
deleted 9y ago
[deleted]
jrochkind1 9y ago
Best summary I've found for the somewhat technical but not hardware-or-low-level-hacker reader is arstechnica. https://arstechnica.com/gadgets/2018/01/whats-behind-the-intel-design-flaw-forcing-numerous-patches/ https://arstechnica.com/gadgets/2018/01/whats-behind-the-int...
- noxecanexx 9y ago
  My head is still spinning writing an OS is a BIG DEAL!!!!
dom96 9y ago
Is it just me or was this post's title changed?
- neospice 9y ago
  It's not you, it used to be shorter.
jokoon 9y ago
Is that me or there is an increase of critical security flaws over the last 5 years?
mlrhazi 9y ago
Would the perf hits introduced by the Linux/Windows patches also be paid by kernels of guest VMs? or just the hosts/hypervisors?
laythea 9y ago
When pondering whether I should be grumpled about this situation or accept it as "just how it goes", I wonder if Intel would be OK with me giving them up to 30% less money after agreeing to 100% before walking out the Intel shop without prejudice.
- matt4077 9y ago
  I don't know if their will be a recall/class-action lawsuit/whatever. But clearly there is a difference between making a mistake in what must be one of the most complicated consumer products on the one hand, and intentionally violating the terms of an agreed-upon contract? Tl/DR: Intent matters.
  - laythea 9y ago
    Good point and agreed. This will cost them, and clearly was a mistake.
juanmirocks 9y ago
Considering the late Intel problems, Apple is going to be even more tempted to design its own CPUs/GPUs for the mac. What do you think, is this realistic?
jmull 9y ago
> The security updates may slow down older machinery by as much as 30 percent, according to The Register. I will eat my hat if that 30% number holds up.
runesoerensen 9y ago
Intel response https://newsroom.intel.com/news/intel-responds-to-security-research-findings/ https://newsroom.intel.com/news/intel-responds-to-security-r...
- itsmemattchung 9y ago
  > Recent reports that these exploits are caused by a “bug” or a “flaw” and are unique to Intel products are incorrect. Based on the analysis to date, many types of computing devices — with many different vendors’ processors and operating systems — are susceptible to these exploits. I wonder how this will play out since it seems that everyone, apart from Intel, view this issue as a "flaw".
- mizzack 9y ago
  > Intel believes these exploits do not have the potential to corrupt, modify or delete data. No, you can just read data you shouldn't be able to. > Intel is committed to product and customer security and is working closely with many other technology companies, including AMD, ARM Holdings and several operating system vendors, to develop an industry-wide approach to resolve this issue promptly and constructively. Let's try to drag AMD and ARM into the mud with us. > However, Intel is making this statement today because of the current inaccurate media reports. "Fake news!" Well you can't fault the PR folks for trying to spin it. They had to say something.
  - ovao 9y ago
    I'd be curious to know which media reports Intel actually finds inaccurate. I'm sure there are some out there, but I suspect most reports aren't inaccurate in ways that significantly deviate from the overall message that Intel's products have a relatively serious security flaw. Making a blanket statement that implies all the reporting is inaccurate is very disingenuous. Dragging AMD's and ARM's names into this is completely inexplicable to me however.
- dang 9y ago
  Now discussed at https://news.ycombinator.com/item?id=16064545 https://news.ycombinator.com/item?id=16064545.
Pica_soO 9y ago
Contracts with fixed guaranteed cloud performance rates just became very valuable.
matt4077 9y ago
This reminds me of a storyline from The West Wing, where a company that was Intel in everything but the name found a bug in their chip. As it threatened the company's existence, the President refused to consider guaranteeing a loan because the company had been a contributor, and any help could potentially appear as corruption. How quaint such considerations seem today...
rdl 9y ago
I wonder how Intel will deal with this. If I were Intel, I'd offer free replacements for at-par performance, and potentially tiny cash payment for upgraded performance. Assuming the marginal cost to produce chips, especially older/slower ones, is very low, the only real cost to them is losing out on potential upgrade sales which would have happened organically, for a while. However, doing this keeps Qualcomm/ARM and AMD from making massive inroads into the market. As well, it would be a great way for Intel to accelerate adoption of their newer technologies, causing even greater lock-in (you could assume a much higher percentage of users will have a feature) This all works great for socketed CPUs (still common for servers/cloud). For embedded, where CPU is more likely non-replaceable even if socketed) CPU peak performance probably doesn't matter as much -- maybe do a discount coupon? Or work with equipment vendors to subsidize upgrades. Laptops and non-technical end users (who couldn't swap their own CPU) probably don't care as much but also don't have the ability to upgrade. A rebate/upgrade program would work, or a substantial cash payment. Doing it as e.g. $50 cash or $250 toward your next Intel-CPU laptop would be interesting. Intel is rich, the market leader, incumbent across multiple segments, etc., so they really should go overboard on their response.
- asah 9y ago
  rofl, you don't simply upgrade chips installed in 1+B servers and laptops and network devices and embedded systems. In fact, statistically-few devices-containing-a-CPU are designed to ever have their CPUs replaced. At the last, you replace the motherboard, which requires coordination with the vendor. Consider cars - good luck coordinating that recall!
  - rdl 9y ago
    Devices containing multiple security levels/distinct users, and where performance matters the most, are generally socketed-CPU servers. For other devices, if they're security critical and can't be addressed through software, you can upgrade them at the board or device level early. This has already happened in embedded devices due to the C2000 timer problem. Assuming there is a software mitigation which has a performance impact, sophisticated users would be capable of adding more capacity (if it's a horizontal scale type workload), upgrading early (if they had extra capacity for futureproofing), or spending money, potentially subsidized by Intel, to upgrade immediately. If there's no mitigation, upgrade early, or rearchitect application (moving away from shared security domains on single boxes, etc.)
blackflame7000 9y ago
Does anyone have insight on the implications this vulnerability might have on Remote Execution. Is controlling the access to the physical machine sufficient?
jhallenworld 9y ago
After the fix, will device drivers still have the user process mapped into their address space? If not, then the fix may expose many driver bugs (where driver accessed user space directly instead of through copy_from_user()), making the whole thing even more painful.
mastazi 9y ago
I am confused, as far as I know two different vulnerabilities have been discovered, Meltdown and Spectre; while the first one affects only Intel CPUs, the second one affects AMD and ARM as well. So how come I'm not seeing much talk around about the latter? Is it because it is harder to exploit? I didn't have a chance to read the 2 papers so I would appreciate a TL;DR. I am a SW developer working with high level languages; security and OS development are not my specific fields so while I don't need an ELI5 I would appreciate a sufficiently "layman's terms" explanation.
- mastazi 9y ago
  Replying to myself: most of the info can be found here * https://googleprojectzero.blogspot.com.au/2018/01/reading-privileged-memory-with-side.html https://googleprojectzero.blogspot.com.au/2018/01/reading-pr... * https://www.theregister.co.uk/2018/01/02/intel_cpu_design_flaw/ https://www.theregister.co.uk/2018/01/02/intel_cpu_design_fl... * https://meltdownattack.com/ https://meltdownattack.com/ * https://www.amd.com/en/corporate/speculative-execution https://www.amd.com/en/corporate/speculative-execution * https://newsroom.intel.com/news/intel-responds-to-security-research-findings/ https://newsroom.intel.com/news/intel-responds-to-security-r... TL;DR is that mitigation for Spectre on an OS level is not very expensive in terms of performance while Meltdown mitigation, which affects only Intel, will have a performance penalty between 5% and 30%
perseusprime11 9y ago
What is more interesting to me is the news that came before this: Intel CEO selling his stock. I did not read the news but I got a notification on the phone through one of the many news apps on my phone. For a moment, I wondered why he sold off his stock.
Vkkan2016 9y ago
Patch on Azure already started rollout today on their affected VM's
aagha 9y ago
I would love an ELI5.

1026 points by el_duderino 9y ago

> AMD shares surged as much as 7.2 percent to $11.77 Wednesday. Intel fell as much as 3.8 percent, the most since April, to $45.05. An Intel spokesman declined to comment. I have no real context for this, but is 7.2% considered a "soar"? And a 3.8% decrease seems like kind of not a lot, considering what's fucking happening here.

haltingthoughts 9y ago
The stock price is the present value of the future profits. Since this shouldn't have a huge effect beyond 4 years, that's saying profits for Intel in the short term would be down by 20 percent.
hbosch 9y ago
A 7.2% rise intraday is pretty big, especially for traders holding leveraged positions. If you're comparing to crypto markets then no, but generally speaking yes.
- pavel_lishin 9y ago
  Thanks!

Havoc 9y ago

As a shareholder that's great. Concerned that this is a very fragile win though. I don't think there will be much real world fall out.

db48x 9y ago
If all Intel CPUs get 30% slower overnight, then there will be some fallout in the real world.
- FBISurveillance 9y ago
  They might be 30% slower in virtualization and should be about 5-7% slower in real world usage. As a heavy user of the cloud I'm worried about my infra more than about my laptop: if my cloud setup gets even 7% slower overnight it won't be good to say the least, especially with lower-clock 2Ghz Skylake GCP CPUs. Those 5--7% will make me feel like I'm powered by Atom and it will be even worse for single-core bounded workloads in the cloud.
  - python-guy-vt 9y ago
    >They might be 30% slower in virtualization and should be about 5-7% slower in real world usage. Virtualization IS real-world-usage. This is going to damage Intel where it will hurt the most, the datacenter (which is largely virtualized using VMware, or Hyper-V). The Xeon CPU's have some of the best profit margins for Intel. If they erode away to Epyc (which is finally becoming available) this could be pretty good for AMD's, espically since AMD has said the the past few years there strategy is to go after the datacenter market.
  - tetraodonpuffer 9y ago
    there's other real world usage (DAWs, for example, where there is a ton of I/O for sample-based virtual instruments) which will likely be as significantly impacted as virtualization likely...
swarnie_ 9y ago
How you hold this stock is a mystery to me. With it bouncing between $10 and $15 constantly last year it just seems far to volatile. I'd be panic buying / selling every day to adjust which seems stressful... Maybe why its a favorite of /r/wallstreetbets
- InTheArena 9y ago
  I bought a ton at 9 before the Ryzen announcement. The oscillation in the stock drove me up the wall, and I came to the conclusion that it’s just stupid to track single stocks, even when you know they have a great product, because the market is so irrational.
- kongbtc 9y ago
  try trading crypto
  - swarnie_ 9y ago
    Ill stick to blue chips and paper trading. The NHS can only hand out so much heart medication...
- Havoc 9y ago
  >/r/wallstreetbets Guilty as charged. >I'd be panic buying / selling every day to adjust which seems stressful... Just treat it as numbers on a screen rather than money. Keeps the emotions at bay.
  - deleted 9y ago
    [deleted]
- meddlepal 9y ago
  You're doing it wrong if you're day trading stocks... dollar cost averaging is your friend when it comes to volatility and well if you're investing you're doing so because of long term belief in the company so it should be easy to hold and not worry about it.
betterunix2 9y ago
I am not so sure. Cloud providers will probably want to get this fixed and AMD would be a convenient alternative in the short term. I think the bigger risk is that rather than going with AMD, cloud providers will pursue a different CPU architecture altogether, especially in the long-term. There were plenty of things to dislike about x86 virtualization etc. before this mess.

NinjaKitten 9y ago

"Intel has a bug that lets some software gain access to parts of a computer’s memory that are set aside to protect things like passwords." Seems like very little got through to the media about the details regarding this flaws effects and costly workaround.

grigjd3 9y ago
Bloomberg is not going to focus on technical detail too much (at all) given their readership. Follow the link to the register for more detail.
- Dotnaught 9y ago
  https://www.theregister.co.uk/2018/01/02/intel_cpu_design_flaw/ https://www.theregister.co.uk/2018/01/02/intel_cpu_design_fl...
willvarfar 9y ago
in this particular case, will the generalization help their readership? I actually think it will - it would be easy to give more accurate details that cause many readers to glaze over.
- marmaduke 9y ago
  That was my reaction. How to ELI5 the risk in multitenant VM environment? It could steal passwords
  - blattimwind 9y ago
    > How to ELI5 the risk in multitenant VM environment? Some other guy paying EC2 steals your customers passwords by sheer force of will > How to ELI5 the risk in desktop PC? A piece of JavaScript in some 0x0 pixel iframe in a tab you're not even looking at stealing your passwords and SSH keys (Although nothing is proven in the latter regard, I wouldn't be per se surprised to see something in that direction once the exact nature of the issue is more widely known)

rwmj 9y ago

AMD must be pretty happy about this patch: https://lkml.org/lkml/2017/12/27/2 https://lkml.org/lkml/2017/12/27/2

ihsw2 9y ago
Not quite -- without his patch, the performance penalty will hit them too. Tom is proposing to be excluded from the proposed solution as it would hit AMD with collateral damage from the `X86_BUG_CPU_INSECURE` fix. I'm sure there are frantic emails claiming that AMD shouldn't be punished for Intel's mistake. EDIT: actually the fix will go out with 4.14.12 and 4.15rc7, both `X86_BUG_CPU_INSECURE` and AMD's addendum to be protected from the collateral damage.
- dingo_bat 9y ago
  Maybe it's just me but that name is just too general. Is there no other conceivable way an x86 CPU can ever be "insecure"? Why'd they use something so vague? Is this part of the redaction?
sena 9y ago
Tom Lendacky works at AMD, so yes... :)
hvindin 9y ago
As long as the patch is all anyone notices then it looks great from AMD marketing. But I'm fairly confident (and a quick browse through the patched in the latest RC confirms at least one instance of this) where comments call out that AMD CPUs do things that should be considered bugs, so there's probably not going to be a lot of PR people telling the masses to read the source code. It's not exactly flattering to anyone. One thing I can definitely respect about the kernel developers is that they don't seem to make any effort to be nice about the fact that they need to deal with undocumented nonsense from vendors all round.
uniformlyrandom 9y ago
Not so sure about that. I am reading the merge commit, and comments are pretty interesting: --- a/arch/x86/include/asm/processor.h +++ b/arch/x86/include/asm/processor.h + * On Intel CPUs, if a SYSCALL instruction is at the highest canonical + * address, then that syscall will enter the kernel with a + * non-canonical return address, and SYSRET will explode dangerously. + * We avoid this particular problem by preventing anything executable + * from being mapped at the maximum canonical address. + * + * On AMD CPUs in the Ryzen family, there's a nasty bug in which the + * CPUs malfunction if they execute code from the highest canonical page. + * They'll speculate right off the end of the canonical space, and + * bad things happen. This is worked around in the same way as the + * Intel problem.

cma 9y ago

This isn't really too far out of proportion with normal daily fluctuations of AMD stock this year.

zelos 9y ago
Quiet, you're spoiling the narrative we're imposing on semi-random, chaotic events.
- cma 9y ago
  To add another point: NVDA is up 5% and doesn't have the same direct competitive narrative. If money has to be spent rectifying the issue with new or more CPUs due to performance loss, that's less money available for spending on Nvidia GPUs. It might tip a few marginal applications in favor of eating the development costs to migrate to GPGPU, but that effect isn't likely nearly as high, especially if applications with lots of system calls are affected the most.
  - tedunangst 9y ago
    Chipotle is also up 5%. All these engineers are going to need lots of burritos to eat.
    - jabl 9y ago
      You're saying that gas in the cleanroom caused the chips to behave incorrectly? Excuse me while I go and invest in a company making rubber underwear.
      - adjkant 9y ago
        Someone's gotta sell Burger King sesame seeds...
- nopriorarrests 9y ago
  +8.79% AMD & -4.44% INTC does not look like a semi-random event anymore. Seems like wider audience is waking up to the news.

toyg 9y ago

This piece should be used in journalism schools. > Advanced Micro Devices Inc. surged [...] after a report that Intel Corp., its only remaining rival in the market for personal computer processors Ahh, so Intel is the only holdout against the dominant wave of AMD processors, right? facepalm.jpg

littlestymaar 9y ago

Interestingly enough, Intel and AMD market values are affected by this but the cloud provider aren't, which I find surprising.

nomercy400 9y ago
Do you pay for computing cycles or for a computing instance? If your cloud provider lowers its performance/efficiency by 30%, isn't it up to its customers to switch? But where to switch too? There's no choice among the big cloud providers. They all use Intel and AMD in varying amounts. As a cloud user you are stuck with Intel or AMD chips. Demand doesn't change, supply is lowered. Looking at it like this, it is more likely that demand for cloud resources will rise, and as such revenue of the cloud providers will as well.
- FollowSteph3 9y ago
  My guess is that it will help cloud providers. In most cases they don’t guarantee x operations per second but rather the type of cpu you get. If that type now gets 30% less performance you’re most likely going to have to pay 30% more. Again the guarantee is not on operations per second but either exact processor, class of processor, or processor units.
Waterluvian 9y ago
Hm. Do cloud providers need to provide up to 30% more capacity for the same price, or do customers need to purchase up to 30% more capacity to get the same speed?
- BoorishBears 9y ago
  This bug doesn’t magically chop all CPU performance down by almost a third.
  - cjbprime 9y ago
    What does it do, then? That is approximately what the mitigation patch does, according to early averages of perf changes.

dsign 9y ago

This is a clusterf/big deal. Beyond the security implications, it means that all companies paying for computing resources will have to pay roughly 30% more overnight on cloud expenses for the same amount of CPU, assuming that they can just scale up their infrastructure. I know that bugs happen and that there was nothing intentional on this one, but at times like this is hard to held at bay the temptation of claiming for a class lawsuit against Intel....

wyager 9y ago
> I know that bugs happen This isn’t an excuse for Intel consistently having terrible verification practices and shipping horrendous hardware bugs. From 2015: https://danluu.com/cpu-bugs/ https://danluu.com/cpu-bugs/ There have been more since then. I’ve talked to multiple people who work in intel’s testing division and think “verification” means “unit tests”. The complexity of their CPUs has far surpassed what they know how to manage.
- zouhair 9y ago
  This is typically what happens when you go for a long time without real competition. You get way too comfortable and bad habits start to pile up.
  - spdy 9y ago
    Isn't why this problem even exits the exact opposite? Intel was losing on the mobile market and changed internal testing to iterate faster by cutting corners. Found a quote: "We need to move faster. Validation at Intel is taking much longer than it does for our competition. We need to do whatever we can to reduce those times… we can’t live forever in the shadow of the early 90’s FDIV bug, we need to move on. Our competition is moving much faster than we are".
    - mannykannot 9y ago
      That is a very interesting perspective, and as far as I know it is correct, though perhaps Intel's situation in the mobile market was exacerbated by complacency?

dzink 9y ago

Didn’t the Intel CEO just sell half of his shares/options? If he knew about these issues isn’t that illegal?

mizzack 9y ago
Looks like Krzanich sold $39.4M of stock on 11/28. Hard to say when the top brass knew about this flaw. https://finance.yahoo.com/quote/INTC/insider-transactions?p=INTC https://finance.yahoo.com/quote/INTC/insider-transactions?p=...
- ehsankia 9y ago
  I don't understand this attitude that "top brass might not know about it". He's the CEO, isn't his entire job to know what's going on in the company? I know we get this idea that rich people just sit back and take in the money, but isn't the reason they are paid so much in the first place because they have in theory a big responsibility on what happens in the company?
  - mizzack 9y ago
    You're putting words in my mouth. I didn't say he didn't know about it. I said we don't know WHEN he first knew about it, which is important in the context of insider trading.
    - philipov 9y ago
      Even if he knew about it, if it was more than 6 months in advance and he follows all the legally-mandated protocols for setting up a regulated stock trade, isn't he safe? The marvel is that somehow the news was kept from hitting the media until he had finished his trade, and then was revealed immediately after the transaction was complete. I wonder how that coincidence happened.
      - mizzack 9y ago
        The SEC would need to be able to show that Krzanich initiated that rather large selloff based on this inside, privileged info. Given the short document retention policies in place at most companies, this would presumably prove pretty difficult.

emn13 9y ago

This piece is (IMNSHO) trash. It's trying to stare into some crystal ball guessing at the cause of market fluctuations; but there's no real evidence they're right. Not to mention it's pretty misleading about technical stuff, saying e.g. "Chip design errors are exceedingly rare. More than 20 years ago, a college professor discovered a problem with how early versions of Intel’s Pentium chip calculated numbers." So, they imply that chip design errors are once in a few decades kind of things; that's just complete nonsense. Chip design errors are common most just aren't this bad. Furthermore, they imply this stock change is anything more than temporary volatility; given the tiny, tiny changes so far that's just premature. Perhaps the stocks will adjust more in the future - we'll see. But as of now, this piece is financially and technically pretty misleading.

mikeokner 9y ago
Bloomberg? Trash? I'm shocked (I'm not).
grendelt 9y ago
> It's trying to stare into some crystal ball guessing at the cause of market fluctuations; but there's no real evidence they're right. Welcome to the world of business reporting.
- dnautics 9y ago
  I think it's pretty clear in this case. Plenty of people here in hn-land were talking about Intel/AMD short/long positions starting in the afternoon yesterday and word has gotten around.
  - emn13 9y ago
    Talk is cheap; investing perhaps less so. The asserted "soaring" stock price simply hasn't happened. The 7% rise they name as "soaring" is not a soar for a stock this volatile: https://www.bloomberg.com/quote/AMD:US https://www.bloomberg.com/quote/AMD:US - just look at the graph over the past year; value changes in excess of 50% happened several times. To be clear; I'm not saying this increase won't stick, just that bloomberg is pretending they're reading this from the numbers, not merely expecting it to occur. It'd be fine to say you might expect the stock to trend higher. But pretending you can look at that noisy line and say the current 7% increase is statistically significantly higher in a humanly relevant way is just hogwash. Obviously you might expect the stock to soar. It may well happen. It just isn't visible in the data they present; the article is simply click bait (or worse, market manipulation).

cesarb 9y ago

This article appears to be jumping the gun. It presents the defect as a fact, but aren't we still in the "rumor" phase (other than perhaps the few who have early access to embargoed details)?

bryanlarsen 9y ago
Stocks tend to move a lot more on rumour than they do on fact.
- blackflame7000 9y ago
  Trading would be a lot easier if you could wait till the facts come out
pixl97 9y ago
https://twitter.com/brainsmoke/status/948561799875502080 https://twitter.com/brainsmoke/status/948561799875502080 Doesn't seem to be much of a rumor.

lafar6502 9y ago

But is the security Bug exploitable in any realistic way?

blattimwind 9y ago
https://twitter.com/brainsmoke/status/948561799875502080 https://twitter.com/brainsmoke/status/948561799875502080
- cypherpunks01 9y ago
  What does that output mean? He was able to look up an address that was used in a speculative execution or something?
  - blattimwind 9y ago
    He successfully read from kernel memory, the first two bytes from the syscall table to be precise. The first entry is sys_read (on x86-64 anyway) and the first field is the address. That's why he shows the full address in the next line; the PoC exploit read the lower 2 bytes of that address.

blattimwind 9y ago

And we got a bingo https://news.ycombinator.com/item?id=16061364 https://news.ycombinator.com/item?id=16061364

dsign 9y ago

Here are some numbers quantifying the problem. Big caveats apply as they are very preliminary, but the hit due to the software patches looks extremely significant: https://www.phoronix.com/scan.php?page=article&item=linux-415-x86pti&num=2 https://www.phoronix.com/scan.php?page=article&item=linux-41...

0xcde4c3db 9y ago
Superficially, it seems like the performance hit mostly scales with IOPS or transactions per second, which might have some pretty serious implications for performance/dollar in the kinds of intensive back-end applications where Intel currently dominates and AMD is trying to make inroads with EPYC.
- mtanski 9y ago
  As I mentioned in the other thread yesterday database and database like applications are going to be hit particular hard. Even more so on fast flash storage. Double whammy compared to apps just doing network IO. And while databases try to minimize the number of syscalls they still end up doing a lot of them for read, writeout, flush.
  - surajrmal 9y ago
    Don't flash devices use nvme (eg userspace queues) now and avoid the kernel all together for read and write operations? Shouldn't they have no impact?
    - kllrnohj 9y ago
      Not by default they don't. That only works if you're willing to dedicate that entire physical drive to a single application anyway.
      - mtanski 9y ago
        In the future this possible on Linux with the filesystems that support DAX. Currently this all pretty experimental with lots of work being done in this space in the last two years. But this will require you to have the right kind of flash storage, right kind of fs, right kind mount options, and probably a different code path in userspace for DAX vs traditional storage. So we're a little ways away from this.

rayiner 9y ago

Can someone help me understand why this is such a big deal? This doesn’t seem to be a flaw in the sense of the Pentium FDIV bug where the processor returned incorrect data. It doesn’t even seem to be a bug at all, but a side channel attack that would be almost expected in a processor with speculative execution unless special measures were taken to prevent it. And it doesn’t seem like it can be used for privilege escalation, only reading secret data out of kernel memory. It seems pretty drastic to impose a double-digit percentage performance hit on every Intel processor to mitigate this.

mikeash 9y ago
If “reading secret data out of kernel memory” translates into “read the page cache from a stranger’s VM that happens to be on the same cloud server” then this could be worse than Heartbleed.
- 0x0 9y ago
  Or maybe random javascript in the browser can stroll upon your ssh private key in the kernel's file cache... and so on.
  - mikeash 9y ago
    Excellent point, I didn't think about the implications for stuff like JavaScript.
- deleted 9y ago
  [deleted]
lmm 9y ago
If you can read kernel (and hypervisor) memory then it seems like a very small step from that to a local root vulnerability - e.g. forge some kind of security token by copying it. There's an embargoed Xen vulnerability that may be related to or combine with this one to mean that anyone running in a VM can break out and access other VMs on the same physical host. That would be a huge issue for cloud providers.

rietta 9y ago

Just built a new Linux workstation the day after Christmas with a 4.2 Ghz i7. In hindsight I should have bought a AMD Ryzen! Glad the computer I built my dad was an AMD.

bandris 9y ago
The following story might comfort you somewhat. Someone had bad luck with Ryzen: http://erlang.org/pipermail/erlang-questions/2018-January/094580.html http://erlang.org/pipermail/erlang-questions/2018-January/09...

tapoxi 9y ago

I don't know much about CPUs, so what prevents a fix via microcode update?

db48x 9y ago
No one outside of Intel knows enough about Intel's microcode to answer that question, especially since we don't know the full details of the problem.
dannyw 9y ago
The bug seems to be revolving around speculative execution. It seems like that is a silicon thing, not a microcode thing.
- zimmerfrei 9y ago
  The bug seems to be about the processor leaving speculatively read privileged data in some of the caches, even if execution failed [1]. If so, clearing all caches upon a failed privilege check sounds like something within the capabilities of microcode and without unreasonable performance penalties. Unfortunately, that would not explain the complex in-kernel fix... [1] https://plus.google.com/+KristianK%C3%B6hntopp/posts/Ep26AoAZxxd https://plus.google.com/+KristianK%C3%B6hntopp/posts/Ep26AoA... EDIT: what remains in cache is not "speculatively read privileged data" but more "unprivileged data whose address is correlated to speculatively read privileged data". Retrieving later such address allows one to infer what the privileged data was. Still, the point about clearing all caches as countermeasure holds...
- rphlx 9y ago
  It's likely they could disable speculative execution in its entirety, either in ucode or UEFI, but that would harm many compute-intensive workloads by 5-10% or more, so my guess is that somebody decided to push this page table mitigation instead, taking the hit on the syscall/hypercall side as that's perceived as "less bad overall".
fulafel 9y ago
We don't know if anything does, but it could be that an effective microcode update (eg turning OOO off) would slow down the CPU more than the software fix.

AnIdiotOnTheNet 9y ago

Honest question, does the performance hit from this patch actually hit Intel's best processors enough to make them perform worse than AMD's best? I don't keep up on these kinds of metrics, but I'm under the impression that Intel still dominated CPU benchmarks berfore this issue, so if this question is answered in the negative then I doubt it will affect Intel very much.

Symmetry 9y ago
Intel hasn't been dominating in CPU benchmarks since AMD's new Zen architecture came out. They still have a ~10% lead for gaming but there are as many usecases where AMD is the best choice as there are where Intel is. So if this bug is slowing down Intel but not AMD servers by 10% then suddenly choosing AMD is a no-brainer.
db48x 9y ago
It depends on what your program is doing. If your program uses a lot of syscalls, then it'll be slower. If it hardly uses them at all, then it won't be as affected.
- AnIdiotOnTheNet 9y ago
  Yes, but that wasn't the question.
deleted 9y ago
[deleted]
BuckRogers 9y ago
It's too soon to say. There's still variants Meltdown/Spectre that aren't fixed yet. The other guy was correct that it probably depends on your workload, but in a couple months after all the dust has settled on this and we have a comprehensive review, my guess is yes AMD is going to take a commanding lead. Spectre affects every modern CPU, and performance impact will be marginal. Meltdown affects Intel-only, and the performance impact will be significant. Here's Fortnight's preliminary server results[0]. Once everything[1] is patched up it's just going to get worse for Intel. Ryzen was already fast though and had superior SMT (Hyperthreading) efficiency than Intel prior to this bug (~10%). This is going to take a serious toll on Intel's single-threaded performance advantage (~10% from IPC, 25% clock frequency advantage). My advice is to stick with Ryzen/Threadripper/Epyc. [0]https://www.epicgames.com/fortnite/forums/news/announcements/132642-epic-services-stability-update https://www.epicgames.com/fortnite/forums/news/announcements... [1]https://gist.github.com/woachk/2f86755260f2fee1baf71c90cd6533e9 https://gist.github.com/woachk/2f86755260f2fee1baf71c90cd653...

bla2 9y ago

The bottom of https://danluu.com/cpu-bugs/ https://danluu.com/cpu-bugs/ suggests that AMD isn't any better, so this is likely just short term.

mtgx 9y ago
Since that article came out, AMD built a whole new CPU architecture, with the help of the guy that designed the K8, too.
dboreham 9y ago
They don't have to be better to benefit from purchasers wanting to diversify their plant across two rather than one CPU vendors.
yborg 9y ago
This specific issue is very relevant to cloud providers, who are the guys that buy thousands of CPUs, and doesn't affect AMD's current generation. I don't know what Intel's profit breakdown is, but I suspect it is heavily weighted to the high-end server chips where they have had no real competition for many years.

hungerstrike 9y ago

So is today a good day to buy Intel stock?

jacksmith21006 9y ago
Would say no. INTC has not been hit yet from this. Cramer this morning indicated the issue is unsubstantiated.
chasd00 9y ago
don't try to catch a falling knife. Let it settle, give it a week or so then see where it is.

Abishek_Muthian 9y ago

I'm worried about the performance impact on low end intel chips like Atom/Celeron found in Chromebooks.30% hit will make computing on those platforms miserable. Talking about chromeOS, is there any speculation about the impact of bug? Does it's hardened sand-boxing techniques put it in a better position even if KASLR is compromised?

mtgx 9y ago
Honestly, that serves Google right. I've been saying it for years how stupid Google is for encouraging 99% of Chromebooks to be powered by Intel chips (even more than Windows machines), when the Chrome OS itself is architecture-agnostic (for the most part). It was just stupid through and through. Even today we see ARM coming to full versions of Windows, but Google is still kicking it with Intel CPUs.
dannyw 9y ago
The bug isn't really KASLR, it's more about reading kernel memory from userspace through side channel attacks of speculative execution. KASLR is/was the cover for the kernel patches, to avoid disclosing the real bug.
- Abishek_Muthian 9y ago
  The comment in linux kernel mailing list, does pin point attacks using 'speculative execution' but isn't access to kernel memory space by any means a potential hazard to the security depending upon KASLR?
- svet_0 9y ago
  Indeed, kernel memory read seems more likely than address only read, the memory probably needs to be cached (in L1 maybe?). Attack is a timing attack as can be seen in this very interesting tweet - https://twitter.com/brainsmoke/status/948561799875502080 https://twitter.com/brainsmoke/status/948561799875502080

jamisteven 9y ago

Literally just read here yesterday how the CEO dumped majority of his shares. So Shiesty. https://news.ycombinator.com/item?id=16055851 https://news.ycombinator.com/item?id=16055851

prewett 9y ago
Don't be so quick to blame. You might have read it yesterday, but he reported it on Nov 29, which means that the transaction happened either within two days prior or about a month, depending on if you believe the SEC's website or NASDAQ's website. But the question isn't when he sold his shares, the question is when did he put in the order to sell those shares. Those guys put their buy/sell orders in months in advance because of exactly this problem. Or maybe he had a limit order in--the beginning of November was a 2-year high, so you could easily imagine a limit order executing about then.
- joncrane 9y ago
  Evidence shows this bug was known in November. It only blew up this week.
  - jacksmith21006 9y ago
    Probably even earlier.
matt4077 9y ago
Don't spread conspiracy theories. It's absolutely impossible for the most visible executive of one of the largest firms to engage in insider trading in such an obvious fashion and get away with it. At this level, there is always a paper trail of who knew what when. There are internal and external audits if any suspicions arise. Plus there are sever penalties, both civil (in the employment contract) as well as criminal. Intel's CEO is without a doubt in the 9- or 10-digit range of personal wealth. Risking time in jail to avoid a 10% loss on his stock holdings would be a terrible decision even if they considered the chance of being caught was low.

TheSwordsman 9y ago

I wonder what implications this will have on those who run Intel in their gaming rigs. I'm due to refresh, and _was_ gonna invest in Intel as my CPU. But this seems pretty damning for that. I assume the system calls to interact with the GPU, or to do any sort of I/O, are going to incur the performance overhead. So rendering frames, reading/writing from the network, and loading assets from the disk could all cause issues. And this is just for gaming. Anyone using a cloud provider that's running on Intel needs to worry about similar things. What a nightmare...

a_humean 9y ago
Apparently zero effect: https://www.phoronix.com/scan.php?page=news_item&px=x86-PTI-Initial-Gaming-Tests https://www.phoronix.com/scan.php?page=news_item&px=x86-PTI-...
- QShift 9y ago
  Well, that's for Linux. We don't exactly know what effects such patches would have on other platforms yet. (do we?)
rnhmjoj 9y ago
To make things worse there is an increasing number of games running DRMs like Denuvo and VMProtect that cause a significant performance hit. I think these will be more heavily affected by the patch.
- obscurantist 9y ago
  I don't get why more developers don't take notes from CD Projekt.
chrisper 9y ago
Sadly I just bought an 8700k last week. Great CPU until next Tuesday? (Windows Patch Day) Though even if I lose some percentage, it will still outrun AMD on single core applications (and probably also multi core ones).

teekert 9y ago

Perhaps a bit off topic but I have an (Asus) laptop with a recent Intel chip running Linux (Solus) and I have no idea how I am to deal with all these CPU bugs... Any pointers?

marcolussetti 9y ago
The patch isn't out yet. Once it's merged in, your distribution will release patches you can install on the normal way you update your distribution.
- teekert 9y ago
  Ah, ok, so Intel Management engine patches are also distributed in the Linux Kernel then?
dna_polymerase 9y ago
Just sit and wait, it's all too fresh to make solid statements on this. Maybe aside from, think twice before buying Intel again.
- teekert 9y ago
  Definitely, sadly the new AMD Ryzen's were not in laptops at the moment I needed one. To be honest, a high end ARM laptop would also have been nice, but as it is, Intel is king on >8 hrs battery life machines with decent performance.

GuB-42 9y ago

It seems like it is all thanks to this patch: https://lkml.org/lkml/2017/12/27/2 https://lkml.org/lkml/2017/12/27/2 If I understand well, there may be a serious bug in some x86 CPUs but nothing is known publicly. Presumably, all current Intel CPUs are affected and none by AMD but we can't really be sure, it is still a secret. It is impressive how a simple, yet to be justified patch has so much influence. It opens up new ways of manipulating the market...

markonen 9y ago
But it's not just a random patch posted to LKML, it has also been reviewed and merged to tip. That means it has been justified, just not to you.

runesoerensen 9y ago

Related discussion https://news.ycombinator.com/item?id=16052451 https://news.ycombinator.com/item?id=16052451

throwawazqq 9y ago

AMD stock price was higher in July and October. It increased a tiny bit and does not constitute “soaring”.

take4 9y ago
It's currently +10%, which absolutely is "soaring".

chrisper 9y ago

If you look here: https://www.computerbase.de/2018-01/intel-cpu-pti-sicherheitsluecke/ https://www.computerbase.de/2018-01/intel-cpu-pti-sicherheit... (Sorry it is German) But if you scroll down to "Windows-Benchmarks: Anwendungen" you can see that most applications do not have any performance hit with the Windows patch. Only M.2 SSD seem to be affected.

nopriorarrests 9y ago
All their tests are CPU-bound, not IO-bound, namely -- archiving, rendering, encoding video. Performance degradation happens with transactional, IO-bound tasks (think noSQL databases, ad serving, trading)
dingo_bat 9y ago
It is possible Microsoft has mitigated the issue in a way that has much lesser performance impact. Maybe they had a highly tuned feature to enable kernel page separation already coded but disabled. I won't be surprised if even the Linux implementation is tuned to the absolute limit in the coming months.
- chrisper 9y ago
  I think so too. It also seems the Linux version right now is in a "get it to work, optimize later" state.
  - amluto 9y ago
    If you know how to materially optimize it, I'm all ears.
- pvdebbe 9y ago
  > I won't be surprised if even the Linux implementation is tuned to the absolute limit in the coming months. To me, this sounds like unnecessary work if Intel is coming up with a microcode patch within a few months.

secfirstmd 9y ago

I wonder what the value of this chip flaw would be to the NSA?

moomin 9y ago

"Chip design flaws are exceedingly rare." Writes someone who's never seen an errata.

kylehotchkiss 9y ago

Does anybody know if the 30% performance reduction would apply to Macbook pros from within the past 2 years?

Brockenstein 9y ago
They run Intel CPUs made within the last ten years so would be subject to this issue. But the performance hit is really dependent on the computing that you're doing. It's not a guaranteed 30% or a guaranteed 5%. Are you doing a lot of really CPU intensive tasks that make a lot of syscalls? Most people aren't. If you are, you'll probably feel that pain. And if you're not, you probably won't notice a difference. And if you don't know you can either research if what you're doing typically is going to be affected, or wait and see.
- cookiecaper 9y ago
  > They run Intel CPUs made within the last ten years so would be subject to this issue. Do we know that? There is a lot of speculation but the embargo is not lifted yet afaik. There are obviously elements of this that are remaining intentionally obscured pending embargo expiry (redacted comments), so it could be that a smaller contingent of chips are affected and no one is bothering to correct the damage/limit the patch only to applicable components so that the cat doesn't get out of the bag too soon (side benefit: so that an extensive emergency fix like this can be widely tested before it's applied to a relatively limited set of hardware). Seems just as valid as any other speculation to me.
- bluedonuts 9y ago
  Do we know that the kernel used in OSX is vulnerable at all? I haven’t found any discussion of it.

aeleos 9y ago

What started as speculation about recent kernel developments has really turned into a shitshow for Intel. I can't imagine they thought that these massive changes would get through without anyone finding out. However, there really isn't any other better option for Intel, so it seems they are in a lose lose situation with no way out. Or at least a way out that doesn't involve them going bankrupt trying to repair the damage.

mandeepj 9y ago
> going bankrupt trying to repair the damage. I think you took it a bit too far. May be, I am missing something. Is it really that bad?
- agumonkey 9y ago
  Bankrupt might be a wild guess, but it is one of the largest blunder I can recall. 12 years lineup affected, large penalty fix, hardwired. Intel is gonna enjoy a healthier diet for a while.
- aeleos 9y ago
  There are at least tens of thousands, possibly hundreds of thousands of Intel CPUs in just datacenters around the globe. Most of which are controlled by companies that make a lot of money and paid a lot of money to intel for their CPUs. And I doubt that they will just take this kind of hit to their performance sitting down. And thats just datacenters, not to mention all the personal computers (mine included) that will suffer. At this point, if this is real, its not a question of if it will cost them, its how much. And considering the sheer numbers of the products affected, I can't imagine it will be cheap. I am not saying that I think they are going to go bankrupt, and I would be surprised if they did, but a 30% percent performance hit is multiple generations of fallback, and considering the importance of computing today (and the number of different entities that are affected by this) I find it hard to imagine that it will be just taken sitting down.

johnjones4 9y ago

So is this sort of issue more likely to occur on a non-RISC chip because of added complexity? I know extremely little about microprocessor design beyond the 101 knowledge from college so forgive my ignorance.

amaranth 9y ago
I think this could occur on any CPU that doesn't have a separate TLB for kernel mode and has speculative execution. So far it looks like it only occurs on Intel's CPUs but I don't think that has anything to do with RISC vs CISC. I believe Linux was at least looking at applying this change to arm64 as well and this is likely going to lead to a design change in RISC-V to avoid having issues like this so it can happen to RISC designs as well.

gagabity 9y ago

Is there any real danger for desktop users? We should be allowed to skip this patch if we dont want it, I would rather take the risk than the performance hit.

zzzcpan 9y ago
For desktop users there should not be any noticeable performance degradation. But they are also likely the ones in the most danger, since they execute random code in their web browsers.
- blackflame7000 9y ago
  I might be wrong, but shouldn't browser makers be able to prevent executing scripts from exploiting the low level memory manipulation this requires?
- Dylan16807 9y ago
  Random code that makes direct kernel calls? Or is that not necessary?

hellbanner 9y ago

This is different from the intentional backdoor, Management Engine?

chrisper 9y ago
Yes. This is far worse.
- hellbanner 9y ago
  I see - so this is more accessible? We're all fucked, then?
  - chrisper 9y ago
    The "fear" with ME is more that governments or someone like that could spy on us... (not really a "threat" to most people in Western Countries). But still better to get rid of it. Not an imminent threat per se. This bug is a true security bug that has been lurking around for 10 years... and it could have been already abused. This is double scary because this attack does not leave any traces behind and it allows any application to pretty much enter God Mode (this is the worst case scenario of a security situation (hence the name meltdown (like nuklear meltdown is the worst case situation in a nuclear power plant)). This bug is also bad because in certain situations the fix of this bug causes severe peformance penatlty. You are only fucked if you don't update your OS.
    - hellbanner 9y ago
      OS updates will fix this - but the bug remains on the chip, right? Hm, I guess I'll check for updates =)

joering2 9y ago

It must be serious when stock of this size goes 5% down now... https://www.google.com/search?q=intel+stock https://www.google.com/search?q=intel+stock Edit: AMD 8% up: https://www.google.com/search?q=amd+stock https://www.google.com/search?q=amd+stock

pashabitz 9y ago

I just read yesterday that the CEO sold all his stock except for what he's required to hold by corporate bylaws, a short while ago.

pas 9y ago
it was an automated sale

newtanjoy 9y ago

I request all my friends. Search my web site at NFL. I will be of great benefit to you for a search. Kindly you search once. You will not have any problem. There are site security. https://livesporthdtv.com https://livesporthdtv.com

microcolonel 9y ago

This is not a PR nightmare, it's a technical competitive nightmare. For many workloads, last-gen AMD server chips are now competitive with current-gen Intel server chips; and the current generation already had a lot in its favour. There's no amount of PR fluff that can save Intel from this, they can only release a new design with this fixed and hope they don't lose too much ground in the mean time.

throwaway613834 9y ago

Will there be any way to disable or block the upcoming patches and keep the performance for those of us who really just don't have any reason to care about inter-process information leakage on our personal computers? Edit: I'm (also) wondering about Windows, in case anyone knows yet.

JoachimSchipper 9y ago
Yes, the work-around can be disabled via a boot-time argument.
- throwaway613834 9y ago
  Thank you! Do you know if this will be true for Windows as well, or just Linux?
pixl97 9y ago
Just don't do this if you have PII, HIPAA, or PCI data on your computer.
- deleted 9y ago
  [deleted]
- stusmall 9y ago
  Even then and if they don't care about their own safety, they should patch for the rest of us. Who knows how long until their unpatched system will get pwned from some other vulnerability and end up in some botnet just spreading the pain.
uniformlyrandom 9y ago
From the merge commit: +#ifdef CONFIG_PAGE_TABLE_ISOLATION +# define DISABLE_PTI 0 +#else +# define DISABLE_PTI (1 << (X86_FEATURE_PTI & 31)) +#endif PS - MSFT has not published relnotes, so we do not know yet. We'll find out soon enough.
- 9y ago

nopriorarrests 9y ago

Can anyone with better knowledge ELI5 to me -- to fix this bug, are cloud providers have to patch only hypervisor machines, or guest boxes as well? And if fix is applied to hypervisor, will performance degrade on guest boxes as benchmark suggests? Thanks!

dingo_bat 9y ago
Guest OS shouldn't be an issue, from what I understand. As long as the hypervisor memory is separated, you're good.
chrisper 9y ago
Yes it will affect your VM as it's the host CPU that's affected.

qubex 9y ago

I’m not (yet) clear on if/how this impacts aarch64 (ARM architecture) chips, the distinction between how it affects Intel vs. doesn’t affect AMD reminds us of a fundamental lesson we seem to have conveniently forgotten: monocultures of anything are bad. We need diversity and diversification in order to have reasonable amount of robustness in the face of unknowable, unpredictable risks. I’m wondering whether ARM chips are affected if they are whether they are uniformly affected or whether it depends on vendor implementation choices.

thraweigh666 9y ago
>We need diversity and diversification in order to have reasonable amount of robustness Ironically, in human populations it produces the opposite effect.
- adornedCupcake 9y ago
  Why?
  - edraferi 9y ago
    More diverse population—> lower trust —> less social will to support each other.
    - crimethink2017 9y ago
      This might well be true, see e.g. [1]. An obvious irony is that those who are most happy with Intel's "velocity"-led culture, and the more general lack of diversity in the x86 CPU market, are probably also the most likely to reject this idea (that human diversity might have negative effects) outright. ____ [1] https://www.mpg.de/19440/Diversity_interaction_solidarity https://www.mpg.de/19440/Diversity_interaction_solidarity
    - cryptonector 9y ago
      So we should be tribal societies, then? (I.e., endogamous. As in cousin marriage.)

troncd 9y ago

My hot take is that we will see a Mirai / qbot variant targeting consumer laptops and VPSs very, very soon with this exploit. Could cause a lot more trouble than baby monitors.

cyberpimp 9y ago

Intel went wrong when it invested in building factories in a zionist nation

deleted 9y ago

[deleted]

jrochkind1 9y ago

Best summary I've found for the somewhat technical but not hardware-or-low-level-hacker reader is arstechnica. https://arstechnica.com/gadgets/2018/01/whats-behind-the-intel-design-flaw-forcing-numerous-patches/ https://arstechnica.com/gadgets/2018/01/whats-behind-the-int...

noxecanexx 9y ago
My head is still spinning writing an OS is a BIG DEAL!!!!

dom96 9y ago

Is it just me or was this post's title changed?

neospice 9y ago
It's not you, it used to be shorter.

jokoon 9y ago

Is that me or there is an increase of critical security flaws over the last 5 years?

mlrhazi 9y ago

Would the perf hits introduced by the Linux/Windows patches also be paid by kernels of guest VMs? or just the hosts/hypervisors?

laythea 9y ago

When pondering whether I should be grumpled about this situation or accept it as "just how it goes", I wonder if Intel would be OK with me giving them up to 30% less money after agreeing to 100% before walking out the Intel shop without prejudice.

matt4077 9y ago
I don't know if their will be a recall/class-action lawsuit/whatever. But clearly there is a difference between making a mistake in what must be one of the most complicated consumer products on the one hand, and intentionally violating the terms of an agreed-upon contract? Tl/DR: Intent matters.
- laythea 9y ago
  Good point and agreed. This will cost them, and clearly was a mistake.

juanmirocks 9y ago

Considering the late Intel problems, Apple is going to be even more tempted to design its own CPUs/GPUs for the mac. What do you think, is this realistic?

jmull 9y ago

> The security updates may slow down older machinery by as much as 30 percent, according to The Register. I will eat my hat if that 30% number holds up.

runesoerensen 9y ago

Intel response https://newsroom.intel.com/news/intel-responds-to-security-research-findings/ https://newsroom.intel.com/news/intel-responds-to-security-r...

itsmemattchung 9y ago
> Recent reports that these exploits are caused by a “bug” or a “flaw” and are unique to Intel products are incorrect. Based on the analysis to date, many types of computing devices — with many different vendors’ processors and operating systems — are susceptible to these exploits. I wonder how this will play out since it seems that everyone, apart from Intel, view this issue as a "flaw".
mizzack 9y ago
> Intel believes these exploits do not have the potential to corrupt, modify or delete data. No, you can just read data you shouldn't be able to. > Intel is committed to product and customer security and is working closely with many other technology companies, including AMD, ARM Holdings and several operating system vendors, to develop an industry-wide approach to resolve this issue promptly and constructively. Let's try to drag AMD and ARM into the mud with us. > However, Intel is making this statement today because of the current inaccurate media reports. "Fake news!" Well you can't fault the PR folks for trying to spin it. They had to say something.
- ovao 9y ago
  I'd be curious to know which media reports Intel actually finds inaccurate. I'm sure there are some out there, but I suspect most reports aren't inaccurate in ways that significantly deviate from the overall message that Intel's products have a relatively serious security flaw. Making a blanket statement that implies all the reporting is inaccurate is very disingenuous. Dragging AMD's and ARM's names into this is completely inexplicable to me however.
dang 9y ago
Now discussed at https://news.ycombinator.com/item?id=16064545 https://news.ycombinator.com/item?id=16064545.

Pica_soO 9y ago

Contracts with fixed guaranteed cloud performance rates just became very valuable.

matt4077 9y ago

This reminds me of a storyline from The West Wing, where a company that was Intel in everything but the name found a bug in their chip. As it threatened the company's existence, the President refused to consider guaranteeing a loan because the company had been a contributor, and any help could potentially appear as corruption. How quaint such considerations seem today...

rdl 9y ago

I wonder how Intel will deal with this. If I were Intel, I'd offer free replacements for at-par performance, and potentially tiny cash payment for upgraded performance. Assuming the marginal cost to produce chips, especially older/slower ones, is very low, the only real cost to them is losing out on potential upgrade sales which would have happened organically, for a while. However, doing this keeps Qualcomm/ARM and AMD from making massive inroads into the market. As well, it would be a great way for Intel to accelerate adoption of their newer technologies, causing even greater lock-in (you could assume a much higher percentage of users will have a feature) This all works great for socketed CPUs (still common for servers/cloud). For embedded, where CPU is more likely non-replaceable even if socketed) CPU peak performance probably doesn't matter as much -- maybe do a discount coupon? Or work with equipment vendors to subsidize upgrades. Laptops and non-technical end users (who couldn't swap their own CPU) probably don't care as much but also don't have the ability to upgrade. A rebate/upgrade program would work, or a substantial cash payment. Doing it as e.g. $50 cash or $250 toward your next Intel-CPU laptop would be interesting. Intel is rich, the market leader, incumbent across multiple segments, etc., so they really should go overboard on their response.

asah 9y ago
rofl, you don't simply upgrade chips installed in 1+B servers and laptops and network devices and embedded systems. In fact, statistically-few devices-containing-a-CPU are designed to ever have their CPUs replaced. At the last, you replace the motherboard, which requires coordination with the vendor. Consider cars - good luck coordinating that recall!
- rdl 9y ago
  Devices containing multiple security levels/distinct users, and where performance matters the most, are generally socketed-CPU servers. For other devices, if they're security critical and can't be addressed through software, you can upgrade them at the board or device level early. This has already happened in embedded devices due to the C2000 timer problem. Assuming there is a software mitigation which has a performance impact, sophisticated users would be capable of adding more capacity (if it's a horizontal scale type workload), upgrading early (if they had extra capacity for futureproofing), or spending money, potentially subsidized by Intel, to upgrade immediately. If there's no mitigation, upgrade early, or rearchitect application (moving away from shared security domains on single boxes, etc.)

blackflame7000 9y ago

Does anyone have insight on the implications this vulnerability might have on Remote Execution. Is controlling the access to the physical machine sufficient?

jhallenworld 9y ago

After the fix, will device drivers still have the user process mapped into their address space? If not, then the fix may expose many driver bugs (where driver accessed user space directly instead of through copy_from_user()), making the whole thing even more painful.

mastazi 9y ago

I am confused, as far as I know two different vulnerabilities have been discovered, Meltdown and Spectre; while the first one affects only Intel CPUs, the second one affects AMD and ARM as well. So how come I'm not seeing much talk around about the latter? Is it because it is harder to exploit? I didn't have a chance to read the 2 papers so I would appreciate a TL;DR. I am a SW developer working with high level languages; security and OS development are not my specific fields so while I don't need an ELI5 I would appreciate a sufficiently "layman's terms" explanation.

mastazi 9y ago
Replying to myself: most of the info can be found here * https://googleprojectzero.blogspot.com.au/2018/01/reading-privileged-memory-with-side.html https://googleprojectzero.blogspot.com.au/2018/01/reading-pr... * https://www.theregister.co.uk/2018/01/02/intel_cpu_design_flaw/ https://www.theregister.co.uk/2018/01/02/intel_cpu_design_fl... * https://meltdownattack.com/ https://meltdownattack.com/ * https://www.amd.com/en/corporate/speculative-execution https://www.amd.com/en/corporate/speculative-execution * https://newsroom.intel.com/news/intel-responds-to-security-research-findings/ https://newsroom.intel.com/news/intel-responds-to-security-r... TL;DR is that mitigation for Spectre on an OS level is not very expensive in terms of performance while Meltdown mitigation, which affects only Intel, will have a performance penalty between 5% and 30%

perseusprime11 9y ago

What is more interesting to me is the news that came before this: Intel CEO selling his stock. I did not read the news but I got a notification on the phone through one of the many news apps on my phone. For a moment, I wondered why he sold off his stock.

Vkkan2016 9y ago

Patch on Azure already started rollout today on their affected VM's

aagha 9y ago

I would love an ELI5.