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: <20240725212915.GA860294@bhelgaas>
Date: Thu, 25 Jul 2024 16:29:15 -0500
From: Bjorn Helgaas <helgaas@...nel.org>
To: Wei Huang <wei.huang2@....com>
Cc: linux-pci@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-doc@...r.kernel.org, netdev@...r.kernel.org,
	Jonathan.Cameron@...wei.com, corbet@....net, davem@...emloft.net,
	edumazet@...gle.com, kuba@...nel.org, pabeni@...hat.com,
	alex.williamson@...hat.com, gospo@...adcom.com,
	michael.chan@...adcom.com, ajit.khaparde@...adcom.com,
	somnath.kotur@...adcom.com, andrew.gospodarek@...adcom.com,
	manoj.panicker2@....com, Eric.VanTassell@....com,
	vadim.fedorenko@...ux.dev, horms@...nel.org, bagasdotme@...il.com,
	bhelgaas@...gle.com
Subject: Re: [PATCH V3 03/10] PCI/TPH: Add pci=notph to prevent use of TPH

On Wed, Jul 24, 2024 at 03:05:59PM -0500, Wei Huang wrote:
> 
> 
> On 7/23/24 17:41, Bjorn Helgaas wrote:
> > On Wed, Jul 17, 2024 at 03:55:04PM -0500, Wei Huang wrote:
> >> TLP headers with incorrect steering tags (e.g. caused by buggy driver)
> >> can potentially cause issues when the system hardware consumes the tags.
> > 
> > Hmm.  What kind of issues?  Crash?  Data corruption?  Poor
> > performance?
> 
> Not crash or functionality errors. Usually it is QoS related because of
> resource competition. AMD has

Looks like you had more to say here?

I *assume* that both the PH hint and the Steering Tags are only
*hints* and there's no excuse for hardware to corrupt anything (e.g.,
by omitting cache maintenance) even if the hint turns out to be wrong.
If that's the case, I assume "can potentially cause issues" really
just means "might lead to lower performance".  That's what I want to
clarify and confirm.

> >> Provide a kernel option, with related helper functions, to completely
> >> prevent TPH from being enabled.
> > 
> > Also would be nice to have a hint about the difference between "notph"
> > and "nostmode".  Maybe that goes in the "nostmode" patch?  I'm not
> > super clear on all the differences here.
> 
> I can combine them. Here is the combination and it meaning based on TPH
> Control Register values:
> 
> Requestor Enable | ST Mode | Meaning
> ---------------------------------------------------------------
> 00               | xx      | TPH disabled (i.e. notph)
> 01               | 00      | TPH enabled, NO ST Mode (i.e. nostmode)
> 01 or 11         | 01      | Interrupt Vector mode
> 01 or 11         | 10      | Device specific mode
> 
> If you have any other thoughts on how to approach these modes, please
> let me know.

IIRC, there's no interface in this series that reall does anything
with TPH per se; drivers would only use the ST-related things.

If that's the case, maybe "pci=notph" isn't needed yet.

Bjorn

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