linux-kernel - Re: [PATCH hyperv-next v5 03/11] Drivers: hv: Enable VTL mode for arm64

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: <119cfb59-d68b-4718-b7cb-90cba67827e8@app.fastmail.com>
Date: Mon, 10 Mar 2025 22:20:41 +0100
From: "Arnd Bergmann" <arnd@...db.de>
To: "Michael Kelley" <mhklinux@...look.com>,
 "Roman Kisel" <romank@...ux.microsoft.com>,
 "bhelgaas@...gle.com" <bhelgaas@...gle.com>,
 "Borislav Petkov" <bp@...en8.de>,
 "Catalin Marinas" <catalin.marinas@....com>,
 "Conor Dooley" <conor+dt@...nel.org>,
 "Dave Hansen" <dave.hansen@...ux.intel.com>,
 "Dexuan Cui" <decui@...rosoft.com>,
 "Haiyang Zhang" <haiyangz@...rosoft.com>,
 "H. Peter Anvin" <hpa@...or.com>, "Joey Gouly" <joey.gouly@....com>,
 "krzk+dt@...nel.org" <krzk+dt@...nel.org>,
 Krzysztof Wilczyński <kw@...ux.com>,
 "K. Y. Srinivasan" <kys@...rosoft.com>, "Len Brown" <lenb@...nel.org>,
 "Lorenzo Pieralisi" <lpieralisi@...nel.org>,
 "Manivannan Sadhasivam" <manivannan.sadhasivam@...aro.org>,
 "Mark Rutland" <mark.rutland@....com>, "Marc Zyngier" <maz@...nel.org>,
 "Ingo Molnar" <mingo@...hat.com>,
 "Oliver Upton" <oliver.upton@...ux.dev>,
 "Rafael J . Wysocki" <rafael@...nel.org>,
 "Rob Herring" <robh@...nel.org>,
 "ssengar@...ux.microsoft.com" <ssengar@...ux.microsoft.com>,
 "Sudeep Holla" <sudeep.holla@....com>,
 "Suzuki K Poulose" <suzuki.poulose@....com>,
 "Thomas Gleixner" <tglx@...utronix.de>, "Wei Liu" <wei.liu@...nel.org>,
 "Will Deacon" <will@...nel.org>, "Zenghui Yu" <yuzenghui@...wei.com>,
 "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
 "kvmarm@...ts.linux.dev" <kvmarm@...ts.linux.dev>,
 "linux-acpi@...r.kernel.org" <linux-acpi@...r.kernel.org>,
 Linux-Arch <linux-arch@...r.kernel.org>,
 "linux-arm-kernel@...ts.infradead.org"
 <linux-arm-kernel@...ts.infradead.org>,
 "linux-hyperv@...r.kernel.org" <linux-hyperv@...r.kernel.org>,
 "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
 "linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>,
 "x86@...nel.org" <x86@...nel.org>
Cc: "apais@...rosoft.com" <apais@...rosoft.com>,
 "benhill@...rosoft.com" <benhill@...rosoft.com>,
 "bperkins@...rosoft.com" <bperkins@...rosoft.com>,
 "sunilmut@...rosoft.com" <sunilmut@...rosoft.com>
Subject: Re: [PATCH hyperv-next v5 03/11] Drivers: hv: Enable VTL mode for arm64

On Mon, Mar 10, 2025, at 22:01, Michael Kelley wrote:
> From: Arnd Bergmann <arnd@...db.de> Sent: Saturday, March 8, 2025 1:05 PM
>> >  config HYPERV_VTL_MODE
>> >  	bool "Enable Linux to boot in VTL context"
>> > -	depends on X86_64 && HYPERV
>> > +	depends on (X86_64 || ARM64)
>> >  	depends on SMP
>> > +	select OF_EARLY_FLATTREE
>> > +	select OF
>> >  	default n
>> >  	help
>> 
>> Having the dependency below the top-level Kconfig entry feels a little
>> counterintuitive. You could flip that back as it was before by doing
>> 
>>       select HYPERV_VTL_MODE if !ACPI
>>       depends on ACPI || SMP
>> 
>> in the HYPERV option, leaving the dependency on HYPERV in
>> HYPERV_VTL_MODE.
>
> I would argue that we don't ever want to implicitly select
> HYPERV_VTL_MODE because of some other config setting or
> lack thereof.  VTL mode is enough of a special case that it should
> only be explicitly selected. If someone omits ACPI, then HYPERV
> should not be selectable unless HYPERV_VTL_MODE is explicitly
> selected.
>
> The last line of the comment for HYPERV_VTL_MODE says
> "A kernel built with this option must run at VTL2, and will not run
> as a normal guest."  In other words, don't choose this unless you
> 100% know that VTL2 is what you want.

It sounds like the latter is the real problem: enabling a feature
should never prevent something else from working. Can you describe
what VTL context is and why it requires an exception to a rather
fundamental rule here? If you build a kernel that runs on every
single piece of arm64 hardware and every hypervisor, why can't
you add HYPERV_VTL_MODE to that as an option?

      Arnd