linux-kernel - RE: vPASID capability for VF

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: <BN9PR11MB52765638CD15BBDC762100EB8C779@BN9PR11MB5276.namprd11.prod.outlook.com>
Date:   Wed, 10 May 2023 02:16:05 +0000
From:   "Tian, Kevin" <kevin.tian@...el.com>
To:     Jason Gunthorpe <jgg@...dia.com>,
        Alex Williamson <alex.williamson@...hat.com>
CC:     "kvm@...r.kernel.org" <kvm@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "Liu, Yi L" <yi.l.liu@...el.com>,
        Nicolin Chen <nicolinc@...dia.com>,
        "Lu, Baolu" <baolu.lu@...el.com>
Subject: RE: vPASID capability for VF

> From: Jason Gunthorpe <jgg@...dia.com>
> Sent: Wednesday, May 10, 2023 8:59 AM
> 
> On Tue, May 09, 2023 at 06:31:11PM -0600, Alex Williamson wrote:
> 
> > IIRC we originally needed to enable this for a Broadcom NIC that
> > stuffed device specific registers in un-architected config space. The
> > capabilities we're {un}hiding are architected things that we know are
> > unsupported or unsafe, the gaps, just like device specific
> > capabilities, we're obliged to expose for functionality.  Thanks,
> 
> I still think that if people want to do this they should wrap their
> stuff in a dvsec..
> 
> If we have no choice but to inject a PASID cap for this to work then I
> don't think we should quirk every device, but punish those that don't
> use DVSEC/etc
> 
> So.. If PASID injection is needed then block the unmanaged space and
> add quirks for devices that really need it. Otherwise leave it
> alone.
> 

We don't have a control knob to hide/unhide a specific PCI cap
today. It's hardcoded with proper virtualization policy in vfio-pci.

Following current convention once vfio-pci adds the support for the
PASID cap it will be exposed if present (for VF it's the presence in PF).

So I wonder how "if PASID injection is needed" can be decided.

If we pick the policy of default blocking the unmanaged space when
the PASID cap is exposed I'm not sure whether it will break any
existing device which already has the PASID cap and hidden registers
in the unmanaged space and can be assigned successfully today. That
legacy usage just doesn't need the PASID cap.

That uncertainty leans me toward quirking every device to use PASID,
though I dislike it.