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
Lets roll some unixbench before upgrading and after, lets see how much we loose.
Confirmed Kernel KPTI fix reduced haproxy performance ~17% https://lkml.org/lkml/2018/1/3/281
and I'm observing a performance loss of ~17%, making the connection
rate go down from 245k/s to 204k/s. It's indeed quite significant for
such use cases, eventhough I think it might reasonably be absorbed by
usual noise in most use cases.
yup https://www.theregister.co.uk/2018/01/05/spectre_flaws_explained/
Because unixbench benchmarks real use case scenario surely.
"pCI: we have confirmation that KVM is immune to guests reading HV or other guest memory via variant 3 (aka meltdown). KVM is NOT "impacted" by Meltdown. So, right now, a guest VM cannot read another VM's memory, neither the HOST 's memory."
https://twitter.com/olesovhcom
So they did updates or are they claiming Google's tests were wrong?
Francisco
Sounds to me like, they claim google is wrong.
For me personally I'm not rushing into any reboots for KVM clients unless I have to. CloudLinux has had spotty results with their patches so I would be scared of suddenly panicing a bunch of nodes with it from a live update.
I'm waiting to see what OpenVZ does. Depending on their turn around it'll decide how hard I press to get people moving.
Francisco
I'm sure Google has a PoC showing to the contrary. Surely they haven't made claims without confirming it first.
Google's tests involved a serial port inside of the VPS, so maybe that's where the potential problem was?
Francisco
I don't recall that ever to have been the case. Virtually the only player, perhaps, i.e. having most market share by far, but the only player?
Of course competition stimulates... everything, otherwise we would all work in state companies, each a monopoly and produce, when we have what to produce with, substandard products which barely can be called that.
There are objective factors in that, nobody can really break the laws of physics, albeit bending is possible...
x86 is an old platform and has a lot of deadweight with it from 30-40 yers ago, maybe more. As long as you could put more transistors in the same space it worked a treat, now the limits of physics are at hand and radical new ideas (existing) and market traction (not existing) as well as enough capital willing to be invested (ehm... so-so, this is high risk and high cost to invest, unlike facebook or google and the like).
The phones/tablets and IoTs will drive the innovation now, servers and desktops in particular, not really...
So we must expect lower progress from anyone.
I do not say we do not need AMD, ARM, others, we do, i only say that this is the human nature, imagine this flaw would have been AMD-centric instead of Intel-centric, the few people using AMD would have been bashed for being cheap instead of buying a real product from the leader, took some shady half-baked chip from half-wits. Same is with apple, who cares they slow it down, we buy it anyway to keep up with the fashion, if you buy junk phone, expect a junk job at McDogFood or WallNut.
We need more POT for HEROES!
Issue is not Intel centric. There's so much noise about Intel merely because Intel is the top one. As you know the issue affects Intel, AMD, ARM and even Apple CPUs.
I mean, I prefer my phone to be stable for the intended lifespan, which in my case is 2 years, not for it to crash when opening something that clocks CPU a bit higher because of my battery being less fit than before due to my usage of it. My only issue would be if this was happening through the warranty period and they would deny fixing, but it's not the case, I had a battery replaced once with them, under warranty, free of charge.
The situation is quite intransparent and complex, but from my understaning it's as follows:
Meltdown "only" affects the security within a VM, but doesn't allow to breach the node's security on hardware-virtualized (!) systems. VMs can be protected against this flaw by an isolation of the Kernel pages (i.e. KPTI in Linux).
According to https://www.qemu.org/2018/01/04/spectre/ a Kernel update is sufficient to protect the host against Spectre-2 (CVE-2017-5715). A new Kernel version has been released for CentOS 6 and CentOS 7 (and probably other distributions as well).
To protect the VMs against Spectre-1, we will probably need to update the CPU's Microcode, the OS kernel (including KVM) and QEMU.
Please correct me if I'm wrong.
Yes, it is intel centric. It is like saying, hey, that guy has cancer, the other a rash, they are both ill. The more performance you squeeze from this against security, the more exposed you are.
Of course you do, if this was done by a chinese or korean company you would have said they are battery hogs and the bateries are shit anyway, look how cheap they are and how easy to change without service, they must have known they suck and sell you subpar products, they even catch fire, but who cares, as long as they are cheap...
At apple, of course you would never think to change the batter at 100 USD a piece, better buy another phone. The car's tires are worn out? It automatically slows down to protect you from accidents until you buy another car.
Intel(R) Core(TM) i5-4460 CPU @ 3.20GHz 5717.2 => 4646.0 (23%)
Intel(R) Core(TM) i3-2130 CPU @ 3.40GHz 3813.9 => 3313.5 (15%)
Intel(R) Atom(TM) CPU N2800 724.9 => 578.1 (25%)
Debian 9 on all of them.
Intel(R) Core(TM) i3-2130 CPU @ 3.40GHz 3813.9 => 3313.5
Intel(R) Atom(TM) CPU N2800 724.9 => 578.1
Fack.
So are CPUs that do not support out-of-order execution (i.e. Intel Atom) also affected?
The patch seems to apply to atoms, however I got told you can pass a parameter so the patch wont be applied, Theoretically you should get your performance back then.
edit:
/etc/default/grub, set GRUB_CMDLINE_LINUX="nopti"
then run "update-grub"
Time, to kill of VM's and move everything to bare metal.
..and then OVH put the prices up.
Scam?
If a lot of people would switch, sure the prices will go up.
But there are a lot of providers and I think that like 70% are like why?
I mean there was a security issue, it is now fixed, so why brother migrate?
Only a few people I guess will migrate, not many.
There needs to be something bigger, to force them to migrate.
Are machines running a grsec kernel protected?
Adding more to the CPU pit:
http://www.pcgamer.com/watch-the-meltdown-cpu-exploit-in-action/
After reading this from StackExchange, https://security.stackexchange.com/questions/176631/just-how-bad-is-spectre, it seems like both AMD and Intel will have the Spectre issue, while Meltdown is only under Intel? If I read that right
redhat/centos tunables to disable/enable kernel patched performance impact https://access.redhat.com/articles/3311301
So i googled a little. The Atom N2800 is based on intel's saltwell microarchitecture, which is explained here: https://en.wikichip.org/wiki/intel/microarchitectures/saltwell
According to that page, this CPU does not support speculative execution. Therefore it should not be vulnerable and should not need a patch.
Can someone try the proof of concept exploits against an N2800 CPU and confirm?
Just curious, is speculative execution a synonym for branch prediction? Keep seeing these pop up and get confused which one is which
As Intel holds the rights over x86 production. They & they alone decide who's allowed to compete against them in the market.
The only reason why AMD is allowed to compete - is due to Intel wanting to avoid getting slammed with the Sherman Act (among others).
A number of providers (namely Online.net and DigitalOcean) are claiming that KVM is not vulnerable to Meltdown due to the way KVM is architected. Still vulnerable to Spectre though.
Looks like good news for KVM providers, but still expect to see patches/updates applied sooner rather than later especially as some are already including Spectre mitigations (RedHat).