'Kernel memory leaking' Intel processor design flaw forces Linux, Windows redesign

Me too and isolate extensions flag, except I use uBlock Origin. Can a I achieve a tight config to block scripts as well by default?

Edit: NM, I found it.

 

You can try your luck on the website of "Elitegroup Computer Systems"

 

WBD you are a genius (stable or not)!

I imaged, applied the two registry tweaks, rebooted and I think I may have my machine back. Lazarus has arisen from the dead.

Tested a Macrium incremental image, which had slowed to a crawl - and it appears to be back to 'normal'. Will continue to test. Haven't tried SpecuCheck yet to confirm effects.

And watch out for any BIOS update that may necessitate removal of these keys, or microcode re-enablement.

OK I may be more exposed now, but at least I won't grow old opening Firefox ...

 

Thanks for the infos, didn't know about it.
Anyway I can't find my model PCCHIPS P63G.
And, anyway I'm going to wait for a refined well worked not rushed bios fix for the next months if ever.

Thanks @mood

 

I don't think so.

This key is defined below:

To reason this out, the OS is "oblivious" to any BIOS updating or not factors. What this key does I believe is disable the Win OS noted software mitigation patches. Don't believe you want to do that. Appears all your hardware exception violations were the result of the recent BIOS upgrade and not due to the OS software mitigation upgrades. It is also highly possible with these disabled settings, any future related OS mitigations will not be installed.

 

In my case the BIOS update had no effect, but the subsequent Win CU did ...

As @Minimalist suggested: https://www.wilderssecurity.com/thr...-windows-redesign.399338/page-20#post-2731025 it may be the combination.

Either way, disabling the mitigations has returned my machine from a lead balloon to snappiness.

Will have to monitor 'future related OS mitigations' ... (Maybe re-enable prior to future CUs?).

 

There is also the issue of the other non-OS like related patches that were applied in the Jan. 3 security update and their interrelationships to the OS mitigation patches.

 

Lol. I had PCChips mobo back in the 1998 and I used it till 2004 with Pentium MMX 200 Mhz (before I got my next board Abit An7 mGuru with AMD Barton 2500+, later GB-P35-DS3 with E2180/E8400/Q9550 and now ASRock Z370 Extreme4 with i7-8700k).

 

This relatively old, well to be honest, obsolete, socket 1155 dated back from 2011. Old from computer industry pov. hehe.

 

I will take the risk for now.

... and of the 'adjustments' given in that guidance document seems to be to disable the mitigations ...

 

I can't speak with 100% certainty, so please take with a grain of salt. Only the hardware engineers and low level / kernel level software developers would know for sure.

But as I understand it through a handful of Alex Ionescu's tweets, the Windows OS patches include software mitigations and also have functionality to facilitate kernel level API specifically for the microcode to intertwine with the system. What was documented thus far showed that this particular kernel API was not there on Windows 7/8.1/10 at all prior to the January 2018 updates. Hence, when users ran SpecuCheck prior to those updates, SpecuCheck failed out with an error message since it relies upon those new kernel API calls to/from the microcode. So the Windows patch works quite differently dependent upon whether the microcode is available or not.

But realistically, I am not an engineer and therefore I am only going based on what researchers have shared in the first 24 hours or so.

Anyway, reverting the BIOS update or disabling the mitigation via those registry keys solves the WHEA event errors and solves the massive performance degradation on some systems. This seems to only affect a certain subset of systems though, whether that be specific to CPU/motherboard combinations or specific to certain manufacturers' BIOS updates, that is not clear as of yet.

EDIT: I should have noted also that, after applying the registry keys to disable hardware mitigation and rebooting, SpecuCheck shows correctly that microcode is disabled by policy. Upon removing those keys and rebooting again, the WHEA errors and significant performance degradation come back immediately and SpecuCheck shows microcode to be enabled.

So while Microsoft suggests this is a Windows Server only registry policy, it does work on home systems as well. Well, at least on my Windows 10 Pro anyway. I can't confirm if it works on Home edition or not.

 

Here too.

I see the same enable / disable fix here: https://support.microsoft.com/en-us...ive-execution-side-channel-vulnerabilities-in

 

In regards to the NVidia ver. 390 Meltdown and Spectre "mitigation" driver updates, I applied them yesterday. Later I read about them causing assorted issues like blue screens and other problems. Then someone posted that the drivers in reality have nothing to due with security mitigations but are rather "tweaks" to enhance graphics performance for gamers to offset the effects of the Win OS mitigations.

Anyway, all was OK till first cold boot this morning. Win 10 1709 dreaded "Start Menu" issue appeared for the first time ever along with other assorted issues such as mouse right click button not functioning on desktop taskbar icons. Rebooting seems so far to have corrected the issue. Event logs indicated a conflict at initial boot time with Paint 3D initialization of all things.

 

I search in The mobile List My Celeron N3060 And There isn t (CPU of My Asus F402S) so is Not vulnerable? noscript is Good To Block javas script on Firefox ? Is The malicious script is on a trusted site noscript Block It?

 

Can anyone verify if my CPU is affected or not. I can't find it on any of the lists. Intel Core i7-6770HQ Skylake. I see these ones

Code:

Intel Core i7-6700K
Intel Core i7-6700
Intel Core i7-6700T
Intel Core i7-6700TE

 

This is interesting. May I ask--did you remove this driver and go back to a previous version? Haven't messed with Nvidia yet, it's not high on the priority list right now.

 

Like I posted previously, it appears the web site is posting vulnerable CPU's based on age with the most recent ones shown. If you look at dates shown, I believe it stops at 2010 or 2011.

If your CPU was manufactured 2010 or thereafter and it is not shown, then its probably safe to assume its not vulnerable. If it was manufactured prior to that, you can't assume anything at this point.

 

No, they are still installed and presently not having any issues. If they come back, I will just rollback to the MS issued ver. 388 drivers.

 

On this page: 5

 

I would assume anything in the Intel Core i7-6770 series would be vulnerable.

 

OK, very good. Thank you for this info,

 

@itman

You can take a look at this hypothesis:

https://www.wilderssecurity.com/thr...-windows-redesign.399338/page-19#post-2730886

It would be too simple ....

 

As an AMD CPU user, I have no intention of applying any BIOS update even if one was offered:

https://www.networkworld.com/articl...spectre-how-much-are-arm-and-amd-exposed.html

Also worth a read:

Meltdown and Spectre exploits: Cutting through the FUD

https://www.networkworld.com/articl...loits-cutting-through-the-fud.html#tk.nww-fsb