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
For what exactly?
Oh I'm sure people will think of something
I have a lot of AWS.
My PV instances are scheduled for a maintenance window in 2 days. My HVM instances are not.
Rest of that post describes my thought process.
Your own link says to the contrary
That moment when your press release could've been a tweet: https://newsroom.intel.com/news/intel-responds-to-security-research-findings/
Well that sure is a whole load of "Don't tell us we did worse than anyone else"
That moment when your press release could've been a tweet: https://newsroom.intel.com/news/intel-responds-to-security-research-findings/
"It's their fault, not ours" - can't say that wasn't expected.
People get mad at a certain political leader for just tweeting off the top of his head but damn, I wish others would do the same. Intel could've tweeted "ain't just us" and saved me minutes of my day. Professionalism is so 2001.
It's kind of sad when Wendys tweets are more accurate, amusing, and professional than a technology company.
Fuck. ARM, too.
This will be rather... Unpleasant
https://www.phoronix.com/scan.php?page=article&item=linux-more-x86pti&num=1
Somewhat ironically, I did actually fit the core takeaways into a tweet - although those are probably the takeaways Intel doesn't want you to think about...
Reproducing them here for completeness:
That list being derived from looking at what Intel doesn't say in their damage-control press release. But yeah, pretty much what we already knew/expected.
https://www.forbes.com/sites/rogerkay/2014/11/25/intel-and-amd-the-juggernaut-vs-the-squid/#3d1fcc202981
It's perhaps reasonable to think the design was a conscious decision. Some of the benchmarks show a 30% hit, or in reverse, a 50% gain.
Best read about this until now:
https://security.googleblog.com/2018/01/todays-cpu-vulnerability-what-you-need.html
In addition to this with more details on how they actually made it work: https://googleprojectzero.blogspot.com/2018/01/reading-privileged-memory-with-side.html
With an extract from the Google post:
The
detailsuser-friendly explanation appears to have been released: https://meltdownattack.com/Already fixed in MacOS?
That's why I stopped and called it too speculative. We simply don't know. If something like ASLR 2.0 (tm) can be and is made to work then, yes, because - at least for some time - some kind of a needle in the haystack or of a scan through loads of garbage for something interesting approach would be needed which translates to a need to get at massive amounts of kernel data. It is my personal guess that something like an aslr 2.0 path is looked for and worked on by the kernel people.
If that is not the case, however - and there seems to be a considerable risk of that being the case - then, no, because only relatively few accesses (kernel data slices) are needed.
Let's wait and see. I personally don't bet a lot on virtualization protecting us. One major reason is the fact that, again, virtualization happens way above the level we're talking here plus the fact that virtualization on x86 usually does not emulate the processor (but just some critical parts with "critical" not meaning what this case here is about).
Google documented some funny business with KVM but it seems to be quite time consuming, but I could be reading it wrong.
Francisco
Servers are particularly heftily fucked but keep multithreading and other forms of ring switching in mind, virtualization being a major one.
So, the typical office desktop will feel a bit sluggish but plus minus OK. Same with gaming machines (end user). Mining strongly depends on the OS and the configuration; mining itself/per se isn't concerned but keep in mind that mining like everything else doesn't run in air but on an OS. Otherwise mining will depend strongly on its architecture, on the way it's designed. Having it done basically on GPUs with just some controlling and housekeeping code on the cpu won't suffer much, idle cycles mining on the other hand might become very sluggish.
Important "but": No matter how hard it is, we will have to wait for what intel (and arm) and the kernel people come up with. While the problem itself is almost certainly not fixable by firmware/microcode that doesn't mean that intel can do nothing. Chances are that intel will be able to tweak at least some bits so as to make much less costly what the kernel people come up with. I'm absolutely in the grey zone of speculation here but I don't expect a penalty of 25 or 30%. I'd rather expect something in the range of 10 to 15% and getting better over some time (weeks and months).
But also keep in mind that we are talking about the kernel here, so the involved engineers won't be too easy going and ready for funny experiments; the general attitude will almost certainly be rather conservative. Neither intel nor windows or linux need another scandal created by acting now in a mix of pressure and performance greed. The decisive factor will be "what can we do without risking to introduce new problems?".
Is the reason why this cannot be fixed by microcode something that can be broken down for me in relatively simple terms?
Which ends up being another good point that it's frivolous, since I heard about it before June 2017.
Why can't we just trust the terminators to make all of our technology? Last time I checked, human-made terminators died off quickly, terminator made terminators took a whole damn movie to kill just 1.
Just an additional link.
Cloudlinux is looking into it when patches get released for both cloudlinux and kernel care products: https://cloudlinux.com/cloudlinux-os-blog/entry/intel-cpu-bug-kernelcare-and-cloudlinux .
They are posting updates on the article as they have more info
I posted an inquiry about any plan of action from my host Scaleway, which I just got since I had never really used any VPS service before: https://community.online.net/t/how-is-scaleway-affected-by-the-speculative-execution-bug/5833/1
Their forum isn't usually very active, though, and I won't hold my breath on this since they may have security concerns with being too specific on this.
Am digesting all papers yet and what I will say is at most a educated guess.
This bug exploits an important optimization in code execution.
Considering that microcodes are not public documented and architecture/processor model dependent, I can only speculate there isn't a way for Intel to patch that via microcode. I will bet that this optimization is so damn hardwired in Intel CPUs that this fix needs to exist at OS level.
AMD Master Race.
Xen says AMD is affected and 'thinks' ARM is affected too https://xenbits.xen.org/xsa/advisory-254.html