| 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
| ||
|
Message-ID: <ff4c58f1-564d-ddfa-bdff-48ffee6e0d72@linux.microsoft.com> Date: Wed, 3 Sep 2025 19:16:37 -0700 From: Mukesh R <mrathor@...ux.microsoft.com> To: Michael Kelley <mhklinux@...look.com>, "dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>, "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, "linux-input@...r.kernel.org" <linux-input@...r.kernel.org>, "linux-hyperv@...r.kernel.org" <linux-hyperv@...r.kernel.org>, "netdev@...r.kernel.org" <netdev@...r.kernel.org>, "linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>, "linux-scsi@...r.kernel.org" <linux-scsi@...r.kernel.org>, "linux-fbdev@...r.kernel.org" <linux-fbdev@...r.kernel.org>, "linux-arch@...r.kernel.org" <linux-arch@...r.kernel.org>, "virtualization@...ts.linux.dev" <virtualization@...ts.linux.dev> Cc: "maarten.lankhorst@...ux.intel.com" <maarten.lankhorst@...ux.intel.com>, "mripard@...nel.org" <mripard@...nel.org>, "tzimmermann@...e.de" <tzimmermann@...e.de>, "airlied@...il.com" <airlied@...il.com>, "simona@...ll.ch" <simona@...ll.ch>, "jikos@...nel.org" <jikos@...nel.org>, "bentiss@...nel.org" <bentiss@...nel.org>, "kys@...rosoft.com" <kys@...rosoft.com>, "haiyangz@...rosoft.com" <haiyangz@...rosoft.com>, "wei.liu@...nel.org" <wei.liu@...nel.org>, "decui@...rosoft.com" <decui@...rosoft.com>, "dmitry.torokhov@...il.com" <dmitry.torokhov@...il.com>, "andrew+netdev@...n.ch" <andrew+netdev@...n.ch>, "davem@...emloft.net" <davem@...emloft.net>, "edumazet@...gle.com" <edumazet@...gle.com>, "kuba@...nel.org" <kuba@...nel.org>, "pabeni@...hat.com" <pabeni@...hat.com>, "bhelgaas@...gle.com" <bhelgaas@...gle.com>, "James.Bottomley@...senPartnership.com" <James.Bottomley@...senPartnership.com>, "martin.petersen@...cle.com" <martin.petersen@...cle.com>, "gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>, "deller@....de" <deller@....de>, "arnd@...db.de" <arnd@...db.de>, "sgarzare@...hat.com" <sgarzare@...hat.com>, "horms@...nel.org" <horms@...nel.org> Subject: Re: [PATCH V0 0/2] Fix CONFIG_HYPERV and vmbus related anamoly On 9/2/25 07:42, Michael Kelley wrote: > From: Mukesh Rathor <mrathor@...ux.microsoft.com> Sent: Wednesday, August 27, 2025 6:00 PM >> >> At present, drivers/Makefile will subst =m to =y for CONFIG_HYPERV for hv >> subdir. Also, drivers/hv/Makefile replaces =m to =y to build in >> hv_common.c that is needed for the drivers. Moreover, vmbus driver is >> built if CONFIG_HYPER is set, either loadable or builtin. >> >> This is not a good approach. CONFIG_HYPERV is really an umbrella config that >> encompasses builtin code and various other things and not a dedicated config >> option for VMBUS. Vmbus should really have a config option just like >> CONFIG_HYPERV_BALLOON etc. This small series introduces CONFIG_HYPERV_VMBUS >> to build VMBUS driver and make that distinction explicit. With that >> CONFIG_HYPERV could be changed to bool. > > Separating the core hypervisor support (CONFIG_HYPERV) from the VMBus > support (CONFIG_HYPERV_VMBUS) makes sense to me. Overall the code > is already mostly in separate source files code, though there's some > entanglement in the handling of VMBus interrupts, which could be > improved later. > > However, I have a compatibility concern. Consider this scenario: > > 1) Assume running in a Hyper-V VM with a current Linux kernel version > built with CONFIG_HYPERV=m. > 2) Grab a new version of kernel source code that contains this patch set. > 3) Run 'make olddefconfig' to create the .config file for the new kernel. > 4) Build the new kernel. This succeeds. > 5) Install and run the new kernel in the Hyper-V VM. This fails. > > The failure occurs because CONFIG_HYPERV=m is no longer legal, > so the .config file created in Step 3 has CONFIG_HYPERV=n. The > newly built kernel has no Hyper-V support and won't run in a > Hyper-V VM. > > As a second issue, if in Step 1 the current kernel was built with > CONFIG_HYPERV=y, then the .config file for the new kernel will have > CONFIG_HYPERV=y, which is better. But CONFIG_HYPERV_VMBUS > defaults to 'n', so the new kernel doesn't have any VMBus drivers > and won't run in a typical Hyper-V VM. > > The second issue could be fixed by assigning CONFIG_HYPERV_VMBUS > a default value, such as whatever CONFIG_HYPERV is set to. But > I'm not sure how to fix the first issue, except by continuing to > allow CONFIG_HYPERV=m. To certain extent, imo, users are expected to check config files for changes when moving to new versions/releases, so it would be a one time burden. CONFIG_HYPERV=m is just broken imo as one sees that in .config but magically symbols in drivers/hv are in kerenel. Thanks, -Mukesh > See additional minor comments in Patches 1 and 2. > > Michael > >> >> For now, hv_common.c is left as is to reduce conflicts for upcoming patches, >> but once merges are mostly done, that and some others should be moved to >> virt/hyperv directory. >> >> Mukesh Rathor (2): >> hyper-v: Add CONFIG_HYPERV_VMBUS option >> hyper-v: Make CONFIG_HYPERV bool >> >> drivers/Makefile | 2 +- >> drivers/gpu/drm/Kconfig | 2 +- >> drivers/hid/Kconfig | 2 +- >> drivers/hv/Kconfig | 14 ++++++++++---- >> drivers/hv/Makefile | 4 ++-- >> drivers/input/serio/Kconfig | 4 ++-- >> drivers/net/hyperv/Kconfig | 2 +- >> drivers/pci/Kconfig | 2 +- >> drivers/scsi/Kconfig | 2 +- >> drivers/uio/Kconfig | 2 +- >> drivers/video/fbdev/Kconfig | 2 +- >> include/asm-generic/mshyperv.h | 8 +++++--- >> net/vmw_vsock/Kconfig | 2 +- >> 13 files changed, 28 insertions(+), 20 deletions(-) >> >> -- >> 2.36.1.vfs.0.0 >>
Powered by blists - more mailing lists