MalwareTips Bot

Content Creator
Microsoft continues to work diligently with our industry partners to address the Spectre and Meltdown hardware-based vulnerabilities. Our top priority is clear: Help protect the safety and security of our customers’ devices and data. Today, I’d like to provide an update on some of that work, including Windows security update availability for additional devices, our role in helping distribute available Intel firmware (microcode), and progress driving anti-virus compatibility.

Additional steps being taken to address Spectre and Meltdown vulnerabilities

Windows devices need both software and firmware updates to help protect them against these new vulnerabilities. Recently we added software coverage for x86 editions of Windows 10, and we continue to work to provide updates for other supported versions of Windows. You can find more information and a table of updated Windows editions in our Windows customer guidance article. We will update this documentation when new mitigations become available.

While firmware (microcode) security updates are not yet broadly available, Intel recently announced that they have completed their validations and started to release microcode for newer CPU platforms. Today, Microsoft will make available Intel microcode updates, initially for some Skylake devices running the most broadly installed version of Windows 10 — the Windows 10 Fall Creators Update — through the Microsoft Update Catalog, KB4090007. We will offer additional microcode updates from Intel as they become available to Microsoft. We will continue to work with chipset and device makers as they offer more vulnerability mitigations.1

For commercial customers, Terry Myerson announced February 13 that Windows Analytics now helps IT professionals assess Meltdown and Spectre update status by providing device-level insights at scale.

Antivirus (AV) Software Compatibility

We have also been working closely with our anti-virus (AV) partners on compatibility with Windows updates, resulting in the vast majority of Windows devices now having compatible AV software installed. The continued focus of our work with our AV partners and customers is to manage the risk of compatibility issues, especially those that result from AV software that makes unsupported calls into Windows kernel memory. Due to this potential risk, we require that AV software is up to date and compatible. We will continue to require that an AV compatibility check is made before delivering the latest Windows security updates via Windows Update until we have a sufficient level of AV software compatibility. We recommend users check with their AV provider on compatibility of their installed AV software products.

Staying up to date

We continue to work with industry partners on further mitigations and tools to help protect against the Spectre and Meltdown vulnerabilities. As always, we emphasize the importance of keeping your devices up to date for both Windows security and feature updates. Windows 10 version 1709, the Fall Creators Update, is the most secure version of Windows and is fully available for all devices.

1 Customers should check with their CPU (chipset) and device manufacturers on availability of applicable firmware security updates for their specific device, including Intel’s Microcode Revision Guidance.


Deleted member 65228

In all fairness, there shouldn't be too much of a difference post the recent Windows Updates for Anti-Virus compatibility. The system call stubs in user-mode are still identical to how they were prior to recent update and kernel-mode software isn't really affected aside from patching any vulnerable code for the Spectre vulnerabilities (e.g. usage of LFENCE where it's required as one mitigation); the biggest change of the recent patches was due to Kernel Page Table Isolation (KPTI) but this is implemented within the Windows Kernel and causes system calls to land at KiSystemCallXxShadow/KiSystemCallXxAmdShadow instead, the end-result is still the correct pointer address being used (taken from the System Service Descriptor Table) and control flow execution being redirected.

I can understand it for vendors like Kaspersky which may have been emulating routines like KiSystemCallXx after performing MSR patching but not many vendors do things like this because it won't be supported on an 64-bit environment without the hyper-visor for Extended Page Table/Rapid Virtualization Indexing to prevent Kernel Patch Protection (KPP) from detecting the modification and throwing a KeBugCheckEx BSOD (which Kaspersky also do as far as I am aware).

Oh well, glad compatibility has officially improved.