CPU Vulnerabilities, Meltdown and Spectre, Kernel Page Table Isolation Patches, and more

That's odd that Mozilla didn't recommend enabling that in their mitigation recommendation.

That First Party Isolation add-on only installs in Mozilla 58 or above, even though the privacy.firstparty.isolate value exists in previous versions - even in 52.5.0.

"First-Party Isolation is not enabled by default in Firefox right now. One reason for that may be that the feature may interfere with the authentication system on some sites.

I suggest you try this out, and see if that is the case on your end. You can disable the security feature at any time to restore the status quo.

1. Load the URL about:config?filter=privacy.firstparty.isolate in the Firefox address bar.
2. Double-click on privacy.firstparty.isolate to set the preference to true.

This is all that needs to be done. There is also the Firefox add-on First Party Isolation which you can install instead. It does the same thing, but comes with an option to disable the functionality temporarily. (via Bleeping Computer)"

There is another value shown in the example:
privacy.firstparty.isolate.restrict_opener_access
but it's not there in my version of Firefox, so I created it and set it to true:

 

I think it is solely the compatibility issue...

 

sorry to bring this from 5 pages back but as i've been putting off new hardware for many years (pc->donated ancient compaq laptop->donated macbook 2010, i can't bear to keep it another 2 months tbh, let alone 2 years), and desperately "in the market" for a new setup, this whole thing comes at an amazingly aggravating time, so...

i would love to wait, if nothing more than for the principle at stake, but realistically won't this be quite some time (2-3+ years?) down the road? i mean, even setting aside the fact that further generations of production/research/corporate financial model are already planned years in advance (i know extremely little but afaik cannon->ice lake having the same microarchitecture, so problem will persist eh), wouldn't this is still be a yuuuuuge task, even if they immediately !!!halt everything!!! and start fresh today? Which obviously they won't/can't afford to do, infamous greed aside, it would be an immense burden even for an entity with pockets as deep as intel, so it probably makes the most sense/only realistic outcome is to continue releasing kaby lake-based 10 microarchitecture while slowly working on a future "solution? (not to give an ethical judgment one way or the other, just saying 'business is business' so not gonna happen eh)

Not to discuss/debate intel morality, or delve into the fine points of the whole fiasco or anything; I just mention that paragraph to display average clueless consumer (as myself) feeling of powerlessness/acceptance. In other words, for all the knowledgeable people here, correct if this is wrong: being realistic, a truly "new" microarchitecture-->new CPUs that are designed fresh to address these flaws, won't be coming out for several more years? So I might as well bite the bullet, suck it up, and buy the crap that they shovel for me to throw money at " "

 

its more of a hardware level fault, rather then pointing out at microsoft, intel should be shamed, not microsoft, ateaslt on os level they are trying to fix for the messes intel made..

 

Well, Micro$loth already has plenty to be ashamed of without this. Windows 8. Windows 8.1. Now, Windows 10. Pointing the finger at Intel, for them at least, for totally screwing things up would be like the pot calling the kettle black, LOL.

Believing there is such a thing as security as it relates to computers of any kind is like believing in Santa, the Easter bunny, leprechauns, and unicorns. As long as there are bad people that want to exploit things, security will be an elusive myth that makes money for the bad guys and the security software companies pretending to be good guys. Everyone in the middle is getting screwed in one way or another. It will either be a voluntary or involuntary robbery.

 

It's all up to personal taste. But for me, I've got enough computers infected with the flaws already, I don't need to buy any more

So I can / will wait, and hopefully AMD - which has the least exposure and is the most nimble to turn changes - can come up with a non-performance losing solution that doesn't require slow mitigation in OS's to accomplish the fix(es).

There will likely be additional "discoveries" coming over time, so it might be a while before "it's time" to put them all into a new CPU.

If you are "ready to buy", I'd recommend AMD for the CPU / motherboard.

AMD is cheaper for the same performance as Intel, and has the added advantage of having AM4 / TR4 sockets with 4 year time spans of useability.

AMD might only give 2 years of cutting edge support - with 2 more years of CPU turns that back fit most of their CPU improvements, hopefully including a "fixed" AM4 / TR4 compatible CPU.

vs Intel that changes socket compatibility as often as it drops CPU flaws, you can be assured that Intel - if they had their way - would issue a new "fixed" CPU that "needs" new motherboard chipset - with or without a new socket.

 

Or just go chinese RISC chips... LOL

 

What are you basing the bolded part on? Seems to me like the exact opposite is historically true of AMD. More than a decade of lurking in the shadows with only garbage for CPUs and still nothing actually any good with GPUs. Yes, they did a really good job with Zen (finally), and their recent work brought them a very long way from their lackluster history, but it sure took them a long time to show any effort that resembled decent progress.

 

It's going to be a while before they can release a clone of a "fixed" CPU, Intel / AMD need to make it first.

VIA To Release 8 Core X86 CPU
http://forum.notebookreview.com/threads/via-to-release-8-core-x86-cpu.812432/

 

Those are x86, I'm talking RISC, such as:

• MIPS, by Silicon Graphics (ceased making MIPS-based systems in 2006).
• SPARC, by Oracle (previously Sun Microsystems), and Fujitsu.
• IBM's Power Architecture, most famously known for its use on many Macintosh computer models until late 2005 with the POWER-derived PowerPC architecture, and in many of IBM's supercomputers, midrange servers and workstations.
• Hewlett-Packard's PA-RISC, also known as HP-PA (discontinued at the end of 2008).
• Alpha, used in single-board computers, workstations, servers and supercomputers from Digital Equipment Corporation, Compaq and HP (discontinued as of 2007).
• RISC-V, the open source fifth Berkeley RISC ISA, with 64 or 128-bit address spaces, and the integer core extended with floating point, atomics and vector processing, and designed to be extended with instructions for networking, IO, data processing etc. A 64-bit superscalar design, "Rocket", is available for download.
  
  

 

ThreadRipper.

AMD was in the middle of Epyc, and on a whim decided to fashion a consumer version of Epyc and both made it out of production successfully.

AMD is hungry and needs to keeping whooping Intel, so I don't think they will leave this opportunity on the table.

Intel has a lot of "mental" baggage about this problem, and I doubt they are going to turn on a dime with a successful effort - they keep blowing any innovations and only seem to be able to build innovation through iteration.

Hopefully they will make a design that is flexible and can adapt to security changes down the road, to move even quicker.

It will be fun to watch both compete to be the first to release fixed CPU's.

For now the consistency of AMD supporting socket compatibility for many years with backwards support for every generation over the 4 year life span makes it the best choice to get right now if you want a chance to just slip in a fixed CPU down the road.

 

Coincidently, RISC-V is used in Nvidia Tensor cores as well. But, china has been developing them and has even used them in supercomputers.
https://www.pcworld.com/article/308...-chip-powers-the-worlds-fastest-computer.html

 

Well, this bugfest requiring CPU architecture changes in hardware to fix it provides a once in a generation opportunity for another technology solution to gain a foothold.

Maybe China will get a CPU family out in time that has what people want in their laptops and desktops.

What people want is drop in compatibility with existing software, OS's and applications.

RISC won't do that, except for OS's with source that can be recompiled and made compatible.

IDK, RISC has been around for a long time now, and hasn't taken over x86/AMD_64 in any sizable fashion...

 

