All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jason Gunthorpe <jgg@ziepe.ca>
To: Baolu Lu <baolu.lu@linux.intel.com>
Cc: Kevin Tian <kevin.tian@intel.com>, Joerg Roedel <joro@8bytes.org>,
	Will Deacon <will@kernel.org>,
	Robin Murphy <robin.murphy@arm.com>,
	Jean-Philippe Brucker <jean-philippe@linaro.org>,
	Nicolin Chen <nicolinc@nvidia.com>, Yi Liu <yi.l.liu@intel.com>,
	Jacob Pan <jacob.jun.pan@linux.intel.com>,
	Joel Granados <j.granados@samsung.com>,
	iommu@lists.linux.dev, virtualization@lists.linux-foundation.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v7 07/10] iommufd: Fault-capable hwpt attach/detach/replace
Date: Tue, 9 Jul 2024 14:36:43 -0300	[thread overview]
Message-ID: <20240709173643.GI14050@ziepe.ca> (raw)
In-Reply-To: <7421b923-0bd6-4c9d-81e6-07d954085171@linux.intel.com>

On Mon, Jul 01, 2024 at 01:55:12PM +0800, Baolu Lu wrote:
> On 2024/6/29 5:17, Jason Gunthorpe wrote:
> > On Sun, Jun 16, 2024 at 02:11:52PM +0800, Lu Baolu wrote:
> > > +static int iommufd_fault_iopf_enable(struct iommufd_device *idev)
> > > +{
> > > +	struct device *dev = idev->dev;
> > > +	int ret;
> > > +
> > > +	/*
> > > +	 * Once we turn on PCI/PRI support for VF, the response failure code
> > > +	 * should not be forwarded to the hardware due to PRI being a shared
> > > +	 * resource between PF and VFs. There is no coordination for this
> > > +	 * shared capability. This waits for a vPRI reset to recover.
> > > +	 */
> > > +	if (dev_is_pci(dev) && to_pci_dev(dev)->is_virtfn)
> > > +		return -EINVAL;
> > I don't quite get this remark, isn't not supporting PRI on VFs kind of
> > useless? What is the story here?
> 
> This remark is trying to explain why attaching an iopf-capable hwpt to a
> VF is not supported for now. The PCI sepc (section 10.4.2.1) states that
> a response failure will disable the PRI on the function. But for PF/VF
> case, the PRI is a shared resource, therefore a response failure on a VF
> might cause iopf on other VFs to malfunction. So, we start from simple
> by not allowing it.

You are talking about IOMMU_PAGE_RESP_FAILURE ?

But this is bad already, something like SVA could trigger
IOMMU_PAGE_RESP_FAILURE on a VF without iommufd today. Due to memory
allocation failure in iommu_report_device_fault()

And then we pass in code from userspace and blindly cast it to
enum iommu_page_response_code ?

Probably we should just only support IOMMU_PAGE_RESP_SUCCESS/INVALID
from userspace and block FAILURE entirely. Probably the VMM should
emulate FAILURE by disabling PRI on by changing to a non PRI domain.

And this subtle uABI leak needs a fix:

		iopf_group_response(group, response.code);

response.code and enum iommu_page_response_code are different
enums, and there is no range check. Need a static assert at least and
a range check. Send a followup patch please

Jason

  reply	other threads:[~2024-07-09 17:36 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-16  6:11 [PATCH v7 00/10] IOMMUFD: Deliver IO page faults to user space Lu Baolu
2024-06-16  6:11 ` [PATCH v7 01/10] iommu: Introduce domain attachment handle Lu Baolu
2024-06-28 20:46   ` Jason Gunthorpe
2024-06-16  6:11 ` [PATCH v7 02/10] iommu: Remove sva handle list Lu Baolu
2024-06-28 21:15   ` Jason Gunthorpe
2024-06-16  6:11 ` [PATCH v7 03/10] iommu: Add attach handle to struct iopf_group Lu Baolu
2024-06-17  7:41   ` Tian, Kevin
2024-06-18  1:35     ` Baolu Lu
2024-06-28 20:48   ` Jason Gunthorpe
2024-06-16  6:11 ` [PATCH v7 04/10] iommu: Extend domain attach group with handle support Lu Baolu
2024-06-28 21:06   ` Jason Gunthorpe
2024-06-29  3:58     ` Baolu Lu
2024-06-16  6:11 ` [PATCH v7 05/10] iommufd: Add fault and response message definitions Lu Baolu
2024-06-16  6:11 ` [PATCH v7 06/10] iommufd: Add iommufd fault object Lu Baolu
2024-06-28 22:14   ` Jason Gunthorpe
2024-06-16  6:11 ` [PATCH v7 07/10] iommufd: Fault-capable hwpt attach/detach/replace Lu Baolu
2024-06-28 21:17   ` Jason Gunthorpe
2024-07-01  5:55     ` Baolu Lu
2024-07-09 17:36       ` Jason Gunthorpe [this message]
2024-07-10  0:32         ` Tian, Kevin
2024-07-10  8:36         ` Baolu Lu
2024-06-16  6:11 ` [PATCH v7 08/10] iommufd: Associate fault object with iommufd_hw_pgtable Lu Baolu
2024-06-28 22:13   ` Jason Gunthorpe
2024-07-01  5:26     ` Baolu Lu
2024-06-16  6:11 ` [PATCH v7 09/10] iommufd/selftest: Add IOPF support for mock device Lu Baolu
2024-06-16  6:11 ` [PATCH v7 10/10] iommufd/selftest: Add coverage for IOPF test Lu Baolu
2024-06-17  7:46 ` [PATCH v7 00/10] IOMMUFD: Deliver IO page faults to user space Tian, Kevin
2024-06-28 22:14 ` Jason Gunthorpe
2024-07-02  6:42   ` Baolu Lu

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=20240709173643.GI14050@ziepe.ca \
    --to=jgg@ziepe.ca \
    --cc=baolu.lu@linux.intel.com \
    --cc=iommu@lists.linux.dev \
    --cc=j.granados@samsung.com \
    --cc=jacob.jun.pan@linux.intel.com \
    --cc=jean-philippe@linaro.org \
    --cc=joro@8bytes.org \
    --cc=kevin.tian@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nicolinc@nvidia.com \
    --cc=robin.murphy@arm.com \
    --cc=virtualization@lists.linux-foundation.org \
    --cc=will@kernel.org \
    --cc=yi.l.liu@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.