linux-kernel - RE: [PATCH] hv: add 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] [thread-next>] [day] [month] [year] [list]

Message-ID:
 <SN6PR02MB4157CE643DEB6CE4B0AEFC00D46AA@SN6PR02MB4157.namprd02.prod.outlook.com>
Date: Tue, 10 Jun 2025 16:17:06 +0000
From: Michael Kelley <mhklinux@...look.com>
To: Arnd Bergmann <arnd@...db.de>, Roman Kisel <romank@...ux.microsoft.com>,
	Arnd Bergmann <arnd@...nel.org>
CC: Dexuan Cui <decui@...rosoft.com>, Haiyang Zhang <haiyangz@...rosoft.com>,
	"K. Y. Srinivasan" <kys@...rosoft.com>, "linux-hyperv@...r.kernel.org"
	<linux-hyperv@...r.kernel.org>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>, "nunodasneves@...ux.microsoft.com"
	<nunodasneves@...ux.microsoft.com>, Saurabh Singh Sengar
	<ssengar@...ux.microsoft.com>, Wei Liu <wei.liu@...nel.org>
Subject: RE: [PATCH] hv: add CONFIG_EFI dependency

From: Arnd Bergmann <arnd@...db.de> Sent: Tuesday, June 10, 2025 8:46 AM
> 
> On Tue, Jun 10, 2025, at 17:33, Roman Kisel wrote:
> >> Selecting SYSFB causes a link failure on arm64 kernels with EFI disabled:
> >>
> >> ld.lld-21: error: undefined symbol: screen_info
> >> >>> referenced by sysfb.c
> >> >>>               drivers/firmware/sysfb.o:(sysfb_parent_dev) in archive vmlinux.a
> >> >>> referenced by sysfb.c
> >>
> >> The problem is that sysfb works on the global 'screen_info' structure, which
> >> is provided by the firmware interface, either the generic EFI code or the
> >> x86 BIOS startup.
> >>
> >> Assuming that HV always boots Linux using UEFI, the dependency also makes
> >> logical sense, since otherwise it is impossible to boot a guest.

This problem was flagged by the kernel test robot over the weekend [1], and I
Had been thinking about the best solution.

Just curious -- do you have real builds that have CONFIG_HYPERV=y (or =m)
and CONFIG_EFI=n? I had expected that to be a somewhat nonsense config,
but maybe not.

Hyper-V supports what it calls "Generation 1" and "Generation 2" guest VMs.
Generation 1 guests boot from BIOS, while Generation 2 guests boot from UEFI. 
x86/x64 can be either generation, while ARM64 is Generation 2 only. Furthermore,
the VTL2 paravisor is supported only in Generation 2 VMs. But I'm not clear on
what dependencies on EFI the VTL2 paravisor might have, if any. Roman -- are
VTL2 paravisors built with CONFIG_EFI=n?

> >>
> >
> > Hyper-V as of recent can boot off DeviceTree with the direct kernel  boot, no UEFI
> > is required (examples would be OpenVMM and the OpenHCL paravisor on arm64).
> 
> I was aware of hyperv no longer needing ACPI, but devicetree and UEFI
> are orthogonal concepts, and I had expected that even the devicetree
> based version would still get booted using a tiny UEFI implementation
> even if the kernel doesn't need that. Do you know what type of bootloader
> is actually used in the examples you mentioned? Does the hypervisor
> just start the kernel at the native entry point without a bootloader
> in this case?

Need Roman to clarify this.

> 
> > Being no expert in Kconfig unfortunately... If another solution is possible to
> > find given the timing constraints (link errors can't wait iiuc) that would be
> > great :)
> >
> > Could something like "select EFI if SYSFB" work?
> 
> You probably mean the reverse here:
> 
>       select SYSFB if EFI && !HYPERV_VTL_MODE

Yes, this is one approach I was thinking about. However, this problem
exposed the somewhat broader topic that at least for ARM64 normal
VMs, CONFIG_HYPERV really does have a dependency on EFI, and that
dependency isn't expressed anywhere. For x86/x64, I want to run some
experiments to be sure a Generation 1 VM really will build and boot
with CONFIG_EFI=n. Then if we can do so, I'd rather add the correct
broader dependency on EFI than embedding the dependency just in
the SYSFB selection.

> 
> I think that should work, as long as the change from the 96959283a58d
> ("Drivers: hv: Always select CONFIG_SYSFB for Hyper-V guests") patch
> is not required in the cases where the guest has no bootloader.

Yes, I think this is true.

> 
> Possibly this would also work
> 
>      select SYSFB if X86 && !HYPERV_VTL_MODE
> 
> in case only the x86 host requires the sysfb hack, but arm can
> rely on PCI device probing instead.

This doesn't work. Regular ARM64 guests require the sysfb hack
as well.

> 
> Or perhaps this version
> 
> --- a/drivers/hv/Kconfig
> +++ b/drivers/hv/Kconfig
> @@ -19,6 +19,7 @@ config HYPERV_VTL_MODE
>         bool "Enable Linux to boot in VTL context"
>         depends on (X86_64 || ARM64) && HYPERV
>         depends on SMP
> +       depends on !EFI
>         default n
>         help
>           Virtual Secure Mode (VSM) is a set of hypervisor capabilities and
> 
> if the VTL mode is never used with a boot loader in the guest.
> 
>      Arnd

[1] https://lore.kernel.org/lkml/202506080820.1wmkQufc-lkp@intel.com/