https://en.wikipedia.org/wiki/Reduc...ter#Workstations,_servers,_and_supercomputers
Evidently, ARM is even a type of RISC, so it comes down to HOW the RISC chip is designed, which also explains ARMs relatively small number of designs exposed.

 

Again, it's not happened yet, and this snafu isn't going to give enough time for a non-compatible CPU to come forward.

Intel or AMD could do it, grown out of X86/AMD_64, but that's because they have the franchise rights, but I don't think any other CPU would get Microsoft to build for it, they've already tried it a number of times, and failed.

I've developed hands on with RISC hardware of many kinds since the inception in the early 80's, and I have long since lost the faith in it taking over Intel/AMD, but if you have the drive to make it happen, go for it!!

 

Yes, I get all of that and things should (hopefully) continue to be much better for them. I just did not understand the bolded part, because they do not have a strong history of showing nimble response to change or progress. Perhaps you are just looking forward and hoping their current success will become status quo, and that's fine. I think we all want them to continue to do well. Well... maybe not the Intel worshipers, but people that are eternally committed to specific brands rather than demanding the nothing short of the best are just stupid.

Micro$loth really needs to get their act together and start showing signs of excellence like AMD has. They're just not very good at what they do any more.

 

AMD need 2 more cores to perform as a lightly oc'd 6 core Intel i7. And with terrible single threaded performance compared, on top. Nope

 

The X86 has the writing on the wall. It is a matter of when, not if. As the power of ARM increases in HPC and grows in IoT, along with the adoption of open source, linux/unix based systems (greed of corporations are literally driving the adoption of linux and android systems across multiple ecosystems), along with devlopment of RISC for AI (literally, google's and Nvidia's solutions are on RISC), I can see it taking awhile, but it should take over without much complaint.

Not exactly true. On research, they are INSANELY good. Just that research doesn't always make it to the products. Most of what made it to Ryzen was shelved or developed, at least in large part, years before Ryzen.

EDIT: They also do a lot for creating industry standards, including on RAM, among other things.

 

I said the same thing while working on discrete RISC and investigating chip implementations, it's only a matter of time, that was literally 34 years ago...

So, be prepared for the long haul

 

I'll wait for it. After all, my first system I ever used was RISC (SunMicro FTW)!

 

Fair enough. There is a certainly place for research.

I only give credit for results though, and for the longest time there just wasn't any. Faith without works is dead and knowledge without implementation is worthless. But, I am glad to see things are finally starting to move the right direction for them. If they get the overclocking thing fixed so they can match or beat Intel on clock speeds, then they'll definitely have a winner that cannot be ignored no matter who you are.

 

The issue there was who was at the helm, the acquisition of ATI stretching them WAY too thin, and GloFo costs bleeding them dry. Between all of that, they couldn't implement such great tech. Now, with Ryzen, they designed an Enterprise chip as a last ditch effort, then expanded it to an entire product stack. From here, without the threat of bankruptcy, and with a hungry team of engineers with great ideas, and of course the master coming back to help for the initial design, as well as him still consulting while working on embedded for Tesla, I think they will make really good strides. In fact, if I'm correct, Intel is going to hit the wall hard at 10nm and the rest of the industry will pass them by. If VIA gets it together and uses TSMC 7nm by 2020, we could see a hell of a shakeup from 2020-23.

 

Now, that would really be something. VIA has not been an important player in computing for years, and that would be more of a shakeup than we have ever seen. They've got a long road ahead of them before they can be taken seriously. That would be nice though. I'd love to see all three of them in a bitter and bloody battle.

 

Speculation Control Validation PowerShell Script
This is described in the blog topic: "Windows Server guidance to protect against the speculative execution side-channel vulnerabilities."
https://gallery.technet.microsoft.com/scriptcenter/Speculation-Control-e36f0050

Find out if your Windows PC is affected by Meltdown/Spectre vulnerabilities
by Martin Brinkmann on January 05, 2018 in Windows - Last Update: January 05, 2018
https://www.ghacks.net/2018/01/05/f...affected-by-meltdown-spectre-vulnerabilities/

"Microsoft created a PowerShell script that returns whether your Windows PC is still vulnerable or if you don’t have to worry about the vulnerabilities at all.

https://gallery.technet.microsoft.c...e36f0050/file/185106/1/SpeculationControl.zip

Here is what you need to do:

1. Load an elevated PowerShell prompt. Tap on the Windows-key, type PowerShell, hold down the Shift-key and the Ctrl-key and select the PowerShell entry to load it.
2. Type Install-Module SpeculationControl
3. You may get a prompt stating that “NuGet provider is required to continue.” Select Y to accept that.
4. You may get a prompt stating that you are installing an “untrusted repository.” Select Y to continue.
5. Type Import-Module SpeculationControl.
6. You may get an error stating that “running scripts” is disabled. If you do, type Set-ExecutionPolicy RemoteSigned. Repeat the command Import-Module SpeculationChannel.
7. Type Get-SpeculationControlSettings.

Tip: You can restore the default ExecutionPolicy setting by running the command Set-ExecutionPolicy Default.

The PowerShell script displays information about the vulnerability and available (installed) mitigations at this point."

"It is a bit hard to read, but true means that protection is available while false means that it is not. If you have installed yesterday’s Windows patch already, you should see some “true” listings there.

The script lists suggested actions to mitigation the issues that are still active. It is required to install a BIOS/firmware update to address those. How that is done depends on the manufacturer of the device.

Microsoft published additional information here."

Windows Server guidance to protect against speculative execution side-channel vulnerabilities
https://support.microsoft.com/en-us...-to-protect-against-the-speculative-execution

 

u know what they say, if its not broken dont fix it.

 

I can see you find the end results

 

PSA: Severe vulnerabilities in fundamental CPU design disclosed. One bug (Meltdown) affects all modern Intel CPUs, while another (Spectre) affects all CPUs from all manufacturers. Patch your machines to avoid exploitation.
https://www.reddit.com/r/pcmasterrace/comments/7o5si5/psa_severe_vulnerabilities_in_fundamental_cpu/

Major Intel CPU Hardware Vulnerability Found
https://www.techpowerup.com/forums/...dware-vulnerability-found.240168/post-3779201

Performance impact of Windows patch and BIOS update (0606) on i7-8700 on ASUS PRIME Z370-A motherboard using Realbench 2.56.
https://www.reddit.com/r/pcmasterrace/comments/7obokl/performance_impact_of_windows_patch_and_bios/

Before & After KB4056892, i7-4790k
https://www.reddit.com/r/pcmasterrace/comments/7o2a7i/before_after_kb4056892_i74790k/

 

the difference seems little, but i want to see the big number decrease so i have a reason not to patch LOL so lazyy. i had some quick read at places i dont remember now but they say programming in different language especially in compiling takes the biggest hit, i'd like to see that, though i dont compile or write any software.

 

Spectre/Meltdown Vulnerabilities - AWS please clarify
https://forums.aws.amazon.com/thread.jspa?threadID=270647&tstart=0

Spoiler: Details...

