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.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Comments
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.
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.
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.
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.
I know you don't need me to explain why that is a complete Red Herring in the context of the VZ kernel.
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.
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.
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.
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.)
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
That was likely due to the ME debacle. Intel's premium this year.
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?
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.
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.
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.
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.
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...
.
With CPU's that went end of life about a decade ago I would not worry too much about this.
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?
The less recent CPUs without PCIDs will be impacted more it seems. But it's still all pretty much... speculative
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.
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/