From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: ira.weiny@intel.com
Cc: Dan Williams <dan.j.williams@intel.com>,
Bjorn Helgaas <bhelgaas@google.com>,
Jonathan Cameron <Jonathan.Cameron@huawei.com>,
Alison Schofield <alison.schofield@intel.com>,
Vishal Verma <vishal.l.verma@intel.com>,
Ben Widawsky <bwidawsk@kernel.org>,
linux-cxl@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-pci@vger.kernel.org
Subject: Re: [PATCH V3 1/2] PCI: Allow drivers to request exclusive config regions
Date: Tue, 27 Sep 2022 09:27:10 +0200 [thread overview]
Message-ID: <YzKlzp2/pSdYiOUf@kroah.com> (raw)
In-Reply-To: <20220926215711.2893286-2-ira.weiny@intel.com>
On Mon, Sep 26, 2022 at 02:57:10PM -0700, ira.weiny@intel.com wrote:
> From: Ira Weiny <ira.weiny@intel.com>
>
> PCI config space access from user space has traditionally been
> unrestricted with writes being an understood risk for device operation.
>
> Unfortunately, device breakage or odd behavior from config writes lacks
> indicators that can leave driver writers confused when evaluating
> failures. This is especially true with the new PCIe Data Object
> Exchange (DOE) mailbox protocol where backdoor shenanigans from user
> space through things such as vendor defined protocols may affect device
> operation without complete breakage.
>
> A prior proposal restricted read and writes completely.[1] Greg and
> Bjorn pointed out that proposal is flawed for a couple of reasons.
> First, lspci should always be allowed and should not interfere with any
> device operation. Second, setpci is a valuable tool that is sometimes
> necessary and it should not be completely restricted.[2] Finally
> methods exist for full lock of device access if required.
>
> Even though access should not be restricted it would be nice for driver
> writers to be able to flag critical parts of the config space such that
> interference from user space can be detected.
>
> Introduce pci_request_config_region_exclusive() to mark exclusive config
> regions. Such regions trigger a warning and kernel taint if accessed
> via user space.
>
> Create pci_warn_once() to restrict the user from spamming the log.
>
> [1] https://lore.kernel.org/all/161663543465.1867664.5674061943008380442.stgit@dwillia2-desk3.amr.corp.intel.com/
> [2] https://lore.kernel.org/all/YF8NGeGv9vYcMfTV@kroah.com/
>
> Cc: Bjorn Helgaas <bhelgaas@google.com>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
> Suggested-by: Dan Williams <dan.j.williams@intel.com>
> Signed-off-by: Ira Weiny <ira.weiny@intel.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
next prev parent reply other threads:[~2022-09-27 7:27 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-26 21:57 [PATCH V3 0/2] CXL: Taint user access to DOE mailbox config space ira.weiny
2022-09-26 21:57 ` [PATCH V3 1/2] PCI: Allow drivers to request exclusive config regions ira.weiny
2022-09-27 7:27 ` Greg Kroah-Hartman [this message]
2022-09-27 18:51 ` Bjorn Helgaas
2022-09-26 21:57 ` [PATCH V3 2/2] cxl/doe: Request exclusive DOE access ira.weiny
2022-09-27 13:58 ` Jonathan Cameron
2022-10-21 23:29 ` [PATCH V3 0/2] CXL: Taint user access to DOE mailbox config space Dan Williams
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=YzKlzp2/pSdYiOUf@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=Jonathan.Cameron@huawei.com \
--cc=alison.schofield@intel.com \
--cc=bhelgaas@google.com \
--cc=bwidawsk@kernel.org \
--cc=dan.j.williams@intel.com \
--cc=ira.weiny@intel.com \
--cc=linux-cxl@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=vishal.l.verma@intel.com \
/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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).