I agree with all of the above but! There have been some big gotchas slipping threw the cracks. Like I said earlier, how is it they don't show up in the insider builds but crop up at the last moment when a consumer build is released? They were patching the last insider build days before it became the consumer build. And more patches right after it was released? Isn't the whole point of insider builds so the kinks get worked out before it hits consumer PC's? What part of the puzzle am I missing?
Put all the new features you want in the insider builds, but at some point you have to draw a line in the sand and stop adding stuff. Then fix what ever is broken. And don't wait until the day before releasing it to the consumer side to do it. IMHO the AU was not ready for prim time.
If you recall the last few months before the AU came out no new features were added and the only thing that was being done was bug repairs.
Kernel-mode rootkits run with the highest operating system privileges (Ring 0) by adding code or replacing portions of the core operating system, including both the kernel and associated device drivers. Most operating systems support kernel-mode device drivers, which execute with the same privileges as the operating system itself. As such, many kernel-mode rootkits are developed as device drivers or loadable modules, such as loadable kernel modules in Linux or device drivers in Microsoft Windows. This class of rootkit has unrestricted security access, but is more difficult to write. The complexity makes bugs common, and any bugs in code operating at the kernel level may seriously impact system stability, leading to discovery of the rootkit. One of the first widely known kernel rootkits was developed for Windows NT 4.0 and released in Phrack magazine in 1999 by Greg Hoglund. Kernel rootkits can be especially difficult to detect and remove because they operate at the same security level as the operating system itself, and are thus able to intercept or subvert the most trusted operating system operations. Any software, such as antivirus software, running on the compromised system is equally vulnerable. In this situation, no part of the system can be trusted.
A rootkit can modify data structures in the Windows kernel using a method known as direct kernel object manipulation (DKOM). This method can be used to hide processes. A kernel mode rootkit can also hook the System Service Descriptor Table (SSDT), or modify the gates between user mode and kernel mode, in order to cloak itself. Similarly for the Linux operating system, a rootkit can modify the system call table to subvert kernel functionality. It's common that a rootkit creates a hidden, encrypted filesystem in which it can hide other malware or original copies of files it has infected. Operating systems are evolving to counter the threat of kernel-mode rootkits. For example, 64-bit editions of Microsoft Windows now implement mandatory signing of all kernel-level drivers in order to make it more difficult for untrusted code to execute with the highest privileges in a system.
Rootkit - Wikipedia, the free encyclopedia
Driver Signing changes in Windows 10 Windows Hardware Certification blogNOTE: These driver signing changes correspond to the initial Windows 10 release. For driver signing changes in Windows 10, version 1607, see this post.Beginning with the release of Windows 10, all new Windows 10 kernel mode drivers must be submitted to and digitally signed by the Windows Hardware Developer Center Dashboard portal. Windows 10 will not load new kernel mode drivers which are not signed by the portal.
Additionally, starting 90 days after the release of Windows 10, the portal will only accept driver submissions, including both kernel and user mode driver submissions, that have a valid Extended Validation (“EV”) Code Signing Certificate.
We’re making these changes to help make Windows more secure. These changes limit the risk of a driver publisher’s signing keys being lost or stolen and also ensures that driver publishers are strongly authenticated.
If you are a driver developer, here is what you need to do:
- Ensure that you submit new drivers to Microsoft via the Windows Hardware Developer Center Dashboard portal.
- Get started with the process of getting an EV Code Signing Certificate.
What about existing drivers? Do I need to re-sign these drivers to get them to work with Windows 10?
No, existing drivers do not need to be re-signed. To ensure backwards compatibility, drivers which are properly
Driver Signing changes in Windows 10, version 1607 Windows Hardware Certification blogFAQs
What are the exact exceptions? Are cross-signed drivers still valid?
Enforcement only happens on fresh installations, with Secure Boot on, and only applies to new kernel mode drivers:
- PCs upgrading from a release of Windows prior to Windows 10 Version 1607 will still permit installation of cross-signed drivers.
- PCs with Secure Boot OFF will still permit installation of cross-signed drivers.
- Drivers signed with an end-entity certificate issued prior to July 29th, 2015 that chains to a supported cross-signed CA will continue to be allowed.
- To prevent systems from failing to boot properly, boot drivers will not be blocked, but they will be removed by the Program Compatibility Assistant. Future versions of Windows will block boot drivers.
To summarize, on non-upgraded fresh installations of Windows 10, version 1607 with Secure Boot ON, drivers must be signed by Microsoft or with an end-entity certificate issued prior to July 29th, 2015 that chains to a supported cross-signed CA.
What about existing drivers? Do I need to re-sign these drivers to get them to work with Windows 10, version 1607?
No. Existing drivers do not need to be re-signed. To ensure backwards compatibility, drivers which are properly signed by a valid cross-signing certificate issued prior to July 29th, 2015 will continue to pass signing checks on Windows 10, version 1607.
What about older versions of Windows?
The changes described in this post apply only to Windows 10, version 1607. Please note that the Windows Hardware Developer Center Dashboard portal will require all new submissions be signed with an EV Code Signing Certificate no matter what OS you plan to support with your driver package.
How do I sign drivers during development and testing?
Please see the Signing Drivers during Development and Test topic on MSDN for information on how to test sign. In addition, if Secure Boot is set to OFF, then drivers signed with existing cross-signed certificates will continue to be valid.
How do I sign a driver so that it is compatible with Windows Vista, Windows 7, Windows 8, Windows 8.1, and Windows 10?
All you need to do is run the HLK tests for Windows 10 and run the HCK tests for Windows 8.1 and earlier versions as you have in the past. Then, using the Windows 10 HLK, merge the two test logs and submit your driver along with the merged HLK/HCK test results to the Windows Hardware Developer Center Dashboard portal. The portal will sign the driver correctly such that it will work on all platforms that you indicate.
What about Extended Validation Certificate Dev Portal package signing?
The portal currently requires all driver submitters to have a valid EV Code Signing Certificate registered to their account. Windows itself does not have any special requirements for drivers to be signed by EV certificates.