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
I might not be up to date, but: did intel really say something about 5% (performance loss)? From what I saw their statement didn't offer much more than a vague large corp. PR fart.
I think there is an elephant in the room and that is time and timing. Now while I don't believe for even a split second that google is anything but as evil as evil goes and then some I do trust them on this one. Simple reason: It nicely fits both their real security interests and their "do no evil, be a nice netizen" showfront; plus, within their nice showfront they are nice.
Moreover google isn't a nobody. google is both a major heavyweight in the market and a (deservedly) well respected player in the security field. In other words: when google tells intel about a serious problem intel listens and listens carefully. Similar for microsoft. With linux I'm not that sure (just see linus' stupid rant); they really might not have taken the issue as seriously as it should be taken but then there would have been at least some lkms noise.
Summary: the problem is known since quite some months and it was largely kept silent in a coordinated way - which imo can only mean one thing, namely that they agreed on and wanted a fix before going public. Which again means that the problem field is not at all easy to mitigate; if a group like intel, microsoft, and the oss unices don't come up with at least a good mitigation in half a year you know that there must be a galaxy sized cluster fuck under the cover.
From what I see my take is that they originally planned to shut the hole for good and in a way which all parties (read: the business side) could live with. But that seems to not have worked out, probably due to the nature of the problem and some other factors (like intel being distracted by the ryzen and epyc launch which they probably took as being more dangerous and important). There was "the other option", too, namely what we seem to get now, i.e. a mostly software solution with intel not much contributing in terms of hardware or at least microcode.
Finally, so it seems, someone got seriously pissed off and opened the gates ...
All in all I would be very surprised if they came up with a reasonably solid remedy that is cheaper than double digit performance penalty, particularly for servers.
Indeed reading the round of news coverage for this highlights how much work will be involved in fixing this ! What a nice thing to be doing in first week of 2018 !
I'll take the liberty to translate that amd statement: "we are shitting our pants (and don't know much what to do about that problem)".
When governments or large corps say something like "just isolated exceptional problems and only in labs" there's tnt in the shit pile.
Lets hope so.
Oh, i didn't say that. Sure there will be a lot of research in the other direction too but then there is nothing magical about computers. Sure there is brilliant ideas and all that but in the end it comes down to possibilities. I admit i am very much out of the loop when it comes to exploit development but looking back at the numerous tries to mitigate the impact of stupidly simple buffer overflows and how all those cute techniques got circumvented again, again and again i think it's not that far off to at least start with a pessimistic outlook.
haha.. lucky you're not their PR guy ^_^
Microsoft's official update for this is out https://support.microsoft.com/en-us/help/4056892/windows-10-update-kb4056892
Thank god. I was starting to feel I was the only one here who can't draw the internal pathways of a CPU core my sleep.
That's actually good advice.
KVM VPS benchmarks with KPTI patches on E3 1280v5 and Xeon Gold 6138 https://www.phoronix.com/vr.php?view=25779
Nice effort but next to worthless. Laudable: this time they didn't do gaming only but also some (more or less) real world tests. Negative (to the extent of making it worthless): irrelevant scenario, plus too little info. Example: Nobody cares about an apache server existing only for testing; and btw, what was the load?
What would be helpful were tests that, e.g. tested a reasonable number of vms on one server (say > 16) running apache or nginx with a realistic amount of client connections (say, 1000).
Moreover, careful! "KPTI patches" may mean a lot or very little. One decisive question is whether and how far those patches mitigate the problems (as currently known).
I'd be very happy to be shown wrong (hey, I run servers and vpss, too) but until I see properly done and relevant test I don't take the performance loss numbers as being "hyped up".
Just as a small reminder: the memory subsystem is extremely important for performance; in fact, most servers get a higher performance boost from adding ram than from a faster cpu.
I hope you're right.
Yeah but restricted due to time constraints I suspect as to how realistic and involved you can get. I use redis so interested in this numbers too. Though on CentOS at least I could regain some of that lost performance switching from yum provided redis to source compiled with GCC 7.1.2 and appropriate flags for better performance post KPTI patching.
I am not sure even many VPS providers would be scientifically measuring the performance impact of KPTI patches - maybe Amazon AWS/MS Azure and Google Cloud might ? Even if they are testing, it definitely will be along the lines of longer time frame than what Phoronix has to work with
Indeed in a massive threading environment the performance hit will be much higher, but i do not think will be more than 10% when semi-final patches will be pushed and probably around half that in 3 months or more. That is a pessimistic view.
Not pessimistic for OVZ, though, whoever is at the limit with the cpu will feel it extremely badly, the straw that broke the camel. The more switching the higher the impact.
300-500 threads in 12/24 for kvm/xen is doable, 10k with ovz, nope, it aint gonna fly.
I hope it will be way better than this.
Oh, but there is...
Decades ago in a sf story i dont remember where i read, it was about the computers of the future, which would become so advanced and powerful only a handful of people would understand them and most people would treat them like gods, with public booths where they could put a coin and open a line to a computer to pray.
Now, seriously, whoever can say that, didnt have protracted matches with the iron, sometimes winning, sometimes not, with so weird and unexpected problems that do look like magic.
Anyone got significant shit in Azure?
They’re rebooting everything NOW.
That must be fun.
I think I’m going to just go out and straight up murder someone.
My (highly speculative) guess is that somehow some kind of competition of who's first to patch has started and the 9th. Jan. plan is out of the window.
Hint: a windows patch seems to have been made available, so microsoft seems to be going fast.
It would be interesting to learn more about the sudden pressure (after ca. 6 months).
Microsoft have had this in plan for Azure since early Dec, it was postponed to early Jan for some reason (at very short notice), then the public disclosure has pushed them into immediate reboot activity.
yup Microsoft patch is https://support.microsoft.com/en-us/help/4056892/windows-10-update-kb4056892
Android has January security update patch out too.
I wouldn't trust that patch. If you have any chance to do so, I'd keep away for another week or so. I assume that a "more mature" patch is to follow the one hurriedly pushed out one.
The patch is being applied at the host level in Azure, so we’ve got no choice but to trust it.
This smells like they discovered already attempts, maybe even successful to exploit it, so they dont really have a choice.
And still, tons of servers running containers unpatched, wonderfull.
Tons? Almost everything.
Yes. I didn't write it because I didn't want to wildly speculate but the context is strange anyway. First they seem to sleep for months then there is a sudden and spike of interest and noise and now the - not particularly large - patch window is interrupted by sudden patches.
Looks to me as if someone got pissed by the "cool" (ignorant?) attitude over months, possibly after there was reason to believe that exploits are out there (don't forget, they had months of time, too). Probably now an alarm bell rang after a real attack was found and now everybody is in a hurry to send out out patches based on whatever they have achieved so far.
Azure wouldn't jump the gun over nothing, yesterday large partners were told that a reboot is scheduled for the 10th - they obviously know something that we don't.
Or have a different, less impacting solution that will be used as a market advantage ;-).
http://www.businessinsider.de/intel-ceo-krzanich-sold-shares-after-company-was-informed-of-chip-flaw-2018-1?r=US&IR=T
tl;dr what do i have to do with my vm's? just upgrade to the newest os?
Fixes for this don't exist yet for most OSes. All we can do is wait for the updates to come.
Disclosure for this happened a week earlier than planned, so everyone is scrambling to get the updates pushed out.