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] [day] [month] [year] [list]
Message-ID:
 <PAWPR08MB8909ECF0B0D9DE942C71BDAD9FCB2@PAWPR08MB8909.eurprd08.prod.outlook.com>
Date: Wed, 5 Mar 2025 20:21:57 +0000
From: Wathsala Wathawana Vithanage <wathsala.vithanage@....com>
To: Jason Gunthorpe <jgg@...pe.ca>
CC: Alex Williamson <alex.williamson@...hat.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, nd
	<nd@....com>, Kevin Tian <kevin.tian@...el.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>, Honnappa Nagarahalli
	<Honnappa.Nagarahalli@....com>, Jeremy Linton <Jeremy.Linton@....com>
Subject: RE: [RFC PATCH] vfio/pci: add PCIe TPH to device feature ioctl



> -----Original Message-----
> From: Jason Gunthorpe <jgg@...pe.ca>
> Sent: Wednesday, March 5, 2025 12:58 PM
> To: Wathsala Wathawana Vithanage <wathsala.vithanage@....com>
> Cc: Alex Williamson <alex.williamson@...hat.com>; linux-
> kernel@...r.kernel.org; nd <nd@....com>; Kevin Tian <kevin.tian@...el.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>; Honnappa Nagarahalli
> <Honnappa.Nagarahalli@....com>; Jeremy Linton <Jeremy.Linton@....com>
> Subject: Re: [RFC PATCH] vfio/pci: add PCIe TPH to device feature ioctl
> 
> On Wed, Mar 05, 2025 at 06:11:22AM +0000, Wathsala Wathawana Vithanage
> wrote:
> 
> > By not enabling TPH in device-specific mode, hypervisors can ensure
> > that setting an ST in a device-specific location (like queue contexts)
> > will have no effect. VMs should also not be allowed to enable TPH.
> 
> So many workloads run inside VMs now for security reasons that is not a
> reasonable approach.
> 
> > I believe this could
> > be enforced by trapping (causing VM exits) on MSI-X/ST table writes.
> 
> Yes, I think this was always part of the plan for virtualization when using a MSI-X
> table.
> 
> > Having said that, regardless of this proposal or the availability of
> > kernel TPH support, a VFIO driver could enable TPH and set an
> > arbitrary ST on the MSI-X/ST table or a device-specific location on
> > supported platforms. If the driver doesn't have a list of valid STs,
> > it can enumerate 8- or 16-bit STs and measure access latencies to determine
> valid ones.
> 
> And you think it is absolutely true that no TPH value can cause a platform
> malfunction or security failure?
> 

I think such hardware bugs are inevitable :).
Would disabling TPH in the kernel and preventing config-writes that enables
TPH from the user-space by trapping them in the kernel work as a solution?
That requires trapping config-writes.

--wathsala




Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