Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!


Your Intel x86 CPU is Deeply Flawed (Meltdown/Spectre) - Page 3
New on LowEndTalk? Please Register and read our Community Rules.

All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.

Your Intel x86 CPU is Deeply Flawed (Meltdown/Spectre)

1356719

Comments

  • AnthonySmithAnthonySmith Member, Patron Provider

    Neoon said: Its already overdue.

    More people buy OVZ in this market than anything else.

  • NeoonNeoon Community Contributor, Veteran

    @AnthonySmith said:

    Neoon said: Its already overdue.

    More people buy OVZ in this market than anything else.

    Because its cheap and works for most stuff.

    Most people are not aware if you want more security, that OVZ is not a good choice.

    Thanked by 2rm_ maverickp
  • AnthonySmithAnthonySmith Member, Patron Provider

    Neoon said: Because its cheap and works for most stuff.

    Most people are not aware if you want more security, that OVZ is not a good choice.

    And that has not changed in the last 7+ years I have been in the industry, not sure what makes you think this will change anything.

  • adlyadly Veteran

    Unless the fix is backported to the 2.x branch of the kernel then surely providers will have to move to OpenVZ 7 going forward? Even if it is backported in some form the 2.x branch lacks PCID which mitigates the performance loss somewhat, so the hit could be worse.

  • NeoonNeoon Community Contributor, Veteran
    edited January 2018

    Well 2.32 is EOL since 2009, Linux will be not updating it, maybe Virtuzzo will do a Backport, since the Kernel is supported until 2019...

  • jackbjackb Member, Host Rep
    edited January 2018

    @Neoon said:
    Well 2.32 is EOL since 2009, Linux will be not updating it, maybe Virtuzzo will do a Backport, since the Kernel is supported until 2019...

    RHEL and by extension CentOS will backport it. CentOS 6 is supported until 2020.

    Virtuozzo will then presumably merge the fix into vz6. Perhaps it will be such a priority that they could decide to do it before RHEL, though.

  • AnthonySmithAnthonySmith Member, Patron Provider
    edited January 2018

    Neoon said: Well 2.32 is EOL since 2009

    I know you don't need me to explain why that is a complete Red Herring in the context of the VZ kernel.

  • MaouniqueMaounique Host Rep, Veteran

    bsdguy said: "Hogging up" - no. Keep in mind that that code doesn't look different from what runs on machines every second.

    I mean, you would need an insanely high number of reads and moving the read part somewhere else to save it, first because the cache lines are small, second because you need quite a few reads from the same area to be able to make sense of it and that data must not significantly change during these operations which means they will have to be very frequent, i.e. hogging the cpu, albeit, maybe, timed attacks and crafted code to request in cache the required bits can probably be imagined, it will likely work on single task machines, NOT in a massively shared environment such as a virtualization node where the attacker has no control over what his neighbours do and on which cores and even physical CPUs each with own cache, controller and stuff.

    bsdguy said: Where (I guess) you are right is that it wouldn't be exactly practical to get at exactly the right, say, 64 bytes (a cache line) out of megabytes of kernel.

    Exactly, and on a virtualization node with many tenants, usually hundreds, this is all but impractical, unless you can really use close to 99% of the CPU for you only, at least for a short time.

  • NeoonNeoon Community Contributor, Veteran
    edited January 2018

    Intel's CEO sold a ton of Stock a few months ago:

    https://www.fool.com/investing/2017/12/19/intels-ceo-just-sold-a-lot-of-stock.aspx

    "Krzanich is keeping the bare minimum"

    Seems like they saw it already comming in.

    Thanked by 3Yura szarka rm_
  • raindog308raindog308 Administrator, Veteran

    bsdguy said: I guess this one is far worse than the floating point fuckup many years ago.

    Oh hell yeah. The FDIV bug was really more about how not to handle a customer recall - in fact, it's a case study on it in many business schools. If Intel had acknowledged the bug, published microcode, and immediately offered replacements to anyone who requested one, we'd have all forgotten about it. The number of people who actually cared about that bug or were affected by it was tiny. By fighting it and dragging their heels, they made it 100x worse.

    From what I've read, problems of the FDIV variety are not that uncommon, though that particular one was worse than most. All CPUs have microcode published to fix bugs and it's common practice for Intel/AMD to publish errata, release microcode, etc.

    It's just that fixing bugs doesn't usually rob your CPU of 30% of its performance...

    The FDIV story is covered in loving detail in the excellent book, In Search of Stupidity, which is actually a book on marketing but has many fun stories like FDIV from the first couple decades of personal computing (Borland's debacles, Ashton-Tate's demise, Microprose's failure, Novell's suicide, etc.)

    Thanked by 1Aidan
  • MasonRMasonR Community Contributor

    As we await further news/benchmarks, what are the types of applications that are bound to take the biggest performance hit from the kernel patch once it's released?

    As @bsdguy already pointed out, the biggest impact will likely be seen by I/O-bound applications. I'd imagine things like game servers and mining programs won't take too much of a hit, rather things like high-trafficked web servers and database servers will take a large performance hit. What other impacts will we likely see?

    On a similar note, anyone know any good hosts in the states with Ryzen servers? :P

  • Neoon said: "Krzanich is keeping the bare minimum"

    Seems like they saw it already comming in.

    That was likely due to the ME debacle. Intel's premium this year.

  • DamianDamian Member
    edited January 2018

    raindog308 said: All CPUs have microcode published to fix bugs and it's common practice for Intel/AMD to publish errata, release microcode, etc.

    Wasn't the original Pentium the last Intel CPU to NOT have writable microcode, which the FDIV bug is what spurred Intel to make it a feature of the Pentium Pro and all subsequent CPUs?

  • WSSWSS Member

    @Francisco said:

    AnthonySmith said: So, unless some security workaround is found, all of a sudden it is 2011 again and everyone wants Xen PV again for performance.

    No, PV has the patch enforced, which means the performance hit is there.

    Jury's out on if HVM/KVM is affected.

    Francisco

    I would assume it only matters if you expose the CPU, but then, that doesn't have to be a passthrough, either. With that simple kernel module posted before on LET which let you (un)set kernel parameters, that won't be creating a module-based exploitable (which was my concern about these sort of issues in that thread), as the new patches make cpubugs static with the separate tables, so if you're running KVM, I don't see it being directly applicable with an emulated CPU- but this is highly speculatory.

  • jarjar Patron Provider, Top Host, Veteran

    @Francisco said:

    AnthonySmith said: So, unless some security workaround is found, all of a sudden it is 2011 again and everyone wants Xen PV again for performance.

    No, PV has the patch enforced, which means the performance hit is there.

    Jury's out on if HVM/KVM is affected.

    Francisco

    Rest up! No sense in sounding the alarms yet since we just don't have the data, but we'll all need to be good and rested should that change.

    Fingers crossed for "only impacts KSM" :)

  • This explains why I have 100+ Azure VMs scheduled for maintenance in the next 2 weeks I guess.

  • @Nekki said:
    This explains why I have 100+ Azure VMs scheduled for maintenance in the next 2 weeks I guess.

    By 10th of January afaik. Some Azure VMs can be restarted by you before then, but any that cant or werent are going to be restarted on the 10th. Thats my information at least.

  • @MagicalTrain said:

    @Nekki said:
    This explains why I have 100+ Azure VMs scheduled for maintenance in the next 2 weeks I guess.

    By 10th of January afaik. Some Azure VMs can be restarted by you before then, but any that cant or werent are going to be restarted on the 10th. Thats my information at least.

    You can reboot yourself from 2-9 Jan after that reboots are scheduled for you (taking accoun of availability sets) from 10-21 Jan.

    Thanked by 1MagicalTrain
  • adlyadly Veteran

    Someone already created a PoC for this, and the advisory is still embargoed.

  • NeoonNeoon Community Contributor, Veteran

    @adly said:
    Someone already created a PoC for this, and the advisory is still embargoed.

    The bug exist since 10 Years, I am pretty sure that it was used before.

    Thanked by 3adly steny netomx
  • raindog308raindog308 Administrator, Veteran

    Damian said: Wasn't the original Pentium the last Intel CPU to NOT have writable microcode, which the FDIV bug is what spurred Intel to make it a feature of the Pentium Pro and all subsequent CPUs?

    You may be right - I don't remember. My point was that processor errata and fixups after manufacturing were not unknown before the FDIV bug. That bug really only became famous because of how Intel handled it.

  • Does anyone knows any link with the complete list of Intel CPUs affected? Also can this impact "our" home/office desktop computer or only affects servers in datacenters?

    If it can impact "our" home /office desktop computer, does anyone knows if there is something we can do? I have 2 desktops at the office with Core2Quad CPUs and i'm worry...

  • YuraYura Member
    edited January 2018

    .

  • AnthonySmithAnthonySmith Member, Patron Provider

    nqservices said: If it can impact "our" home /office desktop computer, does anyone knows if there is something we can do? I have 2 desktops at the office with Core2Quad CPUs and i'm worry...

    With CPU's that went end of life about a decade ago I would not worry too much about this.

    Thanked by 1netomx
  • MaouniqueMaounique Host Rep, Veteran

    I also keep a lot of core2 and centrino products.
    As I see it from Intel's advisory, there is no issue which is not fixed in ME/etc?

  • mfsmfs Banned, Member

    The less recent CPUs without PCIDs will be impacted more it seems. But it's still all pretty much... speculative

    Maounique said: As I see it from Intel's advisory

    There's no advisory on this flaw yet

  • Sniff.. Sniff... Do I smell a class-action lawsuit?

    I don't know how American justice system works except what I've learned from Hollywood, but you guys sure love class-action lawsuits and mass refunds. Maybe I can get my home CPU upgraded for free.

    Thanked by 1hostdare
  • @Harzem said:
    Sniff.. Sniff... Do I smell a class-action lawsuit?

    I don't know how American justice system works except what I've learned from Hollywood, but you guys sure love class-action lawsuits and mass refunds. Maybe I can get my home CPU upgraded for free.

    A couple of lawyers are going to get millions and you will receive $5, maybe $10 and a mouse pad with Intel logo.

  • Darwin said: and you will receive $5, maybe $10 and a mouse pad with Intel logo.

    Thanked by 2netomx MikePT
  • DamianDamian Member
    edited January 2018

    Darwin said: A couple of lawyers are going to get millions and you will receive $5, maybe $10 and a mouse pad with Intel logo.

    and that last half is a "maybe", because you're going to be contacted a ridiculous number of years after the item is no longer relevant and you've completely forgotten about it and can't prove ownership, ala https://cnet.com/news/optical-disc-drive-settlement-claim-sony-optiarc-nec-hitachi-lg-panasonic/

Sign In or Register to comment.