Linux-PCI Archive on lore.kernel.org
 help / color / Atom feed
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Dan Williams <dan.j.williams@intel.com>
Cc: bhelgaas@google.com,
	Jonathan Cameron <Jonathan.Cameron@huawei.com>,
	linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] PCI: Allow drivers to claim exclusive access to config regions
Date: Thu, 25 Mar 2021 07:54:59 +0100
Message-ID: <YFwzw3VK0okr+taA@kroah.com> (raw)
In-Reply-To: <161663543465.1867664.5674061943008380442.stgit@dwillia2-desk3.amr.corp.intel.com>

On Wed, Mar 24, 2021 at 06:23:54PM -0700, Dan Williams wrote:
> The PCIE Data Object Exchange (DOE) mailbox is a protocol run over
> configuration cycles. It assumes one initiator at a time is
> reading/writing the data registers.

That sounds like a horrible protocol for a multi-processor system.
Where is it described and who can we go complain to for creating such a
mess?

> If userspace reads from the response
> data payload it may steal data that a kernel driver was expecting to
> read. If userspace writes to the request payload it may corrupt the
> request a driver was trying to send.

Fun!  So you want to keep root in userspace from doing this?  I thought
we already do that today?

> Introduce pci_{request,release}_config_region() for a driver to exclude
> the possibility of userspace induced corruption while accessing the DOE
> mailbox. Likely there are other configuration state assumptions that a
> driver may want to assert are under its exclusive control, so this
> capability is not limited to any specific configuration range.

As you do not have a user for these functions, it's hard to see how they
would be used.  We also really can't add new apis with no in-tree users,
so do you have a patch series that requires this functionality
somewhere?

> Since writes are targeted and are already prepared for failure the
> entire request is failed. The same can not be done for reads as the
> device completely disappears from lspci output if any configuration
> register in the request is exclusive. Instead skip the actual
> configuration cycle on a per-access basis and return all f's as if the
> read had failed.

returning all ff is a huge hint to many drivers that the device is gone,
not that it just failed.  So what happens to code that thinks that and
then tears stuff down as if the device has been removed?

Trying to protect drivers from userspace here feels odd, what userspace
tools are trying to access these devices while they are under
"exclusive" control from the kernel?  lspci not running as root should
not be doing anything crazy, but if you want to run it as root,
shouldn't you be allowed to access it properly?

What hardware has this problem that we need to claim exclusive ownership
over that differs from the old hardware we used to have that would do
crazy things when reading from from userspace?  We had this problem a
long time ago and lived with it, what changed now?

thanks,

greg k-h

  reply index

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-25  1:23 Dan Williams
2021-03-25  6:54 ` Greg Kroah-Hartman [this message]
2021-03-25  8:29   ` Christoph Hellwig
2021-03-25 17:55     ` Dan Williams
2021-03-26  9:18       ` Greg Kroah-Hartman
2021-03-25 17:43   ` Dan Williams
2021-03-26  9:28     ` Greg Kroah-Hartman
2021-03-26 16:12 ` Bjorn Helgaas
2021-03-27 10:46   ` Greg Kroah-Hartman
2021-05-13 21:28     ` Dan Williams
2021-03-29 16:46   ` Dan Williams
2021-03-30 12:20     ` Jonathan Cameron

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YFwzw3VK0okr+taA@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=Jonathan.Cameron@huawei.com \
    --cc=bhelgaas@google.com \
    --cc=dan.j.williams@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Linux-PCI Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-pci/0 linux-pci/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-pci linux-pci/ https://lore.kernel.org/linux-pci \
		linux-pci@vger.kernel.org
	public-inbox-index linux-pci

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-pci


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git