"Posted on: Jan 5, 2018 11:16 AM
I think Amazon needs to be more transparent about this. At the time of writing this reply, the only information provided your bulletin ( https://aws.amazon.com/de/security/security-bulletins/AWS-2018-013/) on how AWS infrastructure is protected against all currently known vector attacks for Spectre and Meltdown is:

"All instances across the Amazon EC2 fleet are protected from all known threat vectors from the CVEs previously listed. Customers’ instances are protected against these threats from other instances. We have not observed meaningful performance impact for the overwhelming majority of EC2 workloads."

Can you please elaborate? What mitigations have been put in place to prevent information leaks in multi-tenant environments? Are you going to share those with the Xen project? They seem to be rushing to provide patches for some of the attack vectors ( http://xenbits.xen.org/xsa/advisory-254.html), but are still trying to figure out how to deal with others (Bounds-check bypass).

Even if all known attack vectors are currently mitigated in your platform, it is clear that new forms of attacks will be developed in the near future and that the ultimate solution may be a hardware upgrade. In light of that, can you provide an honest assessment of the risk of data being leaked in a multi-tenant environment now and in the foreseeable future? How big is that risk and how does it compare to the risk of data leakage via other exploits? If you see no risk at all, can you please explain why in enough technical detail?

Thanks"

"Posted on: Jan 6, 2018 12:54 AM
Why was this question ignored? How Amazon plans to move forward from this will determine whether we choose to continue our relationship with AWS or switch to a different service provider. Our workload depends heavily on mapreduce performance, and already we have begun to notice performance degradation due to the updates implemented for Intel processors in patching Meltdown.

On Azure, Microsoft has announced their release of Lv2-Series VMs utilizing AMD's Epyc processors. ( https://azure.microsoft.com/en-us/b...series-vms-powered-by-the-amd-epyc-processor/)

Currently, though AWS is used in majority, we already have a portion of our workloads running on Azure for some specific tasks. Why shouldn't we just switch completely to Azure during our next upgrade cycle, something coming up very soon mind you and now being heavily expedited because of this ? In addition to jfargas' statements on general security, even if everything is ultimately patched, and I highly doubt that ever comprehensively happens, the performance degradation that will never go away from such mitigation means increased costs for every moment we continue to stay with our current infrastructure.

I will be completely honest that transitioning from AWS to Azure will likely be a pain with parts of our pipeline that we currently have set up, and if at all possible I would like to be able to continue sticking with AWS. Ultimately, however, if our hands are forced, we can and will go with the service provider that meets our needs. If no new information is released soon, it is highly likely that a decision will be made to move a large percentage our future workload needs onto Azure during our next performance upgrade review meeting, as so far Microsoft is currently the only provider that has confirmed their release of Epyc server instances. If Amazon can make some kind of official comment or notice on future hardware releases, even if it's just a quick confirmation that Epyc server instances will be available at some point, I likely can convince my team to stay with AWS even if it means waiting a little bit longer for new server instance availability.

I've always been a fan of AWS, and hopefully Amazon can ensure that I won't need to learn how to use Azure anytime in the near future. Otherwise, ¯\_(ツ)_/¯."

Question about pending scheduled reboot
https://forums.aws.amazon.com/thread.jspa?threadID=270695&tstart=0

Spoiler: Details...

Posted by: ChrisP@AWS
Posted on: Jan 4, 2018 10:25 PM

Hi,

The Jan 4 reboot covered the maintenance that was originally scheduled for Jan 6. Apologies for the disruption caused by the expedited reboot at short notice. Our hand was forced by the premature public disclosure of the MELTDOWN & SPECTRE security vulnerabilities in Intel CPUs:

https://aws.amazon.com/security/security-bulletins/AWS-2018-013/
https://meltdownattack.com/

Due to the immediate risk that these vulnerabilities could have been exploited by malicious actors to gain unauthorized access to private data stored each on every one of our customer's EC2 instances in AWS, we had no choice but to take immediate action in patching and rebooting impacted infrastructure.

Let us know if you have any other further questions or concerns.

Kind regards,
Chris

AWS fix for Meltdown and Spectre not compatible w/ Centos6 official patch?
https://forums.aws.amazon.com/thread.jspa?threadID=270777&tstart=0

Spoiler: Details.com

"Posted on: Jan 5, 2018 1:36 PM

Hi,
I have an EC2 instance that was deployed from the official Centos marketplace AMI for Centos 6 x86_64 (PV). The host underneath my instance was rebooted yesterday due to the Meldown and Spectre patch. My instance came back up fine. Today I did a "yum update" which installed a new kernel from CentOS for Meltdown+Spectre:
kernel-2.6.32-696.18.7.el6.x86_64.rpm

No other new packages were installed.

The system now refuses to boot (per the console log, it freezes in the boot process prior to loading the kernel).

To verify this is potentially systematic with Centos6, I just deployed a brand new vanilla ec2 instance based on the Centos marketplace AMI for Centos 6 x86_64 with updates. Here is the AMI id:

CentOS 6 x86_64 (2014_09_29) EBS pv-1-adc4348e-1dc3-41df-b833-e86ba57a33d6-ami-809020e8.2 (ami-bc8131d4)

The system booted fine. Then I logged in and did a "yum update" (nothing else). The update completed successfully (all packages and kernel to bring the system to the latest Centos officiall release version). Now this new system refuses to boot (the console log stops just prior to loading the new kernel) as well.

Any assistance would be appreciated."

"Posted on: Jan 5, 2018 2:21 PM

FYI, this is not limited to CentOS 6, and it's not limited to the other particulars noted in the OP.

I'm seeing the exact same problems with a CentOS 4 image that has been running on AWS for years."

"Posted on: Jan 5, 2018 3:03 PM

Hello,

Recently published Red Hat/CentOS kernel version - kernel-2.6.32-696.18.7.el6.x86_64 is failing to boot on a para virtual instance. This is a known issues which is under investigation with Redhat. We will reach out to you as soon we get any update on the issue.

At this time, The workaround changing grub configuration to boot to previous kernel (other than 2.6.32-696.18.7.el6.x8664). This will reduce security on the instance as kernel 2.6.32-696.18.7.el6.x8664 was released to address recent vulnerability disclosed in CVE-2017-5753, CVE-2017-5715 and CVE-2017-5754.

Or using a updated new Redhat version AMI that already has fixes in place."

Forum: Amazon Elastic Compute Cloud (EC2)
https://forums.aws.amazon.com/forum.jspa?forumID=30

 

@hmscott
https://www.pcper.com/news/Storage/Meltdowns-Impact-Storage-Performance-Really-Issue

looks like NVMe flash SSD get hit the most, while sata based nand SSD not so much, weird. 900p optane improves.. LOL

 

TL;DR

How to know if I already installed the patch? And how to avoid it from installing?

 

These answers have already been posted, but I know it's hard to find the solid info for all the noise postings. It's also a changing situation, so you will need to keep yourself up to date, read posts here and information elsewhere on the progress forward.

You can check the #1 post for most of the useful things to know, but not everything worth knowing is in there.

Here's a nice summary answering your question, the top 3 things to do.

Meltdown and Spectre Mitigation: 3 Things to Do Now
https://blog.barkly.com/meltdown-and-spectre-mitigation

Here's another similar summary:

How to Check and Update Windows Systems for the Meltdown and Spectre CPU Flaws
https://www.bleepingcomputer.com/ne...stems-for-the-meltdown-and-spectre-cpu-flaws/

Here are the equivalent posts in this thread:

Spoiler

Just a few posts back, on this same page
http://forum.notebookreview.com/thr...up-to-30-percent.812424/page-29#post-10659304

http://forum.notebookreview.com/thr...up-to-30-percent.812424/page-23#post-10658898
https://www.catalog.update.microsoft.com/Search.aspx?q=2018-01

http://forum.notebookreview.com/thr...up-to-30-percent.812424/page-25#post-10659175

http://forum.notebookreview.com/thr...up-to-30-percent.812424/page-26#post-10659183

http://forum.notebookreview.com/thr...up-to-30-percent.812424/page-26#post-10659246

http://forum.notebookreview.com/thr...up-to-30-percent.812424/page-26#post-10659234

 

Yeah. Sorry about that. I'll go check on these links now.

 

Open services.msc and disable Windows Update service and you won't get anything. You can also block communication with Micro$loth in your hosts file.

 

I totally agree with you 100% on that.. That is what I always do


By the way....I'm a control freak.. I don't know why I say that or have relation to this topic but I'm sure it made my windows never got formatted for 2 years straight now and I'm on the way of going 3 years

Knowledge is power.... that is all what I'm gonna say

 

Epic Games blames Meltdown CPU performance issues for Fortnite downtime
https://www.theverge.com/2018/1/6/16857878/meltdown-cpu-performance-issues-epic-games-fortnite

They are probably using the patch as a scapegoat for their server issues, but it is possible considering all the talk of performance impact. Not that I play that game though.

 

Epic Games blames Meltdown CPU performance issues for Fortnite downtime
By Tom Warren@tomwarren Jan 6, 2018, 12:51pm EST
https://www.theverge.com/2018/1/6/16857878/meltdown-cpu-performance-issues-epic-games-fortnite

"As the technology industry continues to react to two major CPU bugs, we’re starting to see early signs of performance issues from security patches designed to fix the problems. Epic Games has released a chart of CPU usage after it patched its back-end services to address the Meltdown vulnerability. It shows a roughly 20 percent increase in CPU utilization, immediately after the patches were applied. The company released the chart to “provide a bit more context” around recent login issues and stability with its Fortnite game.

“All of our cloud services are affected by updates required to mitigate the Meltdown vulnerability,” says an Epic Games spokesperson in a forum post. “We heavily rely on cloud services to run our back-end and we may experience further service issues due to ongoing updates.” Epic Games warns that issues may continue next week as the company works with cloud providers to address the issues and prevent further problems arising.

Intel has been rolling out firmware updates to protect against the Meltdown and Spectre CPU vulnerabilities. The flaws affect nearly every device made in the past 20 years, and could allow attackers to use JavaScript code running in a browser to access memory in the attacker’s process. That memory content could contain key strokes, passwords, and other valuable information. Cloud platforms are the most at risk, as multiple customers typically share the same CPU hardware so any security issue could hit multiple businesses at the same time. Cloud providers have been patching fast, and Intel says it has made “significant progress” rolling out updates to protect against Meltdown and Spectre.

Intel has admitted that performance issues will be “ highly workload-dependent,” and that further software updates should help. Some Linux admins are reporting performance impacts, and it’s clear we’re only just starting to understand how this could impact internet services.

If you look at their CPU usage monitoring graph, it's pretty clear from the jump in CPU usage abruptly starting and consistently increased moving out from that point that it's due to a change, the patches being applied.


Meltdown and Spectre Fixes Arrive - But Don't Solve Everything
Author: Lily Hay Newman 01.06.1811:30 AM
Two vulnerabilities that shook the entire computer industry are finally getting fixed. So how much should you still be freaking out?
https://www.wired.com/story/meltdown-and-spectre-vulnerability-fix/

"This week, a pair of vulnerabilities broke basic security for practically all computers. That's not an overstatement. Revelations about Meltdown and Spectre have wreaked digital havoc and left a critical mass of confusion in their wake. Not only are they terrifically complex vulnerabilities, the fixes that do exist have come in patchwork fashion. With most computing devices made in the last two decades at risk, it's worth taking stock of how the clean-up efforts are going.

Spoiler: Details...

Part of the pandemonium over addressing these vulnerabilities stems from the necessary involvement of multiple players. Processor manufacturers like Intel, AMD, Qualcomm, and ARM are working with the hardware companies that incorporate their chips, as well as the software companies that actually run code on them to add protections. Intel can't single-handedly patch the problem, because third-party companies implement its processors differently across the tech industry. As a result, groups like Microsoft, Apple, Google, Amazon, and the Linux Project have all been interacting and collaborating with researchers and the processor makers to push out fixes.

So how's it going so far? Better, at least, than it seemed at first. The United States Computer Emergency Readiness Team and others initiallybelieved that the only way to protect against Meltdown and Spectre would be total hardware replacement. The vulnerabilities impact fundamental aspects of how mainstream processors manage and silo data, and replacing them with chips that correct these flaws still may be the best bet for high-security environments. In general, though, replacing basically every processor ever simply isn't going to happen. CERT now recommends "apply updates" as the solution for Meltdown and Spectre.

As for those patches, well, some are here. Some are en route. And others may be a long time coming.

"Everybody is saying 'we're not affected' or 'hey, we released patches,' and it has been really confusing," says Archie Agarwal, CEO of the enterprise security firm ThreatModeler. "And in the security community it's hard to tell who is the right person to resolve this and how soon can it be resolved. The impact is pretty big on this one."

Rapid Response
Meltdown, a bug that could allow an attacker to read kernel memory (the protected core of an operating system), impacts Intel and Qualcomm processors, and one type of ARM chip. Intel has released firmware patches for its processors, and has been working with numerous manufacturers, like Apple and HP to distribute them. Intel has also coordinated with operating system developers to distribute software-level mitigations. Patches are already out for recent versions of Windows, Android, macOS, iOS, Chrome OS, and Linux.

The other bug, Spectre, involves two known attack strategies so far, and is far more difficult to patch. (And in fact, it may be impossible to defend against it entirely in the long term without updating hardware.) It affects processors from Intel, ARM, AMD, and Qualcomm. Browsers like Chrome, Firefox, and Edge/Internet Explorer all have preliminary Spectre patches, as do some operating systems. But Apple, for example, has said it is still working on its Spectre patches, and hopes to release them within a few days.

"One of the most confusing parts of this whole thing is that there are two vulnerabilities that affect similar things, so it's been challenging just to keep the two separate," says Alex Hamerstone, a penetration tester and compliance expert at the IT security company TrustedSec. "But it's important to patch these because of the type of deep access they give. When people are developing technology or applications they’re not even thinking about this type of access as being a possibility so it’s not something they’re working around—it just wasn't in anybody’s mind."

Cloud providers like Amazon Web Services are working to apply patches to their systems as well, and are grappling with corresponding performance slowdowns; the fixes involve routing data for processing in less efficient ways. Google released a mitigation called Reptoline on Thursday in an attempt to manage performance issues and has already implemented it in Google Cloud Platform.

The average user shouldn't see significant performance changes from applying Meltdown and Spectre patches, except perhaps with processor-intensive tasks like video editing. It even seems like gaming won't be significantly affected, though the vulnerabilities exist on so many chips going back so far that it's hard to say for sure.

Consumers frustrated with the risk the vulnerabilities pose and their potential impact have brought three class action lawsuits against Intel so far, filed in California, Indiana, and Oregon.

Everything That's Left
Though many of the most prominent manufacturers and software makers have taken steps to address the issue, countless smaller vendors and developers will inevitably become stragglers—and some may never directly address the flaws in their existing products at all. You should be especially vigilant about applying every software update you receive on your devices to reduce your risk—but don't bank on your four-year-old router ever getting an update.

Experts also note that the rush to push out patches, while necessary, makes the ultimate efficacy of these early updates somewhat suspect. There hasn't been much time for extensive testing and refinement, so slapdash fixes may not offer total protection, or could create other bugs and instabilities that will need to be resolved. This process will play out over the next weeks and months, but will be particularly significant in industrial control and critical infrastructure settings.

"You can't bring down a power grid just to try out a patch," says Agarwal. "Industrial systems, hospital machines, airline control systems—they will have to wait. They can’t just patch and hope that things will work out."

Meanwhile, actors looking to exploit Meltdown and Spectre will be hard at work perfecting attacks—if they haven't already. So far there is no evidence that either vulnerability was known and exploited in the past, but that can't serve as definitive assurance. And attackers could find novel ways to exploit either bug, particularly Spectre, that could circumvent the patches that do come out.

Security researchers say that the vulnerabilities are difficult to exploit in practice, which may limit its real-world use, but a motivated and well-funded attacker could develop more efficient techniques.

Though possible, exploiting Meltdown and especially Spectre is complicated and challenging in practice, and some attacks require physical access. For hackers, the vulnerabilities will only get tougher to exploit as more devices start to get patched. Which means that at this point, the risk to the average user is fairly low. Besides, there are easier ways—like phishing—for an attacker to try to steal your passwords or compromise your sensitive personal information. But more high-value targets, like prominent businesses, financial institutions, industrial systems and infrastructure, and anyone a nation state might be after will all have reason to be concerned about Meltdown and Spectre for years to come.

"The serious thing for me is the unknown," TrustedSec's Hamerstone says. "There may be attacks in the wild, so not knowing what’s coming and not knowing how something is going to be exploited is tough."

Meltdown Town

• Meltdown and Spectre are as devastating as they are complicated. Here's how they work, and why they're such a menace.
  
  
• It's also the latest in a string of rough security lapses for Intel, including a recent, critical vulnerability in its Management Engine.
  
  
• Not to mention a vulnerability that it finally fixed this summer—after seven years.

How Tier 2 cloud vendors banded together to cope with Spectre and Meltdown
Posted 6 hours ago by Ron Miller (@ron_miller)
https://techcrunch.com/2018/01/06/h...d-together-to-cope-with-spectre-and-meltdown/

"Earlier this week news broke of a pair of massive chip vulnerabilities dubbed Spectre and Meltdown (for an explainer see this post). We learned that the larger cloud vendors like Amazon, Google and Microsoft have been in touch with chip vendors and have been working behind the scenes to mitigate the vulnerabilities.

But what about smaller cloud hosting vendors like Linode, OVH and Packet who were not in the inner circle? How were they coping with it?

Spoiler

Details have begun to emerge. These companies left on the outside looking in have been forced to scramble to find answers for their hundreds of thousands of customers and to find ways to protect them from this massive threat. Executives from these “Tier 2” vendors began informally contacting one another when the news of the threats broke on Wednesday.

Much like the children’s book Swimmy by Leo Lionni, the companies realized by banding together they could behave like a much bigger fish.

“Then suddenly he said, “I have it!” “We are going to swim all together like the biggest fish in the sea!” ~ Leo Lionni, Swimmy

According to information provided by the companies, the contact began when Edouard Bonlieu, VP for marketing strategy at French hosting provider Scaleway, reached out to Packet CEO, Zac Smith about an information sharing arrangement. Bonlieu had already contacted fellow French provider OVH.

Eventually six cloud providers — Scaleway, DigitalOcean, Packet, Vultur, Linode and OVH — formed a consortium of sorts to help one another and share information. In order to make the process more efficient, they started a Slack channel with CEOs, CTOs and engineers from the various companies sharing information and fixes as they became available.

This approach has allowed them to get information much more quickly, taking advantage of modern enterprise communications tools like Slack. “Not being part of the select group that received advance notice of Meltdown and Spectre, we’ve been playing catch up. Banding together with the folks at Scaleway, OVH and others has allowed us to short circuit a painfully slow game of telephone and provide our customers with as much detail as possible as they try to understand where and how their systems may be vulnerable,” Nathan Goulding, Packet’s SVP of engineering explained.

Yann Léger, SVP at Scaleway added, “We discovered these vulnerabilities in the press before the full disclosure and started to put pressure on manufacturers as fast as we could to fully understand the situation. Working with other cloud players is one of the best decisions we’ve made so far to mitigate the issue in the most accurate way,” he said.

The companies also sent out tweets and wrote blog posts to keep their customers updated with the latest information they had.

This was a case where cloud companies that normally compete hard with one another had to work together for the good of all in the true spirit of cloud computing cooperation. The large vendors have a direct pipeline to the various parties providing patches, fixes and detailed information. The Tier 2 vendors didn’t have that luxury and this level of cooperation appears to be helping them cope with an extremely difficult situation."

meltdown-spectre TechCrunch coverage

VMware Security Advisory VMSA-2018-0002 – Meltdown and Spectre Vulnerabilities
January 4, 2018 Constantin Ghioc VMware
https://cloudhat.eu/vmware-security-advisory-vmsa-2018-0002-meltdown-specter-vulnerabilities/

Spoiler: Details...

Google Project Zero released yesterday information about two vulnerabilities with impact to major processors vendors: Meltdown (CVE-2017-5754 – rogue data cache load) and Spectre (CVE-2017-5753 – bounds check bypass & CVE-2017-5715 – branch target injection). Among other organizations, VMware released a security advisory: VMSA-2018-0002 – VMware ESXi, Workstation and Fusion updates address side-channel analysis due to speculative execution.

Meltdown and Spectre Overview
Meltdown breaks the isolation between user applications and the operating system, and allows an application to access all system memory (this includes kernel allocated memory). Meltdown affects a range of Intel processors.

Spectre breaks the memory isolation between different applications, and allows an application to force another application to access arbitrary portions of its memory. Spectre affects a wide range of processors: Intel, AMD, and ARM.

“Both of these vulnerabilities are hardware level vulnerabilities that exist because of a flaw in CPU architecture. They are very serious vulnerabilities because they are operating system and software independent. The long term fix for both of these issues will require that CPU makers change the way their chips work, which means redesigning and releasing new chips.” – Defiant

You can find more information on both vulnerabilities on spectreattack.com. For comprehensive technical details, you can refer to these academic papers: Meltdown and Spectre.

VMSA-2018-0002 – ESXi, Workstation, Fusion
VMware released security advisory VMSA-2018-0002 in regards to Meltdown and Spectre vulnerabilities. The advisory only talks about Spectre, as per another blog article VMware products are not vulnerable to Meltdown. Result of exploitation may allow for information disclosure from one Virtual Machine to another Virtual Machine that is running on the same host. Multiple VMware products are affected:

• ESXi 5.5, 6.0, and 6.5 (install relevant patches: ESXi550-201709101-SG, ESXi600-201711101-SG, ESXi650-201712101-SG; ESXi 5.5 patch has remediation against CVE-2017-5715, but not against CVE-2017-5753)
• Workstation 12.x (update to 12.5.8)
• Fusion 8.x (update to 8.5.9)

I find it interesting that all the workloads in VMware Cloud on AWS are already protected since December 2017. Sometimes feels good to have somebody else handling the patching for you!

Other vendors
Many other vendors released security advisories, check the ones relevant to your environment:

• Intel
• AMD
• ARM
• Microsoft; Guidance for Windows Clients; Guidance for Windows Servers
• Microsoft Azure
• Amazon
• Google
• Red Hat
• SUSE
• Ubuntu
• Kaspersky
• Sophos
• Trendmicro
• Firefox

In case of Intel, there is another negative story development in the news cycle: Intel CEO is under fire for selling $39 million in stock.
...
Happy patching as this is not the greatest start for 2018

Update 1 – 5 January 2017
SANS and Rendition Infosec hosted a webinar held by Jake Williams (GSE #150, SANS analyst, SANS instructor). You can see the webinar in the below YouTube video and you can download the slide deck here.

Meltdown and Spectre - Understanding and mitigating the threats - SANS DFIR Webcast


Some other organizations published customer recommendations on Meltdown/Spectre:

• Apple
• CPanel
• Bitdefender
• Malwarebytes
• McAfee
• Xen

Update 2 – 6 January 2017
As BIOS/firmware updates are also required, here are some hardware vendors advisories:

• Dell
• Cisco
• Lenovo
• IBM
• HPE

Update 3 – 6 January 2017
Some more information is available via a William Lam’s tweet: there is a new KB52264 published by VMware stating that some appliances may be affected (more information to follow), while listing the unaffected appliances (VMware NSX for vSphere, VMware Unified Access Gateway, VMware vCenter Server 5.5, VMware vRealize Log Insight, VMware vRealize Operations, VMware vRealize Orchestrator).

“vSECR has evaluated these products and determined that under supported configurations they are not affected because there is no available path to execute arbitrary code without administrative privileges. This assumes that the underlying hypervisor(s) have been patched to remediate CVE-2017-5753, and CVE-2017-5715.” – VMware KB52264

William also mentions work-in-progress patches for ESXi 5.5 (CVE-2017-5753) and for vCenter to deliver Microcode update for Enhanced vMotion Compatibility (EVC).

https://twitter.com/lamw/status/949662333038559232?ref_src=twsrc^tfw&ref_url=https://cloudhat.eu/vmware-security-advisory-vmsa-2018-0002-meltdown-specter-vulnerabilities/

VMWare VMSA-2018-0002
VMware ESXi, Workstation and Fusion updates address side-channel analysis due to speculative execution.
https://www.vmware.com/us/security/advisories/VMSA-2018-0002.html

Home > Blogs > VMware Security & Compliance Blog
VMWare VMSA-2018-0002
Update 01/04/18: OS vendors have begun issuing patches that address CVE-2017-5753, CVE-2017-5715, and CVE-2017-5754 for their operating systems. For these patches to be fully functional in a guest OS additional ESXi and vCenter Server updates will be required. These updates are being given the highest priority. Please sign up to the Security-Announce mailing list to be alerted when these updates are available.
https://blogs.vmware.com/security/2018/01/vmsa-2018-0002.html

Meltdown and Spectre Linux Kernel Status
Linux Kernel Monkey Log JAN 6TH, 2018
Random bits from Greg Kroah-Hartman
http://www.kroah.com/log/blog/2018/01/06/meltdown-status/

"By now, everyone knows that something “big” just got announced regarding computer security. Heck, when the Daily Mail does a report on it , you know something is bad…

Spoiler: Linux Status Details...

Anyway, I’m not going to go into the details about the problems being reported, other than to point you at the wonderfully written Project Zero paper on the issues involved here. They should just give out the 2018 Pwnie award right now, it’s that amazingly good.

If you do want technical details for how we are resolving those issues in the kernel, see the always awesome lwn.net writeup for the details.

Also, here’s a good summary of lots of other postings that includes announcements from various vendors.

As for how this was all handled by the companies involved, well this could be described as a textbook example of how NOT to interact with the Linux kernel community properly. The people and companies involved know what happened, and I’m sure it will all come out eventually, but right now we need to focus on fixing the issues involved, and not pointing blame, no matter how much we want to.

What you can do right now
If your Linux systems are running a normal Linux distribution, go update your kernel. They should all have the updates in them already. And then keep updating them over the next few weeks, we are still working out lots of corner case bugs given that the testing involved here is complex given the huge variety of systems and workloads this affects. If your distro does not have kernel updates, then I strongly suggest changing distros right now.

However there are lots of systems out there that are not running “normal” Linux distributions for various reasons (rumor has it that it is way more than the “traditional” corporate distros). They rely on the LTS kernel updates, or the normal stable kernel updates, or they are in-house franken-kernels. For those people here’s the status of what is going on regarding all of this mess in the upstream kernels you can use.

Meltdown – x86
Right now, Linus’s kernel tree contains all of the fixes we currently know about to handle the Meltdown vulnerability for the x86 architecture. Go enable the CONFIG_PAGE_TABLE_ISOLATION kernel build option, and rebuild and reboot and all should be fine.

However, Linus’s tree is currently at 4.15-rc6 + some outstanding patches. 4.15-rc7 should be out tomorrow, with those outstanding patches to resolve some issues, but most people do not run a -rc kernel in a “normal” environment.

Because of this, the x86 kernel developers have done a wonderful job in their development of the page table isolation code, so much so that the backport to the latest stable kernel, 4.14, has been almost trivial for me to do. This means that the latest 4.14 release (4.14.12 at this moment in time), is what you should be running. 4.14.13 will be out in a few more days, with some additional fixes in it that are needed for some systems that have boot-time problems with 4.14.12 (it’s an obvious problem, if it does not boot, just add the patches now queued up.)

I would personally like to thank Andy Lutomirski, Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, Peter Zijlstra, Josh Poimboeuf, Juergen Gross, and Linus Torvalds for all of the work they have done in getting these fixes developed and merged upstream in a form that was so easy for me to consume to allow the stable releases to work properly. Without that effort, I don’t even want to think about what would have happened.

For the older long term stable (LTS) kernels, I have leaned heavily on the wonderful work of Hugh Dickins, Dave Hansen, Jiri Kosina and Borislav Petkov to bring the same functionality to the 4.4 and 4.9 stable kernel trees. I had also had immense help from Guenter Roeck, Kees Cook, Jamie Iles, and many others in tracking down nasty bugs and missing patches. I want to also call out David Woodhouse, Eduardo Valentin, Laura Abbott, and Rik van Riel for their help with the backporting and integration as well, their help was essential in numerous tricky places.

These LTS kernels also have the CONFIG_PAGE_TABLE_ISOLATION build option that should be enabled to get complete protection.

As this backport is very different from the mainline version that is in 4.14 and 4.15, there are different bugs happening, right now we know of some VDSO issues that are getting worked on, and some odd virtual machine setups are reporting strange errors, but those are the minority at the moment, and should not stop you from upgrading at all right now. If you do run into problems with these releases, please let us know on the stable kernel mailing list.

If you rely on any other kernel tree other than 4.4, 4.9, or 4.14 right now, and you do not have a distribution supporting you, you are out of luck. The lack of patches to resolve the Meltdown problem is so minor compared to the hundreds of other known exploits and bugs that your kernel version currently contains. You need to worry about that more than anything else at this moment, and get your systems up to date first.

Also, go yell at the people who forced you to run an obsoleted and insecure kernel version, they are the ones that need to learn that doing so is a totally reckless act.

Meltdown – ARM64
Right now the ARM64 set of patches for the Meltdown issue are not merged into Linus’s tree. They are staged and ready to be merged into 4.16-rc1 once 4.15 is released in a few weeks. Because these patches are not in a released kernel from Linus yet, I can not backport them into the stable kernel releases (hey, we have rules for a reason…)

Due to them not being in a released kernel, if you rely on ARM64 for your systems (i.e. Android), I point you at the Android Common Kernel tree All of the ARM64 fixes have been merged into the 3.18, 4.4, and 4.9 branches as of this point in time.

I would strongly recommend just tracking those branches as more fixes get added over time due to testing and things catch up with what gets merged into the upstream kernel releases over time, especially as I do not know when these patches will land in the stable and LTS kernel releases at this point in time.

For the 4.4 and 4.9 LTS kernels, odds are these patches will never get merged into them, due to the large number of prerequisite patches required. All of those prerequisite patches have been long merged and tested in the android-common kernels, so I think it is a better idea to just rely on those kernel branches instead of the LTS release for ARM systems at this point in time.

Also note, I merge all of the LTS kernel updates into those branches usually within a day or so of being released, so you should be following those branches no matter what, to ensure your ARM systems are up to date and secure.

Spectre
Now things get “interesting”…

Again, if you are running a distro kernel, you might be covered as some of the distros have merged various patches into them that they claim mitigate most of the problems here. I suggest updating and testing for yourself to see if you are worried about this attack vector

For upstream, well, the status is there is no fixes merged into any upstream tree for these types of issues yet. There are numerous patches floating around on the different mailing lists that are proposing solutions for how to resolve them, but they are under heavy development, some of the patch series do not even build or apply to any known trees, the series conflict with each other, and it’s a general mess.

This is due to the fact that the Spectre issues were the last to be addressed by the kernel developers. All of us were working on the Meltdown issue, and we had no real information on exactly what the Spectre problem was at all, and what patches were floating around were in even worse shape than what have been publicly posted.

Because of all of this, it is going to take us in the kernel community a few weeks to resolve these issues and get them merged upstream. The fixes are coming in to various subsystems all over the kernel, and will be collected and released in the stable kernel updates as they are merged, so again, you are best off just staying up to date with either your distribution’s kernel releases, or the LTS and stable kernel releases.

It’s not the best news, I know, but it’s reality. If it’s any consolation, it does not seem that any other operating system has full solutions for these issues either, the whole industry is in the same boat right now, and we just need to wait and let the developers solve the problem as quickly as they can.

The proposed solutions are not trivial, but some of them are amazingly good. The Retpolinepost from Paul Turner is an example of some of the new concepts being created to help resolve these issues. This is going to be an area of lots of research over the next years to come up with ways to mitigate the potential problems involved in hardware that wants to try to predict the future before it happens.

Other arches
Right now, I have not seen patches for any other architectures than x86 and arm64. There are rumors of patches floating around in some of the enterprise distributions for some of the other processor types, and hopefully they will surface in the weeks to come to get merged properly upstream. I have no idea when that will happen, if you are dependant on a specific architecture, I suggest asking on the arch-specific mailing list about this to get a straight answer.

Conclusion
Again, update your kernels, don’t delay, and don’t stop. The updates to resolve these problems will be continuing to come for a long period of time. Also, there are still lots of other bugs and security issues being resolved in the stable and LTS kernel releases that are totally independent of these types of issues, so keeping up to date is always a good idea.

Right now, there are a lot of very overworked, grumpy, sleepless, and just generally pissed off kernel developers working as hard as they can to resolve these issues that they themselves did not cause at all. Please be considerate of their situation right now. They need all the love and support and free supply of their favorite beverage that we can provide them to ensure that we all end up with fixed systems as soon as possible.

Posted by Greg Kroah-Hartman Jan 6th, 2018 kernel, linux

Linus Torvalds Is Not Happy About Intel's Meltdown and Spectre Mess
Tom McKay Today 6:05pm
https://gizmodo.com/linus-torvalds-is-not-happy-about-intels-meltdown-and-s-1821845198

"Famed Linux developer Linus Torvalds has some pretty harsh words for Intel on the fiasco over Meltdown and Spectre, the massive security flaws in modern processors that predominantly affect Intel products."

Spoiler

Meltdown and Spectre exploit an architectural flaw with the way processors handle speculative execution, a technique that most modern CPUs use to increase speed. Both classes of vulnerability could expose protected kernel memory, potentially allowing hackers to gain access to the inner workings of any unpatched system or penetrate security measures. The flaw can’t be fixed with a microcode update, meaning that developers for major OSes and platforms have had to devise workarounds that could seriously hurt performance.


In an email to a Linux list this week, Torvalds questioned the competence of Intel engineers and suggested that they were knowingly selling flawed products to the public. He also seemed particularly irritated that users could expect a five to 30 percent projected performance hit from the fixes.

“I think somebody inside of Intel needs to really take a long hard look at their CPU’s, and actually admit that they have issues instead of writing PR blurbs that say that everything works as designed,” Torvalds wrote. “.. and that really means that all these mitigation patches should be written with ‘not all CPU’s are crap’ in mind.”

“Or is Intel basically saying ‘we are committed to selling you **** forever and ever, and never fixing anything’?” he added. “Because if that’s the case, maybe we should start looking towards the ARM64 people more.”

“Please talk to management,” Torvalds concluded. “Because I really see exactly two possibibilities:—Intel never intends to fix anything OR—these workarounds should have a way to disable them. Which of the two is it?”

As Business Insider noted, as the person in charge of the open-source Linux kernel, Torvalds may be freer to share his opinion on Intel’s explanation for the issue than engineers working for the company’s business partners. Intel is currently being hit by a series of class action lawsuits citing the flaws and its handling of the security disclosure.

While workaround fixes for affected systems—or at the very least, those that are still supported by developers—have begun rolling out, per Wired, they’re far from an ideal solution. Meltdown patches are available for Microsoft, Apple, Google and Linux systems, though Spectre is a far more difficult to resolve vulnerability and it may in fact be impossible to guard against it entirely without replacing hardware. While consumer systems are impacted, enterprise systems like cloud service providers may suffer the biggest performance hits, take the longest to patch, and are the likeliest targets of any malware targeting the exploits.

“One of the most confusing parts of this whole thing is that there are two vulnerabilities that affect similar things, so it’s been challenging just to keep the two separate,” TrustedSec security researcher Alex Hamerstone told Wired. “But it’s important to patch these because of the type of deep access they give. When people are developing technology or applications they’re not even thinking about this type of access as being a possibility so it’s not something they’re working around—it just wasn’t in anybody’s mind.”

[ IT Wire/ Business Insider]

Re: Degraded performance after forced reboot due to AWS instance maintenance
https://forums.aws.amazon.com/thread.jspa?start=25&threadID=269858&tstart=0

"Jan 6, 2018 4:32 PM

Hi all,

I managed to get "expected" capacity back for my former PV c3.medium instances (that were performing at about 10% of what they used to) by stopping and launching again as c1.medium (which is more expensive though).

It did take a few stop/start tries though, and I did change the kernel also a few times, so don't expect it to work straight away. Stop -> change instance type -> start -> check performance -> repeat if not working.

I don't have any c3.large instances working at full, but I also managed to get a few m1.small:s back this way. I had one m1.small that was "spared" in the rapture so that gave me the idea that this kind of juggling might be possible.

Just thought it might help some of you that are struggling."

 

I will do this now. Also, Is O&OShutup will do the same?

 

Yes, I believe so. If you use MSMG Toolkit to physically remove all of the W10 cancer cells by force, before installing the OS, you don't need to do as much with O&O Shutup to keep things clean. Disabling Windows Update service solves the lion's share of the nonsense and keeps your system from contracting Micro$loth's digital STDs.

 

You need to warn people that going without patches for these vulnerabilities - and other security patches that emerge moving forward - by disabling Windows Update they are making themselves open to attack through those unpatched security holes.

You may not believe any of it, but hundreds of thousands of computer professionals, security researchers, Google, Amazon, Microsoft, and thousands of smaller companies are taking it seriously.

You are giving bad advice. Please at least include a warning that turning off the Windows Update service and ignoring security patches opens the user up to security holes they may run across when browsing the internet.

As I recall you also advise not running anti-virus or any browser protections, which compounds the possibility of becoming compromised.

I've alerted the Mods to your posts, please stop recommending people ignore the problem and ignore the security patches.

 

If you want me to be quiet and not tell people what I do, that just ain't gonna happen. People can make their own choices. There is more than ample doom and gloom floating around for individuals to make their own decisions about what action they think is necessary. I've never said "hey everybody, do this" that I can recall.

And, I have never said that security risks are not real. What is not real is the over-hyped chaos and ridiculous drama created by the media. Security risks are real. I happen to think that the risk is not as great as some want us to believe it is. Anyone can be in the wrong place at the wrong time, and get shot, stabbed, raped, killed by a drunk driver or hacked.

Providing straight answers when people ask questions is just one of the value-added services I provide.

 

Thanks for stating it explicitly, that the security risks are real, it would be nice to do that every time someone asks to put themselves in danger by disabling Windows Updates and not taking Microsoft Security Patches.

Most people won't read any more than the patches are making a performance hit, ranging from small to large, and want to avoid the problem instead of taking the security patches and seeing how it affects them.

For most gamers and benchmarkers, there won't be a huge hit, but even a small one is important to some, so read the Microsoft information and learn how to disable the patches while gaming / benchmarking. Right now it might take running a script and rebooting, later it might be something that is easy to disable on the fly.

Suggesting to disable Windows Update services, followed by "insane" statements of what MS is doing, isn't answering their question it's disrespecting the seriousness of the situation and spreading FUD.

"Disabling Windows Update service solves the lion's share of the nonsense and keeps your system from contracting Micro$loth's digital STDs."

If it's nonsense why do you now say you believe it? Or are you just saying that you believe it for convenience sake now? Which is it? If you believe it how can you recommend disabling Windows Updates and not taking the Security patches?

Instead of telling them how to put themselves in danger (and any others reading this) by telling them how to disable Windows Update man up and let them know the seriousness of the situation, to take it seriously, and take the patches.

 

I'm well aware of the risk. But I made my decision not to install the update in my gaming only machine. I rarely use it for browsing and its set to airplane mode the whole time. The only time I switch off airplane mode is when I want to quickly grab some files or update some of the softwares (that will take 30 minutes or less) but as soon as make computer go online, windows will automatically check for updates and I don't want that. Is why I asked "How to know if I already installed the patch? And how to avoid it from installing?".

 

To be fair, windows updates have regularly had issues and crippled performance. I, too, turn off windows automatic update. The difference is that I search through and apply security patches to make sure I am covered on that part.

Microsoft has also pushed broken drivers, etc., or try replacing newer drivers with WHQL, which in part seems to be a racket.

So I agree with both of you in part, and disagree with both of you in part.

If you are an average user that does NOT know what they are doing or why, TAKE THE UPDATES! Otherwise, please fully inform yourselves of the risks and consequences of your actions. Mr. Fox holds those risks as low, others, like @hmscott and myself hold them higher. If you don't understand, err on the side of caution.

 

The hype about it is the nonsense. And, the haphazard mess Micro$loth creates by applying updates to all systems whether they need them or not is also nonsense. And, not giving end users a say in whether or not they want to put up with their crap... that's nonsense.

Terrorists are very real. I do not live in fear of them. I do not refrain from doing whatever I want to do, or doing things my own way, simply because they exist.

Exactly. I apply a few now and then as well, but I decide... not the Redmond Mafia. And, I almost always make a Macrium image prior to those selective updates in case I decide the disease is worse than the cure. Micro$loth is not a trustworth entity, just as the hackers and cybercriminals are not. They are the King of Cybercrime based on how they treat their customers peasant subjects.

 

We aren't talking about in general we are talking about this specific situation, and yes I also normally recommend leaving Windows Update off and to selectively do Windows Updates manually, but that's not what @Mr. Fox is saying:

"Disabling Windows Update service solves the lion's share of the nonsense and keeps your system from contracting Micro$loth's digital STDs."

That's not sane advice.

 

There are far more informed technical discussions, with real results, and positive actions for users and systems administrators to take than there is hype.

There are real reports of before and after hits from the patches on Windows and Linux, and real reports from Cloud Providers and VM servers.

The reality is for most of the uses of Windows laptops and desktops for gaming and benchmarking, and everyday use there isn't much of a performance hit that will be noticeable.

It's also reality that the fixes aren't all done being created and pushed out, it will take a while for companies to come around to the reality of the situation - believe they need to take immediate action - and then make it happen.

Ignoring the problem and suggesting others ignore the problem isn't going to make any of this any easy for those taking that advice. They will worry about their exposure, and fret over it until finally they patch their systems against the problems exposed.

It's wasting their time suggesting they continue to worry about it instead of backing up their systems and installing the patches as they become available.

Why prolong the process and waste more time over it all?

 

You can spin it however you wanna spin it, bubba. I even posted a screen shot before showing I have few. Here it is again. It is sane advice if you want to maintain a stable system that reacts the way you expect it to. Enabling automatic updates and hoping everything turns out OK is totally insane as far as I am concerned. I don't care who believes it or not. I've had to reinstall Windows way too many times from screwed up Windows Updates that get applied without my moderation and control. I almost never "hurry up" and apply updates. I observe what happens to those that do first in most cases. If there are no reports of adverse implications and the information about the updates seems serious enough to warrant action, then I apply them. Unfortunately, the bastards at Micro$loth no longer provide detailed information about their updates and they bundle them in cancer packs. That really sucks.

 

I already answered your questions (see included responses above), did you download and install the powershell script to see if you have the mediation in place?

Did you get the patches and their KB numbers to look them up in your Windows Update History?

That's how you can tell, or you could just run Windows Update and see if you have updates waiting. That's something to do every week or two anyway, just to stay on top of what is going on.

 

I did. Fortunately, no updates has been installed.