Hyper-V UEFI bootloader complexities

[…]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).[…]



Microsoft seeks Senior UEFI Engineer

The Surface Team focuses on building devices that fully express the Windows vision. Be part of the team that brings to life experiences in Microsoft Windows and Office through the hardware of its Microsoft Surface product line.   Our team develops the UEFI and firmware that connects the operating system to the hardware. Candidate will be a member of the Surface SW/FW team and be responsible for developing, adapting and fixing code related to UEFI. As a member of the team, candidate will actively participate on development practices such as task planning/sizing and scheduling, bug triage and bug management.   Candidate will actively participate in SCRUM meetings, documenting progress and updating tasks. Candidates are expected to collaborate and familiarize with other functions within the team in order to develop BIOS code that adapts the HW to platform requirements. […]




UEFI VBS required by Microsoft


“VBS will enable No-Execute (NX) protection on UEFI runtime service code and data memory regions. UEFI runtime service code must support read-only page protections, and UEFI runtime service data must not be executable.”

I’m glad Alex is reading these Microsoft updates better than I am. 🙂 Glad to know that VBS is not VBScript.





Microsoft updates Secure Boot and ACPI requirements

These Microsoft pages have recently (last month) been updated. No changelog, so unclear what has changed. 😦







OSR on debugging bad Windows drivers

OSR has a nice blog post that shows how to debug bad drivers. OSR is a smart group of Windows-centric driver consultants, check out their NT Insider newsletter if you’re into NT. And their NTdev mailing list.

[…]The bugcheck makes much more sense now. Someone’s stack expansion callback was called at DISPATCH_LEVEL (Arg2 == 2) and returned at PASSIVE_LEVEL (Arg1 == 0). That’s against the rules, thus you get a system crash. Personally I would call this a bug in KeExpandKernelStackAndCalloutEx seeing as how it is generating an IRQL_UNEXPECTED_VALUE using invalid (unexpected?) arguments. At a minimum the documentation is currently wrong though and I have filed a bug to try to get that addressed.






Hmm, it looks like OSRonline.com is becoming ‘legacy’. If there’s not a future home for some of the tools listed there, you might want to grab a set of tools while you still can. The tools are somewhat like SysInternals-style of tools.



SysInternals updated




Microsoft Surface Enterprise Management Mode (SEMM)

Quoting the Ars Technica story:

[…]To further increase the appeal of the Surface in constrained enterprise environments, today Microsoft is announcing Surface Enterprise Management Mode (SEMM) for Surface Pro 4, Surface Book, and Surface Studio. SEMM enables administrators with physical access to the hardware to lock out integrated peripherals such as webcam, microphone, and USB ports. This locking out is done by the firmware, disabling the devices in question, rendering them wholly inaccessible to the operating system. It’s intended as a much more elegant alternative to supergluing the ports or drilling out the cameras. SEMM is designed to allow not just static configuration, wherein the devices are disabled permanently, but also dynamic configuration that responds to the environment. For example, a SEMM system could be configured so that when it was on a classified network the USB ports and camera were disabled, but when on an open network they were re-enabled. The system uses digital signatures and certificates to manage the configurations, preventing end users from re-enabling devices that they shouldn’t have access to.[…]