If you are curious about the details behind the registry key that your Antivirus program needs to create in order to receive Windows Updates, The Register describes its purpose here. In essence, modern AV programs regularly access the kernel to look for suspicious activity and become quite upset when they are not allowed to access it after the patch places the kernel in isolation, upset enough to continually crash your computer. Ensuring your AV software has updated itself to ensure that this does not occur before allowed the Windows patch to install is a good thing, however there is a serious problem with the way Microsoft decided to deal with the situation. Until that key is present, you will not be able to install any new security patches; something which should be changed ASAP as it could help spread other infections simply because you had the temerity not to use Windows Defender.
"Microsoft's workaround to protect Windows computers from the Intel processor security flaw dubbed Meltdown has revealed the rootkit-like nature of modern security tools."
Here is some more Tech News from around the web:
- Spectre and Meltdown not a concern for mobile says Qualcomm @ Electronics Weekly
- Meltdown and Spectre Patches Bricking Ubuntu 16.04 Computers @ Slashdot
This is a much watch video
This is a much watch video about how a CPU design(x86 design) is made and verified and tested! Some good links are provided for sources of for kernel developers/linux and others, He talke about “Chicken Bits” built-in the CPU’s hardware JTAG testing and patching. Verilog, microcode etc.
“[Video] David Kaplan: When hardware must just work“
Well the AV makers had no
Well the AV makers had no busines making calls to undocumented Kernel Hooks to enable the AV’s/Firewall’s functionality. Undocumented Kernel Hooks are not guaranteed to be around like the offical documented OS Kernel hooks that are there to allow third party software to monitor things and set up other firewall/protection or debugging fucnctionality.
It’s best not to even try and directly address any documented object/functionality inside any API outside of the proper and approved API/Object method calls that are there to supply data access(Via public Function Calls) to the needed Kernel/IO/Network states. Trying to directly address any Object’s private data and private functionality, or even public methods, via any direct addressing methods outside of the supplied and official Object’s/APIs Public Methods Interface can result in Blue Screens and other such bad day sorts of things. Any of the insides of any code/data objects defined in any API(OS or otherwise) is/are not guaranteed to be sucessful if the API/Assemblies/OS undergoes any changes under the hood for the relevent Objects/Object Methods(Function Calls).
So every Object/Structure defined in every API has a list of Public Method calls/interfaces that are symbol based and either defined at compile time for .exe or runtime dynamic load .DLL and only the standard interface is guaranteed to remain cosntant and backwards compatable, with the actual functions defined in the Opject/Object’s Name Space/bounds moved around and changed to account for newer features, security, or other such changes.
Kernel Functionality especially needs to be accessed via the API’s/Objects’s public method calls defined in the object’s publicly Documented Function Prototypes and public Interface Methods. So any of those back door methods are not guaranteed to be safe to do EVER!
Here is the title(1) of the Register article that you linked to and really journalistically you need to inclde the Title of the article that you linked to Before or as the Hyper-link and not some part of your articel’s text. That Title speaks of what the AV folks did wrong and it’s always going to cause problems and the AV/Security software folks are to blame mostly for some BSODs caused by their software teams not following the proper methods to get things done.
“CPU bug patch saga: Antivirus tools caught with their hands in the Windows cookie jar”
See Above PCPer article for the link.
simply because you were
Fixed that for you. Third-party AV products have long been superfluous for most people, and often introduce vulnerabilities to systems they claim to protect.
You’re seriously going to
You’re seriously going to trust the people that were unable to write the program correctly in the first place to write the antimalware correctly to detect and block the attack against the hole they’re not competent to fix (or they would fix it instead) and often don’t know about (zero day) anyway?
Yeah, get back to us when Microsoft gets in trouble for detecting experimental malware that escaped a government lab.
And right on time, here’s a
And right on time, here’s a new batch of remote code execution vulnerabilities reported in Microsoft products, including this one:
Title: Microsoft Malware Protection Engine Remote Code Execution Vulnerability