From: Jonathan Cameron <Jonathan.Cameron@huawei.com>
To: <ira.weiny@intel.com>
Cc: Dan Williams <dan.j.williams@intel.com>,
Bjorn Helgaas <bhelgaas@google.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
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 V2 1/2] PCI: Allow drivers to request exclusive config regions
Date: Thu, 25 Aug 2022 16:06:58 +0100 [thread overview]
Message-ID: <20220825160658.000051a6@huawei.com> (raw)
In-Reply-To: <20220824232450.723179-2-ira.weiny@intel.com>
On Wed, 24 Aug 2022 16:24:49 -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>
> Cc: Jonathan Cameron <Jonathan.Cameron@huawei.com>
> Suggested-by: Dan Williams <dan.j.williams@intel.com>
> Signed-off-by: Ira Weiny <ira.weiny@intel.com>
One comment inline.
I'm not totally convinced of the necessity of this, but done this way
it has very little impact so I'm fine with it.
Other than the comment about not realigning things...
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
>
> ---
> Changes from V1:
> Greg and Dan:
> Create and use pci_warn_once() to keep the user from spamming
> Dan:
> Clarify the warn message
>
> Changes from[1]:
> Change name to pci_request_config_region_exclusive()
> Don't flag reads at all.
> Allow writes with a warn and taint of the kernel.
> Update commit message
> Forward port to latest tree.
> ---
> drivers/pci/pci-sysfs.c | 7 +++++++
> drivers/pci/probe.c | 6 ++++++
> include/linux/ioport.h | 2 ++
> include/linux/pci.h | 33 +++++++++++++++++++++++++--------
> kernel/resource.c | 13 ++++++++-----
> 5 files changed, 48 insertions(+), 13 deletions(-)
>
> /* drivers/pci/bus.c */
> void pci_add_resource(struct list_head *resources, struct resource *res);
> void pci_add_resource_offset(struct list_head *resources, struct resource *res,
> @@ -2486,14 +2502,15 @@ void pci_uevent_ers(struct pci_dev *pdev, enum pci_ers_result err_type);
> #define pci_printk(level, pdev, fmt, arg...) \
> dev_printk(level, &(pdev)->dev, fmt, ##arg)
>
> -#define pci_emerg(pdev, fmt, arg...) dev_emerg(&(pdev)->dev, fmt, ##arg)
> -#define pci_alert(pdev, fmt, arg...) dev_alert(&(pdev)->dev, fmt, ##arg)
> -#define pci_crit(pdev, fmt, arg...) dev_crit(&(pdev)->dev, fmt, ##arg)
> -#define pci_err(pdev, fmt, arg...) dev_err(&(pdev)->dev, fmt, ##arg)
> -#define pci_warn(pdev, fmt, arg...) dev_warn(&(pdev)->dev, fmt, ##arg)
> -#define pci_notice(pdev, fmt, arg...) dev_notice(&(pdev)->dev, fmt, ##arg)
> -#define pci_info(pdev, fmt, arg...) dev_info(&(pdev)->dev, fmt, ##arg)
> -#define pci_dbg(pdev, fmt, arg...) dev_dbg(&(pdev)->dev, fmt, ##arg)
> +#define pci_emerg(pdev, fmt, arg...) dev_emerg(&(pdev)->dev, fmt, ##arg)
> +#define pci_alert(pdev, fmt, arg...) dev_alert(&(pdev)->dev, fmt, ##arg)
> +#define pci_crit(pdev, fmt, arg...) dev_crit(&(pdev)->dev, fmt, ##arg)
> +#define pci_err(pdev, fmt, arg...) dev_err(&(pdev)->dev, fmt, ##arg)
> +#define pci_warn(pdev, fmt, arg...) dev_warn(&(pdev)->dev, fmt, ##arg)
> +#define pci_warn_once(pdev, fmt, arg...) dev_warn_once(&(pdev)->dev, fmt, ##arg)
> +#define pci_notice(pdev, fmt, arg...) dev_notice(&(pdev)->dev, fmt, ##arg)
> +#define pci_info(pdev, fmt, arg...) dev_info(&(pdev)->dev, fmt, ##arg)
> +#define pci_dbg(pdev, fmt, arg...) dev_dbg(&(pdev)->dev, fmt, ##arg)
This realignment is a lot of noise. Do we really care about one diffentlyu
aligned entry? + if you are going to do it two tabs rather than a space
following the tab (I think that's what you have here?)
>
next prev parent reply other threads:[~2022-08-25 15:07 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-24 23:24 [PATCH V2 0/2] CXL: Taint user access to DOE mailbox config space ira.weiny
2022-08-24 23:24 ` [PATCH V2 1/2] PCI: Allow drivers to request exclusive config regions ira.weiny
2022-08-25 7:34 ` Greg Kroah-Hartman
2022-08-25 20:03 ` Ira Weiny
2022-08-25 15:06 ` Jonathan Cameron [this message]
2022-08-25 15:47 ` Ira Weiny
2022-08-30 12:53 ` Jonathan Cameron
2022-08-24 23:24 ` [PATCH V2 2/2] cxl/doe: Request exclusive DOE access ira.weiny
2022-08-25 14:59 ` 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=20220825160658.000051a6@huawei.com \
--to=jonathan.cameron@huawei.com \
--cc=alison.schofield@intel.com \
--cc=bhelgaas@google.com \
--cc=bwidawsk@kernel.org \
--cc=dan.j.williams@intel.com \
--cc=gregkh@linuxfoundation.org \
--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