After spending the better part of a weekend writing a specialized Windows driver for the purposes of allowing me to communicate with the Hyper-V hypervisor, as well as the Secure Kernel, from user-mode, I realized that there was a dearth of concise technical content on non-PnP driver development, and especially on how the Windows Driver Foundation (WDF) fundamentally changes how such drivers can be developed. While I’ll eventually release my full tool, once better polished, on GitHub, I figured I’d share some of the steps I took in getting there. Unlike my more usual low-level super-technical posts, this one is meant more as an introduction and tutorial, so if you already consider yourself experienced in WDF driver development, feel free to wait for Part 2.
The HDK is an updated version of the HvGdk.h header file published under MSR-LA as part of the Singularity Research Kernel. It has been updated to add the latest definitions, structures and definitions as described in the Microsoft Hypervisor Top-Level Functional Specification (TLFS) 5.0c published June 2018.
Setting Up Network Debugging of a Virtual Machine – KDNET
This topic describes how to configure a kernel debugging connection to a Hyper-V virtual machine (VM).[…]
Announcing the Windows Bounty Program:
Windows 10 represents the best and newest in our strong commitment to security with world-class mitigations. One of Microsoft’s longstanding strategies toward improving software security involves investing in defensive technologies that make it difficult and costly for attackers to find, exploit and leverage vulnerabilities. We built in mitigations and defenses such as DEP, ASLR, CFG, CIG, ACG, Device Guard, and Credential Guard to harden our systems and we continue adding defenses such as Windows Defender Application Guard to significantly increase protection to harden entry points while ensuring the customer experience is seamless. In the spirit of maintaining a high security bar in Windows, we’re launching the Windows Bounty Program on July 26, 2017. This will include all features of the Windows Insider Preview in addition to focus areas in Hyper-V, Mitigation bypass, Windows Defender Application Guard, and Microsoft Edge. We’re also bumping up the pay-out range for the Hyper-V Bounty Program.[…]
[…]Forcing GRUB installation to EFI removable media path does basically the same thing as when Ubuntu installer asks you if you want to force UEFI installation: it installs to the removable media path in the ESP (EFI System Partition). This is fine for environment where no other operating system is present. However if there is another operating system present on the device which depends on this fallback location “removable media path” it will make this system temporary unbootable (you can manually configure GRUB later to boot it if necessary though). Windows installer for example *also* installs to the removable media path in the ESP. All OS installers installing things to this removable media path will conflict with any other such installers and that’s why in Debian (and Ubuntu) installers don’t do this by default. You explicitly have to select UEFI mode during the normal installation (what I did).[…]
Adolfo V Aguayo of Intel announced the version 2.2 release of OpenCIT.
New Features in 2.2:
– TPM 2.0 support.
+ Added support for platform and asset tag attestation of Linux and Windows hosts with TPM 2.0.
+ Support attestation of either SHA1 or SHA256 PCR banks on TPM 2.0.
+ Ubuntu 16.04 and RHEL 7.2, 7.3 (SHA1 and SHA256), Windows Server 2012 and Hyper-V Server 2012 (SHA1) are supported with TPM 2.0
– All the certificates and hashing algorithms used in CIT are upgraded to use SHA256. SHA1 has been deprecated and will no longer be used.
– CIT Attestation Service UI has been updated to allow the user to select either the SHA1 or SHA256 PCR bank for Attestation of TPM 2.0 hosts.
+ The CIT Attestation Service will automatically choose the strongest available algorithm for attestation (SHA1 for TPM 1.2, and SHA256 for TPM 2.0)
– CIT Attestation Service UI Whitelist tab no longer requires the user to select PCRs when whitelisting, and will automatically choose the PCRs to use based on the host OS and TPM version. This is done to reduce confusion due to differing behaviors between TPM 1.2 and TPM 2.0 PCR usages.
– Additional changes made to support TPM 2.0:
+ Linux hosts with TPM 2.0 will now utilize TPM2.0-TSS (TPM 2.0 Software Stack) and TPM2.0-tools instead of the legacy trousers and tpm-tools packages. The new TSS2 and TPM2.0-tools are packaged with the CIT Trust Agent installer.
+ TPM 2.0 Windows hosts use TSS.MSR (The TPM Software Stack from Microsoft Research) PCPTool.
+ TPM 1.2 hosts will continue to use the legacy TSS stack (trousers) and tpm-tools components.
For more information, see the full announcement on the firstname.lastname@example.org mailing list.
The CHIPSEC team have tweeted about an upcoming 1.2.3 release with more Xen, Hyper-V, IOMMU, EPT support.
Also, Yuriy Bulygin of the Intel CHIPSEC team has posted some videos of their REcon training showing CHIPSEC usage:
Kostya Kortchinsky pointed out some Hyper-V bugs recently fixed in Chromium, all 3 are listed as being fixed 4 days ago.
Hyper-V vmswitch.sys VmsMpCommonPvtHandleMulticastOids Guest to Host Kernel-Pool Overflow
Hyper-V vmswitch.sys VmsVmNicHandleRssParametersChange OOBR Guest to Host BugChecks
Hyper-V vmswitch.sys VmsPtpIpsecTranslateAddv2toAddv2Ex OOBR Guest to Host BugCheck
Gerhart X has done some research on Microsoft Hyper-V:
Nice document, lots of figures and information, apparently from a translation!