14 ms·

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 over

by 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?
    - leoc 9y ago
      Where’s that quote from? ISTR reading it (or something very similar) as reported speech in a HN comment. Overall it’s a depressing story of predictable market failure as well as internal misbehavior at Intel, if true. Few buyers want to pay or wait for correctness until a sufficiently bad bug is sufficiently fresh in human memory. And if you do want to, it’s not as if you’re blessed with many convenient alternatives.
      - deeth_starr_v 9y ago
        The quote is from the link above (referencing an anonymous reddit comment).
    - mtgx 9y ago
      I think that could also have been the "official reason". The same reason could have been used to give the NSA some legroom for instance, but tell everyone that's why they won't do so much verification in the future.
    - HelloNurse 9y ago
      Obvious hypothesis: first complacency leads to incompetence, then starting to cut corners has catastrophic consequences. The two problems are wonderfully complementary. As other comments suggest, there might be a third stage, completely forgetting how to design and validate chips properly.
      - eximius 9y ago
        Or the system was designed poorly to begin with and now you're stuck with the design for backwards compatibility reasons.
        HelloNurse 9y ago
        I'd expect engineers that are aware of such serious bugs to spit on the grave of backwards compatibility. After all, the worst case impact would be smaller than the current emergency patches: rewriting small parts of operating systems with a variant for new fixed processors.
    - fpoling 9y ago
      This implies that ARM vendors do less validation. I guess ARM is just so much simpler that good enough validation can be done faster. So essentially this is payback time for Intel for keeping compatibility with older code and simpler to program architecture (stricter cache coherence etc.). It is like one can only have 2 of cheap, reliable, easy-to-program.
      - pkaye 9y ago
        I'm sure ARM vendors have their own problems... it is just that they tend to be used in application specific products so the bugs are worked around. Having come from a firmware background I've worked are tons of ugly workarounds for serious bugs in validated hardware. Furthermore, I just a read an article (can't find the link) that certain ARM Cortex cores have this same issues as Intel.
      - lmm 9y ago
        > This implies that ARM vendors do less validation. I guess ARM is just so much simpler that good enough validation can be done faster. More likely "good enough" is much lower because ARM users aren't finding the bugs. The workloads that find these bugs in Intel systems are: heavy compilation, heavy numeric computation, privilege escalation attackers on multi-user systems. Those use cases barely exist on ARM: who's running a compile farm on ARM, or doing scientific computation on an ARM cluster, or offering a public cloud running on ARM?
    - kabdib 9y ago
      Man, you should see the errata for some ARM-based SOCs. It's amazing that they work at all. Vendor, in conversation: "We're pretty sure we can make the next version do cache coherency correctly." Me (paraphrased): "Don't let the door hit you in the ass on the way out." Management chain chooses them anyway, I spend the next year chasing down cache-related bugs. Fun.
      - djsumdog 9y ago
        ARM is such a shitstorm. At least the PC with UEFI is a standard. With every ARM device, you have to have a specialized kernel rom just for that device. There have been efforts made on things like PostmarketOS, but still in general, ARM isn't an architecture. It's random pins soldered to an SoC to make a single use pile of shit.
        madez 9y ago
        Why is it an issue to need a different kernel image for each device? I don't see a problem as long as there is a simple mechanism to specify your device to generate the right image. It's already like that with coreboot/libreboot/librecore, and it worked just fine for me.
        kabdib 9y ago
        Imagine that you are the person leading the team that's making an embedded system on an ARM SOC. It's not Linux, so you have your own boot code, drivers and so forth. It's not just a matter of "welp, get another kernel image." You're doing everything from the bare metal on up. (I should remark that there are good reasons for this effort. Such as: It boots in under 500ms, it's crazy efficient, doesn't use much RAM, and your company won't let you use anything with a GPL license for reasons that the lawyers are adamant about). So now you get to find all the places where the vendor documentation, sample code and so forth is wrong, or missing entirely, or telling the truth but about a different SOC. You find the race conditions, the timing problems, the magic tuning parameters that make things like the memory controller and the USB system actually work, the places where the cache system doesn't play well with various DMA controllers, the DMA engines that run wild and stomp memory at random, the I2C interfaces that randomly freeze or corrupt data . . . I could go on. It's fun, but nothing you learn is very transferrable (with the possible exception of mistrust of people at big silicon houses who slap together SOCs).
  - innagadadavida 9y ago
    But why do AMD chips not have similar issues? To me it looks like Intel tried to micro optimize something and screwed up.
    - leoc 9y ago
      Maybe the answer lies in Intel’s feted IPC advantage over AMD? Or is it the case that AMD has simply been relatively lucky so far?
    - rayiner 9y ago
      According to LKML: https://lkml.org/lkml/2017/12/27/2 https://lkml.org/lkml/2017/12/27/2 > The AMD microarchitecture does not allow memory references, including speculative references, that access higher privileged data when running in a lesser privileged mode when that access would result in a page fault. Out-of-order processors generally trigger exceptions when instructions are retired. Because instructions are retired in-order, that allows exceptions and interrupts to be reported in program order, which is what the programmer expects to happen. Furthermore, because memory access is a critical path, the TLB/privilege check is generally started in parallel with the cache/memory access. In such an architecture, it seems like the straightforward thing to do is to let the improper access to kernel memory execute, and then raise the page fault only when the instruction retires.
  - djsumdog 9y ago
    There are people looking to deploy ARM servers now. However I wish there had been more server competition. Many companies write their backend services in Python, JVM (Java/Scala/Groovy), Ruby, etc. Stuff that would run fine on Power, ARM or other architectures. There are very few specialized libraries that really require x86_64 (like ffmpeg and video-transcoding)
    - astrange 9y ago
      ffmpeg works great on ARM. I don't know if the PPC port is all that optimized lately.
- amigoingtodie 9y ago
  Sounds like Facebook and Youtube, too.
- deleted 9y ago
  [deleted]
ashelmire 9y ago
From what I've read, this slowdown only affects syscalls, which, since they aren't usually a huge percentage of processing in the first place, should not have such an effect. You're more likely looking at a few percent at most, which is not going to be enough to make AMD outperform Intel. Let's stop the fear mongering and wait for actual metrics.
- mschaef 9y ago
  > syscalls, which, since they aren't usually a huge percentage of processing in the first place... Let's stop the fear mongering Agreed! (We should probably also stop overgeneralizing about the nature of computational workloads.)
- vardump 9y ago
  > From what I've read, this slowdown only affects syscalls Incorrect. It also affects interrupts and (page) faults. Any usermode to kernel and back transition.
  - api 9y ago
    So this is evil for virtualization hosting, which is the major enterprise application for Intel chips. Hosting on bare metal will become more attractive. Too bad you can't long OVH and Hetzner.
    - chrisper 9y ago
      >Too bad you can't long OVH and Hetzner. What does that even mean? Also Hetzner just introduced some AMD Epyc server.
      - golfer 9y ago
        "Long" as a verb means to purchase their stock. As opposed to "shorting" a stock, which means making a bet that it will go down in value.
oliwarner 9y ago
As a billion other people have already said, that all depends on their workloads. This isn't a 30% clockspeed deduction.
- prudhvis 9y ago
  As i understand the problem, this isn't about clockspeed reduction, now it is the software's responsibility to check if the page is a kernel page/user page. So, the impact is significant. So, every time either pages are touched/accessed this check needs to be triggered, which causes it to be much slower.
  - DSMan195276 9y ago
    > So, every time either pages are touched/accessed this check needs to be triggered, which causes it to be much slower. Not to be mean, but that's not what is being changed. You're right on the bug - userlevel code can now read any memory regardless of privilege level. However the fix isn't to manually check the privileges on each access - that would be extremely slow and wouldn't actually fix the problem. The fix is to unmap the kernel entirely when userspace code is running. Because the kernel will no longer be in the page-table, the userspace code can no longer read it. The side-effect of this is that the page-table now needs to be switched every-time you enter the kernel, which also flushes the TLB and means that there will be a lot more TLB misses when executing code, which slows things down a lot. So, to be clear, it is not accessing pages that is being slowed down, it is the switch from the kernelspace to the userspace.
    - Cyph0n 9y ago
      But doesn't the CPU enter kernelspace every time a syscall takes place? So based on what you've described, every time a syscall returns control back to userspace, the TLB will be flushed, which means slower page access times in general.
      - DSMan195276 9y ago
        The distinction I was trying to make was the above commenters thinking that the kernel is now checking page permissions instead of the CPU doing it - IE. Doing privileged checks in software. That's not what's happening, the kernel is just unmapping itself when usercode is run so the kernel can't be seen at all. Then the privileged checks (which are now broken) don't matter because there is no kernel memory to read. All your points are right though. Page access times will in general be slower because of all the extra TLB flushes, leading to more TLB misses when accessing memory.
m3kw9 9y ago
Cloud services may not need to worry about the issue depending on the OS the customer choose to use, the patched or non patched version.
- ajasmin 9y ago
  For the cloud providers it's the security of the hypervisor that's at stake.
- chrisper 9y ago
  Why would the OS of the customer matter? The patch would be applied to the kernel of the hypervisor / host OS.
frik 9y ago
The other issue here is what MS does regarding Windows 7. It would not surprise me in the least if they tried a clever/efficient patch for Windows 10 and a simpler (and slower) bodge-job for Windows 7/8. Still, I guess we'll find out soon enough. They'd also better make sure that the changes only apply to Intel machines. I don't want MS to arbitrarily slow down my AMD PC as a result of this - you'll note that AMD submitted a Linux patch to ensure their CPUs weren't caught up in this, will MS do the same? Afterall, there is a reason this partnership is called "Wintel", both know it's in their best interest not to screw each other over.
cornholio 9y ago
> claiming for a class lawsuit against Intel If people who received written assurance from Intel that their hardware is 100% bug free can form a legal class, sure. I highly doubt there is even a single one such customer.
- golfer 9y ago
  Anyone can sue anyone else at any time. If you think Intel isn't going to be sued for this, you're wrong.
  - ianai 9y ago
    They need some legal standing or the case can be dismissed out of hand. It may very well be a question of who has the better legal team.
    - AnimalMuppet 9y ago
      > They need some legal standing or the case can be dismissed out of hand. Yes and no. Yes, Intel would get a chance to claim that the case should be dismissed out of hand. To do that, they have to prove that, even assuming all the claimed facts are true, the people suing still don't have a valid case. That's a high bar. It can be reached - there's a reason that preliminary summary judgment is a thing in court cases - but it takes a really flawed case to be dismissed in this way. How flawed? SCO v. IBM was not completely dismissed on preliminary summary judgment, and that was the most flawed case I've ever seen. > It may very well be a question of who has the better legal team. Well, Intel can afford to hire the best. A huge class-action suit can sometimes attract the best to the other side as well, though. (There's not just one "best", so there's enough for both sides of the same court case.) IANAL, but it looks to me like there's at least the potential for a valid court case. CPUs are (approximately) priced according to their ability to handle workloads; if they can't provide the advertised performance, they didn't deserve the price they sold for.
  - cornholio 9y ago
    It depends on how they handle user compensation. Going by the FDIV precedent, they should typically replace all defective products for free, and they will be in the clear. What I meant was that the presence of the bug itself is not a valid cause, for example you can't claim that due to the error you lost 1 trillion dollars via a software hack - even if it's true. If Intel can prove they acted ethically when disclosing the bug and that they replaced / compensated users up to the value of the CPU, they are in the clear.
olfactory 9y ago
> all companies paying for computing resources will have to pay roughly 30% more overnight on cloud expenses Well, if I rent a VPS with x performance, I still expect x performance after this flaw is patched. The company providing the virtual machine will perhaps have to pay 30% more to provide me with the same product I've been getting. Since most VPS offerings arbitrage shared resources, this will not increase costs of providing VPSes by the full performance penalty.
- jk563 9y ago
  Well if you use m5.xlarge instances from AWS you were getting 4 vCPUs for your money. I don't expect you'll now get 5...
  - olfactory 9y ago
    No, but the underlying hardware that perviously hosted two m5.xlarge instances may instead host one M5.xlarge and one M5.medium, so that performance is not degraded.
    - sbarre 9y ago
      Yeah but AWS doesn't guarantee that "2x m5.xlarge" will meet any kind of performance requirements, particularly your own application's, do they? So you may suddenly find that your own performance requirements, that were previously satisfied by "2x m5.xlarge" are no longer being met by that configuration, and I doubt AWS will just provide you with more resources at no additional charge.
- Sean1708 9y ago
  > Well, if I rent a VPS with x performance, I still expect x performance after this flaw is patched. Are there any providers that state you will get x performance? Most that I've seen say you will m processors, n memory, and p storage but don't make any guarantees about how well those things will perform.
  - Retric 9y ago
ComodoHacker 9y ago
Forgive me my ignorance, but I fail to see how this is such a big deal. Even 50% performance hit/cost increase would be... bearable, computations are rather cheap today. ML and other intensive calculations aren't done on CPU anyway. It's not like technical progress of our civilization is slowed down by 30% or something... On the other hand, shrinking Intel's market share due to bad PR and thus adding some competition into the industry could actually foster that progress.
- cdoxsey 9y ago
  If you run things efficiently you're eaking every ounce of performance out of this hardware. A 30% performance hit means a 30% cost increase. The bigger issue is for things that don't scale easily. That sql server that was at 90% capacity is suddenly unable to handle the load. Sure that could've happened organically, but now it happens (perhaps literally) overnight for everyone all at once. Expect a bunch of outages in the next few weeks as companies scramble to fix this.
  - mkagenius 9y ago
    Should the individual companies hurry to patch it. There is no news of exploit as such.
    - rkeene2 9y ago
      There is now !
      - mkagenius 9y ago
        Intel CEO added - "But when you take a look at the difficulty it is to actually go and execute this exploit — you have to get access to the systems, and then access to the memory and operating system — we're fairly confident, given the checks we've done, that we haven't been able to identify an exploit yet." It seems you need root or physical access to the system as a prerequisite for the attack.
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
rbanffy 9y ago
It's a good thing CPU is fairly compressible. Unless you meter it very carefully, you'll see the performance hit and it'll not impact you that much. Very few of my physical boxes are over 70% CPU utilization on a daily average. It's, however, really bad if you sell CPU cycles for a living. You just lost between 5 and 30% of your capacity. If you have a large building, you just lost part of your parking lot to the Intel Kernel Page Problem building.
- asplake 9y ago
  No vendor can afford to do it at a loss for long. One way or another the customer will end up paying
- devcpp 9y ago
  Problem is, most companies that need a lot of power only care about one thing - peak performance. And they tune it carefully in order to not overspend while guaranteeing minimal downtime. This means that they'll have to pretty much scale their infrastructure up by exactly 30%. That's a LOT for these big clients. Honestly, I'd just make sure the server firewalls are super tight and not take in the future patches. At least for now.
  - ajross 9y ago
    Very very few highly tuned "peak performance" workloads are dominated by syscall overhead like the test that produced that 30% number was. It's best to hold off on the hyperbole.
    - bpchaps 9y ago
      No, but lots of workloads are built with latency in mind. For APIs that talk to each other in long serial chains, don't be surprised if request responses take significantly longer in many, many workflows.
    - dijit 9y ago
      I have a power dependent workload that scales horizontally and is currently already dominated by the cost of system calls. This will effectively, directly cause me to buy 30% more compute on a huge infrastructure. (2,000~physical machines. Quite beefy dual socket machines with a lot of memory) I know I’m not alone. Then again. Think of microservices, Kubernetes for instance; Network requests are system calls.
devit 9y ago
It depends on whether it's an attack against HVM hypervisors or not. If it, like it seems, is just an attack on OS kernels and PV hypervisors, you can simply turn off the mitigation, since nowadays kernel security is mostly useless (and Linux is likely full of exploitable bugs anyway, so memory protection doesn't really do that much other that protecting against accidental crashes, which isn't changed by this). Even if it's an attack against hypervisors any large deployment can simply use reserved machines and it won't have a significant cost.
Iv 9y ago
More than the lawsuit, it attacks one of the core aspect of Intel's brand: performances. Intel chips are supposed to be faster. Now they are suddenly 30% slower because they carelessly implemented performance features over security ones.

by dsign 9y ago

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?
  - leoc 9y ago
    Where’s that quote from? ISTR reading it (or something very similar) as reported speech in a HN comment. Overall it’s a depressing story of predictable market failure as well as internal misbehavior at Intel, if true. Few buyers want to pay or wait for correctness until a sufficiently bad bug is sufficiently fresh in human memory. And if you do want to, it’s not as if you’re blessed with many convenient alternatives.
    - deeth_starr_v 9y ago
      The quote is from the link above (referencing an anonymous reddit comment).
  - mtgx 9y ago
    I think that could also have been the "official reason". The same reason could have been used to give the NSA some legroom for instance, but tell everyone that's why they won't do so much verification in the future.
  - HelloNurse 9y ago
    Obvious hypothesis: first complacency leads to incompetence, then starting to cut corners has catastrophic consequences. The two problems are wonderfully complementary. As other comments suggest, there might be a third stage, completely forgetting how to design and validate chips properly.
    - eximius 9y ago
      Or the system was designed poorly to begin with and now you're stuck with the design for backwards compatibility reasons.
      - HelloNurse 9y ago
        I'd expect engineers that are aware of such serious bugs to spit on the grave of backwards compatibility. After all, the worst case impact would be smaller than the current emergency patches: rewriting small parts of operating systems with a variant for new fixed processors.
  - fpoling 9y ago
    This implies that ARM vendors do less validation. I guess ARM is just so much simpler that good enough validation can be done faster. So essentially this is payback time for Intel for keeping compatibility with older code and simpler to program architecture (stricter cache coherence etc.). It is like one can only have 2 of cheap, reliable, easy-to-program.
    - pkaye 9y ago
      I'm sure ARM vendors have their own problems... it is just that they tend to be used in application specific products so the bugs are worked around. Having come from a firmware background I've worked are tons of ugly workarounds for serious bugs in validated hardware. Furthermore, I just a read an article (can't find the link) that certain ARM Cortex cores have this same issues as Intel.
    - lmm 9y ago
      > This implies that ARM vendors do less validation. I guess ARM is just so much simpler that good enough validation can be done faster. More likely "good enough" is much lower because ARM users aren't finding the bugs. The workloads that find these bugs in Intel systems are: heavy compilation, heavy numeric computation, privilege escalation attackers on multi-user systems. Those use cases barely exist on ARM: who's running a compile farm on ARM, or doing scientific computation on an ARM cluster, or offering a public cloud running on ARM?
  - kabdib 9y ago
    Man, you should see the errata for some ARM-based SOCs. It's amazing that they work at all. Vendor, in conversation: "We're pretty sure we can make the next version do cache coherency correctly." Me (paraphrased): "Don't let the door hit you in the ass on the way out." Management chain chooses them anyway, I spend the next year chasing down cache-related bugs. Fun.
    - djsumdog 9y ago
      ARM is such a shitstorm. At least the PC with UEFI is a standard. With every ARM device, you have to have a specialized kernel rom just for that device. There have been efforts made on things like PostmarketOS, but still in general, ARM isn't an architecture. It's random pins soldered to an SoC to make a single use pile of shit.
      - madez 9y ago
        Why is it an issue to need a different kernel image for each device? I don't see a problem as long as there is a simple mechanism to specify your device to generate the right image. It's already like that with coreboot/libreboot/librecore, and it worked just fine for me.
        kabdib 9y ago
        Imagine that you are the person leading the team that's making an embedded system on an ARM SOC. It's not Linux, so you have your own boot code, drivers and so forth. It's not just a matter of "welp, get another kernel image." You're doing everything from the bare metal on up. (I should remark that there are good reasons for this effort. Such as: It boots in under 500ms, it's crazy efficient, doesn't use much RAM, and your company won't let you use anything with a GPL license for reasons that the lawyers are adamant about). So now you get to find all the places where the vendor documentation, sample code and so forth is wrong, or missing entirely, or telling the truth but about a different SOC. You find the race conditions, the timing problems, the magic tuning parameters that make things like the memory controller and the USB system actually work, the places where the cache system doesn't play well with various DMA controllers, the DMA engines that run wild and stomp memory at random, the I2C interfaces that randomly freeze or corrupt data . . . I could go on. It's fun, but nothing you learn is very transferrable (with the possible exception of mistrust of people at big silicon houses who slap together SOCs).
- innagadadavida 9y ago
  But why do AMD chips not have similar issues? To me it looks like Intel tried to micro optimize something and screwed up.
  - leoc 9y ago
    Maybe the answer lies in Intel’s feted IPC advantage over AMD? Or is it the case that AMD has simply been relatively lucky so far?
  - rayiner 9y ago
    According to LKML: https://lkml.org/lkml/2017/12/27/2 https://lkml.org/lkml/2017/12/27/2 > The AMD microarchitecture does not allow memory references, including speculative references, that access higher privileged data when running in a lesser privileged mode when that access would result in a page fault. Out-of-order processors generally trigger exceptions when instructions are retired. Because instructions are retired in-order, that allows exceptions and interrupts to be reported in program order, which is what the programmer expects to happen. Furthermore, because memory access is a critical path, the TLB/privilege check is generally started in parallel with the cache/memory access. In such an architecture, it seems like the straightforward thing to do is to let the improper access to kernel memory execute, and then raise the page fault only when the instruction retires.
- djsumdog 9y ago
  There are people looking to deploy ARM servers now. However I wish there had been more server competition. Many companies write their backend services in Python, JVM (Java/Scala/Groovy), Ruby, etc. Stuff that would run fine on Power, ARM or other architectures. There are very few specialized libraries that really require x86_64 (like ffmpeg and video-transcoding)
  - astrange 9y ago
    ffmpeg works great on ARM. I don't know if the PPC port is all that optimized lately.
amigoingtodie 9y ago
Sounds like Facebook and Youtube, too.
deleted 9y ago
[deleted]

ashelmire 9y ago

From what I've read, this slowdown only affects syscalls, which, since they aren't usually a huge percentage of processing in the first place, should not have such an effect. You're more likely looking at a few percent at most, which is not going to be enough to make AMD outperform Intel. Let's stop the fear mongering and wait for actual metrics.

mschaef 9y ago
> syscalls, which, since they aren't usually a huge percentage of processing in the first place... Let's stop the fear mongering Agreed! (We should probably also stop overgeneralizing about the nature of computational workloads.)
vardump 9y ago
> From what I've read, this slowdown only affects syscalls Incorrect. It also affects interrupts and (page) faults. Any usermode to kernel and back transition.
- api 9y ago
  So this is evil for virtualization hosting, which is the major enterprise application for Intel chips. Hosting on bare metal will become more attractive. Too bad you can't long OVH and Hetzner.
  - chrisper 9y ago
    >Too bad you can't long OVH and Hetzner. What does that even mean? Also Hetzner just introduced some AMD Epyc server.
    - golfer 9y ago
      "Long" as a verb means to purchase their stock. As opposed to "shorting" a stock, which means making a bet that it will go down in value.

oliwarner 9y ago

As a billion other people have already said, that all depends on their workloads. This isn't a 30% clockspeed deduction.

prudhvis 9y ago
As i understand the problem, this isn't about clockspeed reduction, now it is the software's responsibility to check if the page is a kernel page/user page. So, the impact is significant. So, every time either pages are touched/accessed this check needs to be triggered, which causes it to be much slower.
- DSMan195276 9y ago
  > So, every time either pages are touched/accessed this check needs to be triggered, which causes it to be much slower. Not to be mean, but that's not what is being changed. You're right on the bug - userlevel code can now read any memory regardless of privilege level. However the fix isn't to manually check the privileges on each access - that would be extremely slow and wouldn't actually fix the problem. The fix is to unmap the kernel entirely when userspace code is running. Because the kernel will no longer be in the page-table, the userspace code can no longer read it. The side-effect of this is that the page-table now needs to be switched every-time you enter the kernel, which also flushes the TLB and means that there will be a lot more TLB misses when executing code, which slows things down a lot. So, to be clear, it is not accessing pages that is being slowed down, it is the switch from the kernelspace to the userspace.
  - Cyph0n 9y ago
    But doesn't the CPU enter kernelspace every time a syscall takes place? So based on what you've described, every time a syscall returns control back to userspace, the TLB will be flushed, which means slower page access times in general.
    - DSMan195276 9y ago
      The distinction I was trying to make was the above commenters thinking that the kernel is now checking page permissions instead of the CPU doing it - IE. Doing privileged checks in software. That's not what's happening, the kernel is just unmapping itself when usercode is run so the kernel can't be seen at all. Then the privileged checks (which are now broken) don't matter because there is no kernel memory to read. All your points are right though. Page access times will in general be slower because of all the extra TLB flushes, leading to more TLB misses when accessing memory.

m3kw9 9y ago

Cloud services may not need to worry about the issue depending on the OS the customer choose to use, the patched or non patched version.

ajasmin 9y ago
For the cloud providers it's the security of the hypervisor that's at stake.
chrisper 9y ago
Why would the OS of the customer matter? The patch would be applied to the kernel of the hypervisor / host OS.

frik 9y ago

The other issue here is what MS does regarding Windows 7. It would not surprise me in the least if they tried a clever/efficient patch for Windows 10 and a simpler (and slower) bodge-job for Windows 7/8. Still, I guess we'll find out soon enough. They'd also better make sure that the changes only apply to Intel machines. I don't want MS to arbitrarily slow down my AMD PC as a result of this - you'll note that AMD submitted a Linux patch to ensure their CPUs weren't caught up in this, will MS do the same? Afterall, there is a reason this partnership is called "Wintel", both know it's in their best interest not to screw each other over.

cornholio 9y ago

> claiming for a class lawsuit against Intel If people who received written assurance from Intel that their hardware is 100% bug free can form a legal class, sure. I highly doubt there is even a single one such customer.

golfer 9y ago
Anyone can sue anyone else at any time. If you think Intel isn't going to be sued for this, you're wrong.
- ianai 9y ago
  They need some legal standing or the case can be dismissed out of hand. It may very well be a question of who has the better legal team.
  - AnimalMuppet 9y ago
    > They need some legal standing or the case can be dismissed out of hand. Yes and no. Yes, Intel would get a chance to claim that the case should be dismissed out of hand. To do that, they have to prove that, even assuming all the claimed facts are true, the people suing still don't have a valid case. That's a high bar. It can be reached - there's a reason that preliminary summary judgment is a thing in court cases - but it takes a really flawed case to be dismissed in this way. How flawed? SCO v. IBM was not completely dismissed on preliminary summary judgment, and that was the most flawed case I've ever seen. > It may very well be a question of who has the better legal team. Well, Intel can afford to hire the best. A huge class-action suit can sometimes attract the best to the other side as well, though. (There's not just one "best", so there's enough for both sides of the same court case.) IANAL, but it looks to me like there's at least the potential for a valid court case. CPUs are (approximately) priced according to their ability to handle workloads; if they can't provide the advertised performance, they didn't deserve the price they sold for.
- cornholio 9y ago
  It depends on how they handle user compensation. Going by the FDIV precedent, they should typically replace all defective products for free, and they will be in the clear. What I meant was that the presence of the bug itself is not a valid cause, for example you can't claim that due to the error you lost 1 trillion dollars via a software hack - even if it's true. If Intel can prove they acted ethically when disclosing the bug and that they replaced / compensated users up to the value of the CPU, they are in the clear.

olfactory 9y ago

> all companies paying for computing resources will have to pay roughly 30% more overnight on cloud expenses Well, if I rent a VPS with x performance, I still expect x performance after this flaw is patched. The company providing the virtual machine will perhaps have to pay 30% more to provide me with the same product I've been getting. Since most VPS offerings arbitrage shared resources, this will not increase costs of providing VPSes by the full performance penalty.

jk563 9y ago
Well if you use m5.xlarge instances from AWS you were getting 4 vCPUs for your money. I don't expect you'll now get 5...
- olfactory 9y ago
  No, but the underlying hardware that perviously hosted two m5.xlarge instances may instead host one M5.xlarge and one M5.medium, so that performance is not degraded.
  - sbarre 9y ago
    Yeah but AWS doesn't guarantee that "2x m5.xlarge" will meet any kind of performance requirements, particularly your own application's, do they? So you may suddenly find that your own performance requirements, that were previously satisfied by "2x m5.xlarge" are no longer being met by that configuration, and I doubt AWS will just provide you with more resources at no additional charge.
Sean1708 9y ago
> Well, if I rent a VPS with x performance, I still expect x performance after this flaw is patched. Are there any providers that state you will get x performance? Most that I've seen say you will m processors, n memory, and p storage but don't make any guarantees about how well those things will perform.
- Retric 9y ago

ComodoHacker 9y ago

Forgive me my ignorance, but I fail to see how this is such a big deal. Even 50% performance hit/cost increase would be... bearable, computations are rather cheap today. ML and other intensive calculations aren't done on CPU anyway. It's not like technical progress of our civilization is slowed down by 30% or something... On the other hand, shrinking Intel's market share due to bad PR and thus adding some competition into the industry could actually foster that progress.

cdoxsey 9y ago
If you run things efficiently you're eaking every ounce of performance out of this hardware. A 30% performance hit means a 30% cost increase. The bigger issue is for things that don't scale easily. That sql server that was at 90% capacity is suddenly unable to handle the load. Sure that could've happened organically, but now it happens (perhaps literally) overnight for everyone all at once. Expect a bunch of outages in the next few weeks as companies scramble to fix this.
- mkagenius 9y ago
  Should the individual companies hurry to patch it. There is no news of exploit as such.
  - rkeene2 9y ago
    There is now !
    - mkagenius 9y ago
      Intel CEO added - "But when you take a look at the difficulty it is to actually go and execute this exploit — you have to get access to the systems, and then access to the memory and operating system — we're fairly confident, given the checks we've done, that we haven't been able to identify an exploit yet." It seems you need root or physical access to the system as a prerequisite for the attack.

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

rbanffy 9y ago

It's a good thing CPU is fairly compressible. Unless you meter it very carefully, you'll see the performance hit and it'll not impact you that much. Very few of my physical boxes are over 70% CPU utilization on a daily average. It's, however, really bad if you sell CPU cycles for a living. You just lost between 5 and 30% of your capacity. If you have a large building, you just lost part of your parking lot to the Intel Kernel Page Problem building.

asplake 9y ago
No vendor can afford to do it at a loss for long. One way or another the customer will end up paying
devcpp 9y ago
Problem is, most companies that need a lot of power only care about one thing - peak performance. And they tune it carefully in order to not overspend while guaranteeing minimal downtime. This means that they'll have to pretty much scale their infrastructure up by exactly 30%. That's a LOT for these big clients. Honestly, I'd just make sure the server firewalls are super tight and not take in the future patches. At least for now.
- ajross 9y ago
  Very very few highly tuned "peak performance" workloads are dominated by syscall overhead like the test that produced that 30% number was. It's best to hold off on the hyperbole.
  - bpchaps 9y ago
    No, but lots of workloads are built with latency in mind. For APIs that talk to each other in long serial chains, don't be surprised if request responses take significantly longer in many, many workflows.
  - dijit 9y ago
    I have a power dependent workload that scales horizontally and is currently already dominated by the cost of system calls. This will effectively, directly cause me to buy 30% more compute on a huge infrastructure. (2,000~physical machines. Quite beefy dual socket machines with a lot of memory) I know I’m not alone. Then again. Think of microservices, Kubernetes for instance; Network requests are system calls.

devit 9y ago

It depends on whether it's an attack against HVM hypervisors or not. If it, like it seems, is just an attack on OS kernels and PV hypervisors, you can simply turn off the mitigation, since nowadays kernel security is mostly useless (and Linux is likely full of exploitable bugs anyway, so memory protection doesn't really do that much other that protecting against accidental crashes, which isn't changed by this). Even if it's an attack against hypervisors any large deployment can simply use reserved machines and it won't have a significant cost.

Iv 9y ago

More than the lawsuit, it attacks one of the core aspect of Intel's brand: performances. Intel chips are supposed to be faster. Now they are suddenly 30% slower because they carelessly implemented performance features over security ones.