Microsoft proposes LVBS secure kernel for Linux on Hyper-V

Microsoft engineers have posted an RFC patch series to the Linux kernel list proposing Linux Virtualization-Based Security (LVBS) for Hyper-V guests: a small secure kernel running in Virtual Trust Level 1 (VTL1) beside the ordinary guest kernel in VTL0, with isolation enforced by the hypervisor.

The work, led by Thara Gopinath with contributions from Anna Trikalinou and Stanislav Kinsburskii, aims only at the foundation. VTL0 must enable VTL1, reserve memory the secure kernel cannot take from the normal allocator, load a signed ELF secure-kernel image (intended to ship inside a Unified Kernel Image so Secure Boot covers it end to end), build initial CPU context, transition the boot CPU via a vtlcall, and bring remaining CPUs into VTL1. Higher-level services such as attestation, memory protection, and VTL0 requests into VTL1 are deferred to later RFCs.

The security argument is that on a VSM-capable guest the VTL0 kernel is already launched under Secure Boot, so standing up VTL1 during early boot is no weaker than Secure Boot itself: an attacker who can subvert that path can already subvert the kernel before VTL1 exists. The EFI stub also signals Hyper-V that the OS intends to enable VTL1.

Wei Liu, reviewing the series, asked for a Hyper-V-specific prefix on the new securekernel= command-line option, pressed for closure of several open TODOs (including assumptions about the boot CPU), and raised a trust-model question: if a generic kernel advertises VSM support but no secure kernel is packaged, could malware later occupy VTL1 to hide? The series is explicitly an architecture and boot-model RFC seeking feedback before more services land.