linux-kernel - RE: [RFC PATCH] vfio/pci: add PCIe TPH to device feature ioctl

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: <BN9PR11MB5276424BAA968DF29C3D4B8F8CAA2@BN9PR11MB5276.namprd11.prod.outlook.com>
Date: Mon, 7 Apr 2025 05:22:49 +0000
From: "Tian, Kevin" <kevin.tian@...el.com>
To: Jason Gunthorpe <jgg@...pe.ca>
CC: Wathsala Wathawana Vithanage <wathsala.vithanage@....com>, Alex Williamson
	<alex.williamson@...hat.com>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>, nd <nd@....com>, Philipp Stanner
	<pstanner@...hat.com>, Yunxiang Li <Yunxiang.Li@....com>, "Dr. David Alan
 Gilbert" <linux@...blig.org>, Ankit Agrawal <ankita@...dia.com>, "open
 list:VFIO DRIVER" <kvm@...r.kernel.org>, Dhruv Tripathi
	<Dhruv.Tripathi@....com>, "Nagarahalli, Honnappa"
	<Honnappa.Nagarahalli@....com>, Jeremy Linton <Jeremy.Linton@....com>
Subject: RE: [RFC PATCH] vfio/pci: add PCIe TPH to device feature ioctl

> From: Jason Gunthorpe <jgg@...pe.ca>
> Sent: Tuesday, April 1, 2025 10:12 PM
> 
> On Wed, Mar 12, 2025 at 07:53:17AM +0000, Tian, Kevin wrote:
> 
> > Probably we should not allow device-specific mode unless the user is
> > capable of CAP_SYS_RAWIO? It allows an user to pollute caches on
> > CPUs which its processes are not affined to, hence could easily break
> > SLAs which CSPs try to achieve...
> 
> I'm not sure this is within the threat model for VFIO though..
> 
> qemu or the operator needs to deal with this by not permiting such
> HW to go into a VM.

it could be used by native app e.g. dpdk.

> 
> Really we can't block device specific mode anyhow because we can't
> even discover it on the kernel side..
> 

hmm the TPH capability reports which steering modes (no st,
irq vector, or device specific) are supported by a device. and the
mode must be selected explicitly when sw enables the capability.

so policy-wise vfio could advocate/enforce that only the interrupt
vector mode is supported for non-privileged users.