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
It is not Intel-centric, but the reason much of the fuss is about Intel is not the one you state.
The variant called "Meltdown" only affects Intel, unlike the two variants called "Spectre", which have a much broader scope. Meltdown was speculated on first, as the public disclosure had to be rushed because people were already inferring what was going on based on kernel patches / discussions. Spectre came as part of the same disclosure but I don't think people had already guessed on it. Meltdown is also much more immediately exploitable.
Hence the fuss currently being about Intel... although many people I've heard from seem convinced that Spectre is barely even an issue on non-Intel, which I believe to be far from the case in the long run.
Which cloud providers are affected by Meltdown?
Cloud providers which use Intel CPUs and Xen PV as virtualization without having patches applied. Furthermore, cloud providers without real hardware virtualization, relying on containers that share one kernel, such as Docker, LXC, or OpenVZ are affected.
source: https://meltdownattack.com/
The ones that stay silent are probably the ones affected ;-)
@rick2610 Google initially mentioned KVM as being vulnerable, hence the - pardon the pun - speculation.
@datanoise ArubaCloud haven't said anything, as of yet, and they aren't vulnerable to Meltdown (VMWare ESXi). I've applied the Debian update to my VMs so PTI is enabled, but they haven't updated the node so the CPU info showing CPU_INSECURE isn't yet being shown.
I like this table SolusVM made:
Virtuozzo have committed to a beta patched kernel today for Virtuozzo Linux 7 (and presumably OpenVZ?). No solid dates for Virtuozzo/OpenVZ 6 but they have stated they do intend to patch.
You probably will have to reboot for the Intel microcode update even if you have KernelCare.
I'm definitely going to wait a few days after these patches come out. Probably till after the Intel microcode is released and gets tested and probably some more patches for that.
There are no known exploits in the wild so I don't think people should be running around like chickens with their heads cut off.
CloudLinux people are talking about adding option flags to disable some of the changes because of the performance hit.
Someones already posted github link to unofficial patched VZ kernel on OpenVZ forums, but I don't know if its legit.
Always feel more excited getting owned by an unknown one?
This inevitable security religious argument is kinda like saying you should not cross the street because it's dangerous. Well thanks for that helpful advice. Properly tested and complete fixes are not even out yet.
If you are so frightened by connecting computers to the internet then maybe you should do something.
TL;DR; ~25% performance loss is the point at which people consider to take the risk of living with the probably biggest known security hole (yet) by leaving it unpatched on their servers/computers...
netcup has silently rebooted everything I have with them ~3 hours ago, anyone else?
Email warning was sent out.
See: https://forum.netcup.de/administration-eines-server-vserver/vserver-server-kvm-server/9515-umgang-mit-sicherheitlücken-in-cpus-meltdown-spectre/
oops you're right, I missed that
not here, so probably yours were in the first batch ;-)
I took the liberty to emphasize "known". One of the things that became painfully understood with the current cluster fuckup is that there are unknown - or should I say "kept unknown"? - vulnerabilities and security holes.
So the real question for many might actually be "am I willing to accept a considerable performance loss to plug 1 hole while there are who knows how many other severe fuckups?"
Let's be realistic: the x86 is rotten to the core (pun intended). No matter how much performance penalty one is willing to take, no matter how many tools (AV, etc.) one is running - there just is no such thing as a secure x86 system.
The architecture is rotten, the OSs are more or less rotten, many vital libraries are rotten, most languages widely used do not even allow for reasonably safe software creation - and I should be concerned enough about a not at all simple and rather exotic security hole to considerably slow down my system for "security"? Nope. Bad deal.
Anyone really caring about security simply avoids x86. Being at that: Let us make sure that the promising light on the horizon, the Risc-V, isn't all but captured and exclusively controlled by an intel-like behemoth again. Because that is the real problem: large corps caring only about the next billion in profits and smirkingly fucking billions of people along the way.
P.S. If you really want reasonably secure systems you need a government that brutally punishes large corps like intel and microsoft whenever a fuckup is detected. Trust me, if those corp. bosses would personally loose multimillions when their companies create clusterfucks there would be virtually none.
I was told they won't be rebooting anything until the 8th, but both of my nameservers magically went down for a few minutes. I was able to tell it wasn't just a network glitch because my time was different from when they shutdown to current (I have my shit ntp'd, and they weren't yet accurate)
Not really. It's more like saying that you shouldn't cross the highway because cars tend to drive fast and it's known that people get hit easily, and you say "well I don't see any cars right now so what are you panicking about". It only takes one car on the known-dangerous road to kill you. Whether you see it coming is irrelevant, and by the time you do it'll be too late.
EDIT: Here's your car, by the way.
@bsdguy reminds me a lot of myself.. around 2001-2002. ALL SHALL BOW BEFORE SPARC!
I also believe that you should change the title of the thread, as it isn't only Intel/x86 affected here.. but I can live with it, unlike @bsdguy.
Thank you. Now I see the light. What the current clusterfuck, heartbleed, and plenty other nightmares actually demonstrate is, how secure and well everything is.
[Explanatory side note: I take most images in a forum discussion to mean that the one using them wishes to communicate that he's an idiot]
@WSS well, the title isn't 'wrong'. Intel CPUs are 'deeply flawed' (Meltdown), the rest are just 'flawed'.
These poorly-constructed car analogies need to stopped! (See what I did there?)
Unless you read the thread, you could possibly take away from it "My phone/tablet/etc are OK tho". Mostly it's a playful poke at both @bsdguy and @raindog308. 'Cuz they're bros.
Well Intel says its a general problem
"No. This is not a bug or a flaw in Intel products. These new exploits leverage data about the proper operation of processing techniques common to modern computing platforms, potentially compromising security even though a system is operating exactly as it is designed to. Based on the analysis to date, many types of computing devices — with many different vendors’ processors and operating systems — are susceptible to these exploits."
What a joke, these suckers, Intel is one of the most affected one.
Yes and no. It's a bit more complicated. Superficially they are all about equally fucked up with intel processors being slightly worse than the others. Looking closer, though, intel is clearly the culprit. Reason: x86 is intels baby; intel sets the x86 standards and amd can't but be compatible. intel created the utterly poor way spec. exec is done on x86 and even if amd knew better they for the biggest part just had to implement the same shitty mechanism (or else their processors would be incompatible).
As for arm, oh well, they all "inspire" one another. Another example of that cross breeding is the unholy intel management engine and "trusted" shit, only that this time it went the other direction; arm was the inventor ("trustzone") and intel pretty much copied the mechanism.
For what it's worth, there's a reason why it's called 'AMD64' for the implementation that won, IA64, which was used in the Itanium, was designed by HP.
Look at how far back the current cluster fuck reaches: pentium 4 and even 80386. The spec exec mechanism was nailed down way before amd64.
As I said, intel is condemned to carry along loads of shit and amd is condemned to implement most of that shit, too. "Compatibility" is the holy cow.
Its a fucking flaw, Intels design is garbage, they keep selling it and people keep buying it.
Linus Torvalds "Will Intel sell "Shit for forever and ever"?
Intel knew that, before they released there new CPU line, they keeped it secret for another 6 months, wankers.
The CEO even sold all his shares, and people still use that shit? The Company does not give a fuck about the costumers as you see.
I was not illustrating any specific bit of poor design which has pegged x86 throughout the years, but that Intel is not solo to blame in this shit-show.
There's always hope for Oracle to start building Suns again.
Any idea when will we get a patch for FreeDOS ?