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
So people knows what I am doing, legit question, what's the danger of that?
They will know I am running apache, mysql, why should I consider this dangerous?
Glad most of our VPS nodes are AMD based except last few that we got Intel E5
Going to setup a new OpenVZ Node today, will disable HT and see how the performance goes
But it seems it's time completely ditch Intel as new vulnerabilities are coming out every few days
Rubbish probably
It's an OpenVZ node and our nodes CPU usage is usually low, so it should not be bad, lets see how it goes
To check if the vulnerabilities are mitigated or not you can run this shell command:
for x in $(ls /sys/devices/system/cpu/vulnerabilities/*); do echo -n $x " "; cat $x; doneOutput for an OVH VPS with the latest Debian kernel (4.9.168-1+deb9u2):
Zombieload = MDS (Microarchitectural Data Sampling)
Note the "no microcode".
I don't think that there's an entry for mds before a patch is applied.
There will be if the kernel is updated, even when the microcode is not yet updated. The output above is actually an example of this: most recent kernel, no microcode update.
Not seeing the MDS vulnerability means the kennel was not updated.
Yes, I meant a patched kernel.
The latest Debain kernel 4.9.168-1+deb9u2 now got it patched partly to get rid of SMT I think you need to disable hyper-threading.
/sys/devices/system/cpu/vulnerabilities/mds Mitigation: Clear CPU buffers; SMT vulnerable
Does anyone know if the patches apply to KVM instances which got live migrated to a patched host? I guess yes?
(I know that the VM also need updates)
Please refrain from benchmarking your multi core vps for a few weeks.
I'd hate to make our low end providers sleep any harder.
There will always be a certain percentage of stubborn 'curious cats'.
Initially it was a more shared system based on merged cache and actual physical cores (i.e. Bulldozer architecture on consumer side, which was sold as "Dual core" but more like SMT/HT on cocaine with the FlexAPU) with a different instruction pipeline design - back then AVX and AES were introduced at AMD and Bulldozer was a huge improvement (albeit a lost war later).
Actual SMT akin to Intel only exists since Zen, Bulldozer had the "FlexFPU" per core and Interlagos (server SKU) shared cache but was due to multi CPU another design. The APUs (eg. AM1) i am not sure - i think my AM1 demo sys here actually simply has 4 actual cores like Atoms did at some time.
In Zen it does the same as Intel but data is.. scarce, you just talk software to it ultimately. We know from past (overclocking, per level DIE shots eg. by der8auer etc., power usage, voltage) that Intel has parts of a "core" per actual core 'attached' and performance does differ in some generations, both bench very similar to their physical core and cost some % power (varies a lot, atom is in-order mostly with partly HT and a whole other topic entirely, insanely efficient).
AMD seems to share cache not directly as the basic function would imply since the P4 times which counteracts some attacks by design (and might be required for the Game Mode on TR/multi-DIE & for Infinity Fabr... ahhh lets not get started on that). Intentional? I doubt it but such things happen not rarely.
I want to point out that AMDs market share and supposed popularity (as in bad) nowadays + low sales are not the reason for no exploits, they sell very good and are investigated similar now. It might be not a planned design choice to be protected partially (or even a workaround/late eng hack way after core design) but it works apparently, sometimes.
Youtube has some Zen and Bulldozer architectual walkthroughs and ex/current engineers of Blue & Red detailing some things (eg. on GamersNexus a few also for GPUs) but it is... boring if you are not into the subject lol
Sorry, it's also boring if one is into the subject, even more so.
In fact, gaming is in a way "the symbol" of the opposite of security. Why? Because it almost brutally focusses on what created the nightmare in the first place.
Explanation: In the beginning (similar to OSs being designed along the line "security? Sure, we have a password check" (if even that)) weren't designed with security in mind. "security" then would mean to e.g. not accidentially bleeding registers onto the internal bus, i.e. it was purely technical.
Later, much later security (as we understand it today) begin to trickle into the minds. And a typical response was what intel did with protected mode or ring 0. One reason why I like both of those examples is that they also show what was really the main concern: performance. That was what drove intel and the others. The market had grown dimensionally very quickly and along with it the customers greed for ever more power (and bang for the buck). Even then (at a relatively late stage) security was an afterthought at best - and the fact that more security pretty much always meant "at the cost of performance" didn't exactly help.
Well noted, this is not an attack on intel. They are a company and a company wants to make profit, the more the better. Plus, intel merely gave the customer what they demanded. And security wasn't on their wish list. And if it (rarely) was then that was seen as something that was to be solved in the OS.
Short, processor design was done under the assumption that everything within the processor was to be trusted. And the force that drove processor design for decades was power. Pretty much only power.
All the things that would fall under "security" (in any way) like ring 0, PRNGs, etc. were (a) added, just like a bigger L1 cache or vector instructions were merely added, and (b) still under the assumption "within the processor everything can be trusted" (and in extension "security is something software (be it the OS or firmware) is in charge of").
Today we see the result. But again, it's not as simple as "intel is evil". It was the expectation and the point of view that has changed and now security is a big thing. intel merely did what a processor company does: It delivers what customers want - and customers for decades wanted performance at pretty much any cost.
That explains both why many, many more processors vulnerabilities will see the light of day, and why it's so hard (and quite often next to impossible) to design in security after the fact and into something that has (quite wildly often) grown largely driven by one parameter only, performance.
That battle was lost before it began, not the least because the enemy is hardly visible and the battle field is almost entirely his. And again: the main culprit is we, the customers. Even bloody today the "more performance!" clientele is vastly outnumbering the "security, please" clientele.
The solution: Whole new generations of processors with a quite different mindset at design time. That, however, creates another problem: software. Yes, there is quite good support for e.g. Risc-V - but: will companies with gazillion lines bodies of code just create new products for the new processors? I have doubts based on severeal reasons. Plus, per definitionem we can't possibly have experience and a good track record with a new processor generation, and formal testing only goes so far (if we have the tools, which we don't yet have), etc.
There might be another solution, though, a much more feasible one: intel stripping all unneeded cruft (AMT anyone?) or at least puts it into another chip outside the CPU plus they create a new "security co-processor" (much like in the old times there was a dedicated math co-processor) that is !trustworthy! - which btw is a very hard thing to do (both, to design and to regain trust).
Reason: Actually security can almost always boil down to very little. A couple of instructions (like prng), a bit (really just a bit) of memory, etc. You see, it's not the 5 GB of data that are critical, it's the 256 bits of key and some more bits hash, all in all less than a KB. Now, evidently such a co-processor should also have a fast cache, say, some MB, etc. but I guess you get the gist.
As a big fan of capitalism i have no preference anyway, i use the best priced possible option for my requirement - competition is nice
I do not blame Intel for most (nearly all) of this attacks as yea some things as... prediction overall in nearly any way... are just dangerous by design for a gain somewhere else.
I am already very happy the world runs on AMD64/Intel64 nowadays - the change looked grim first with hardware, then drivers (brr XP 64) and finally software just to demolish the 32bit legacy into.. legacy then. Without this change we would have far other problems than speculative execution exploits (some of which are also enabled by todays raw computing power enabled by ingenious designs that benefited the entire industry and many others at an accepted - KNOWN - risk).
EDIT: I do however blame Intel for releasing more CPUs - entire generations even - before hardware fixes for some things are rolling out slowly now and general mismanagement of their FABs (chipsets in 32nm are still fine with 14nm capacity at limits, reserving capacity for them is.. dumb) plus horrible rip off for "enterprise" features standard on cheap shit AMD APUs and other architectures (ECC -- Non Standard CPU PCIe lane splitting eg. 4x4/8x2 on 16x, not 8+8/8+4+4 mostly forced etc.).
Simpler is:
So prem:
New microcode updates? Performance loss incoming....
There is a new Linux kernel parameter:
mitigations=offthat turns off all these mitigations. It defaults toautowhich turns on all mitigations but leaves SMT enabled, and there isauto,nosmtwhich disables SMT if needed. With this parameter, there is no need to keep track of all the vulnerabilities for most users.Maybe intel should offer some firmware switches, too. Like e.g. "live dangerously on the fast lane" and "safe - for the moment. With 7% of performance left" ...
xD Be cautios what you wish for
Intel Performance Hit 5x Harder Than AMD After Spectre, Meltdown Patches
The performance hit seems really bad. I think probably would be good to some hardware replacements to AMDs for older/lower end chips for providers. If something happens on the servers without patching due to cost considerations, it's the provider that gets blamed, not Intel.
More and more AMD look like they are going to take Intel's place at the top of the CPU market in the next few years.
I think this will spook commercial customers because it looks like an architectural flaw that needs extensive re-design and the end result may well be that Intel's chips are actually not that much more powerful than AMD, just that they went for some risky shortcuts. Pretty much people have been fooled into paying a hefty premium for "performance".
Disclosure: my first PC was a 486 from AMD
still really not sure what to make of all this but for what it's worth, I've been informed about reboots for patching by only two hosts so far (LaunchVPS and InceptionHosting).
This is probably more dangerous than anything Huawei can pull lol
eh ... it's tricky since (as has been pointed out) the current proof-of-concept is not quite (yet) "head on fire" status such as was the case with heartbleed - and the patches themselves tend to introduce new unknowns (aka vulnerabilities) as well as a performance hit.
while I would hesitate to speculate on the relative probabilities involved, would just say "citation needed" if someone were to claim p < 0.05 "moral certainty"
(And I sure don't know nothing about none of that huawei stuff, boss
)
bottom line for me (with nothing much at stake in the current scenario) - just have to appreciate the few brave hosts who are diligent in doing the needful (while I can also appreciate the instinct for the rest of the crowd to hang back a bit to see what happens first).
I'm not with those 2 hosts, but so far only AnyNode has mentioned the patch from the dozen or so hosts I have services with.
I was really not sure what to make of that either, seems a lot of providers are worried about the performance hit?
Most of our VPS Nodes are AMD based, we added 2 Intel vps nodes this week, already disabled HT in them, but going to wait for few days before we apply these patches or microcode updates to our Intel Based Node, as i remember last time some microcodes/patches created a lot of trouble initially and took multiple patches/updates to finally give a proper patch
No emails from any of about 14 providers I do use.
That really, makes it secure.
I suspect they just run kernel care and suspect its magically fixed.
Speaking of magical, when does ColoCrossing finally gets IPv6?