linux-kernel - Re: [RFC PATCH v2 1/1] platform-msi: Add platform check for subdevice irq domain

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: <20210107060916.GY31158@unreal>
Date:   Thu, 7 Jan 2021 08:09:16 +0200
From:   Leon Romanovsky <leon@...nel.org>
To:     "Tian, Kevin" <kevin.tian@...el.com>,
        Lu Baolu <baolu.lu@...ux.intel.com>
Cc:     Jason Gunthorpe <jgg@...dia.com>,
        "tglx@...utronix.de" <tglx@...utronix.de>,
        "Raj, Ashok" <ashok.raj@...el.com>,
        "Jiang, Dave" <dave.jiang@...el.com>,
        "Dey, Megha" <megha.dey@...el.com>,
        "dwmw2@...radead.org" <dwmw2@...radead.org>,
        "alex.williamson@...hat.com" <alex.williamson@...hat.com>,
        "bhelgaas@...gle.com" <bhelgaas@...gle.com>,
        "Williams, Dan J" <dan.j.williams@...el.com>,
        "dmaengine@...r.kernel.org" <dmaengine@...r.kernel.org>,
        "eric.auger@...hat.com" <eric.auger@...hat.com>,
        "Pan, Jacob jun" <jacob.jun.pan@...el.com>,
        "kvm@...r.kernel.org" <kvm@...r.kernel.org>,
        "kwankhede@...dia.com" <kwankhede@...dia.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>,
        "maz@...nel.org" <maz@...nel.org>,
        "Hossain, Mona" <mona.hossain@...el.com>,
        "netanelg@...lanox.com" <netanelg@...lanox.com>,
        "parav@...lanox.com" <parav@...lanox.com>,
        "pbonzini@...hat.com" <pbonzini@...hat.com>,
        "rafael@...nel.org" <rafael@...nel.org>,
        "Ortiz, Samuel" <samuel.ortiz@...el.com>,
        "Kumar, Sanjay K" <sanjay.k.kumar@...el.com>,
        "shahafs@...lanox.com" <shahafs@...lanox.com>,
        "Luck, Tony" <tony.luck@...el.com>,
        "vkoul@...nel.org" <vkoul@...nel.org>,
        "yan.y.zhao@...ux.intel.com" <yan.y.zhao@...ux.intel.com>,
        "Liu, Yi L" <yi.l.liu@...el.com>
Subject: Re: [RFC PATCH v2 1/1] platform-msi: Add platform check for
 subdevice irq domain

On Thu, Jan 07, 2021 at 02:04:29AM +0000, Tian, Kevin wrote:
> > From: Leon Romanovsky <leon@...nel.org>
> > Sent: Thursday, January 7, 2021 12:02 AM
> >
> > On Wed, Jan 06, 2021 at 11:23:39AM -0400, Jason Gunthorpe wrote:
> > > On Wed, Jan 06, 2021 at 12:40:17PM +0200, Leon Romanovsky wrote:
> > >
> > > > I asked what will you do when QEMU will gain needed functionality?
> > > > Will you remove QEMU from this list? If yes, how such "new" kernel will
> > > > work on old QEMU versions?
> > >
> > > The needed functionality is some VMM hypercall, so presumably new
> > > kernels that support calling this hypercall will be able to discover
> > > if the VMM hypercall exists and if so superceed this entire check.
> >
> > Let's not speculate, do we have well-known path?
> > Will such patch be taken to stable@...stros?
> >
>
> There are two functions introduced in this patch. One is to detect whether
> running on bare metal or in a virtual machine. The other is for deciding
> whether the platform supports ims. Currently the two are identical because
> ims is supported only on bare metal at current stage. In the future it will look
> like below when ims can be enabled in a VM:
>
> bool arch_support_pci_device_ims(struct pci_dev *pdev)
> {
> 	return on_bare_metal() || hypercall_irq_domain_supported();
> }
>
> The VMM vendor list is for on_bare_metal, and suppose a vendor will
> never be removed once being added to the list since the fact of running
> in a VM never changes, regardless of whether this hypervisor supports
> extra VMM hypercalls.

This is what I imagined, this list will be forever, and this worries me.

I don't know if it is true or not, but guess that at least Oracle and
Microsoft bare metal devices and VMs will have same DMI_SYS_VENDOR.

It means that this on_bare_metal() function won't work reliably in many
cases. Also being part of include/linux/msi.h, at some point of time,
this function will be picked by the users outside for the non-IMS cases.

I didn't even mention custom forks of QEMU which are prohibited to change
DMI_SYS_VENDOR and private clouds with custom solutions.

The current array makes DMI_SYS_VENDOR interface as some sort of ABI. If in the future,
the QEMU will decide to use more hipster name, for example "qEmU", this function
won't work.

I'm aware that DMI_SYS_VENDOR is used heavily in the kernel code and
various names for the same company are good example how not reliable it.

The most hilarious example is "Dell/Dell Inc./Dell Inc/Dell Computer Corporation/Dell Computer",
but other companies are not far from them.

Luckily enough, this identification is used for hardware product that
was released to the market and their name will be stable for that
specific model. It is not the case here where we need to ensure future
compatibility too (old kernel on new VM emulator).

I'm not in position to say yes or no to this patch and don't have plans to do it.
Just expressing my feeling that this solution is too hacky for my taste.

Thanks