linux-kernel - Re: [PATCH v2 1/1] Drivers: hv: Always select CONFIG

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <aDCk6haZF4fjRHf4@liuwe-devbox-ubuntu-v2.tail21d00.ts.net>
Date: Fri, 23 May 2025 16:40:10 +0000
From: Wei Liu <wei.liu@...nel.org>
To: mhklinux@...look.com
Cc: kys@...rosoft.com, haiyangz@...rosoft.com, wei.liu@...nel.org,
	decui@...rosoft.com, deller@....de, javierm@...hat.com,
	arnd@...db.de, linux-kernel@...r.kernel.org,
	linux-hyperv@...r.kernel.org, stable@...r.kernel.org
Subject: Re: [PATCH v2 1/1] Drivers: hv: Always select CONFIG_SYSFB for
 Hyper-V guests

On Mon, May 19, 2025 at 09:01:43PM -0700, mhkelley58@...il.com wrote:
> From: Michael Kelley <mhklinux@...look.com>
> 
> The Hyper-V host provides guest VMs with a range of MMIO addresses
> that guest VMBus drivers can use. The VMBus driver in Linux manages
> that MMIO space, and allocates portions to drivers upon request. As
> part of managing that MMIO space in a Generation 2 VM, the VMBus
> driver must reserve the portion of the MMIO space that Hyper-V has
> designated for the synthetic frame buffer, and not allocate this
> space to VMBus drivers other than graphics framebuffer drivers. The
> synthetic frame buffer MMIO area is described by the screen_info data
> structure that is passed to the Linux kernel at boot time, so the
> VMBus driver must access screen_info for Generation 2 VMs. (In
> Generation 1 VMs, the framebuffer MMIO space is communicated to
> the guest via a PCI pseudo-device, and access to screen_info is
> not needed.)
> 
> In commit a07b50d80ab6 ("hyperv: avoid dependency on screen_info")
> the VMBus driver's access to screen_info is restricted to when
> CONFIG_SYSFB is enabled. CONFIG_SYSFB is typically enabled in kernels
> built for Hyper-V by virtue of having at least one of CONFIG_FB_EFI,
> CONFIG_FB_VESA, or CONFIG_SYSFB_SIMPLEFB enabled, so the restriction
> doesn't usually affect anything. But it's valid to have none of these
> enabled, in which case CONFIG_SYSFB is not enabled, and the VMBus driver
> is unable to properly reserve the framebuffer MMIO space for graphics
> framebuffer drivers. The framebuffer MMIO space may be assigned to
> some other VMBus driver, with undefined results. As an example, if
> a VM is using a PCI pass-thru NVMe controller to host the OS disk,
> the PCI NVMe controller is probed before any graphics devices, and the
> NVMe controller is assigned a portion of the framebuffer MMIO space.
> Hyper-V reports an error to Linux during the probe, and the OS disk
> fails to get setup. Then Linux fails to boot in the VM.
> 
> Fix this by having CONFIG_HYPERV always select SYSFB. Then the
> VMBus driver in a Gen 2 VM can always reserve the MMIO space for the
> graphics framebuffer driver, and prevent the undefined behavior. But
> don't select SYSFB when building for HYPERV_VTL_MODE as VTLs other
> than VTL 0 don't have a framebuffer and aren't subject to the issue.
> Adding SYSFB in such cases is harmless, but would increase the image
> size for no purpose.
> 
> Fixes: a07b50d80ab6 ("hyperv: avoid dependency on screen_info")
> Signed-off-by: Michael Kelley <mhklinux@...look.com>
> Reviewed-by: Saurabh Sengar <ssengar@...ux.microsoft.com>

Applied.