linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jason Gunthorpe <jgg@ziepe.ca>
To: Chathura Rajapaksha <chathura.abeyrathne.lk@gmail.com>
Cc: Yunxiang.Li@amd.com, alex.williamson@redhat.com,
	audit@vger.kernel.org, avihaih@nvidia.com, bhelgaas@google.com,
	chath@bu.edu, eparis@redhat.com, giovanni.cabiddu@intel.com,
	kevin.tian@intel.com, kvm@vger.kernel.org,
	linux-kernel@vger.kernel.org, paul@paul-moore.com,
	schnelle@linux.ibm.com, xin.zeng@intel.com, yahui.cao@intel.com,
	zhangdongdong@eswincomputing.com
Subject: Re: [RFC PATCH 0/2] vfio/pci: Block and audit accesses to unassigned config regions
Date: Mon, 26 May 2025 16:44:24 -0300	[thread overview]
Message-ID: <20250526194424.GG12328@ziepe.ca> (raw)
In-Reply-To: <20250517171459.15231-1-chath@bu.edu>

On Sat, May 17, 2025 at 05:14:59PM +0000, Chathura Rajapaksha wrote:
> On Fri, May 16, 2025 at 2:35 PM Jason Gunthorpe <jgg@ziepe.ca> wrote:
> > > By PCI bus error, I was referring to AER-reported uncorrectable errors.
> > > For example:
> > > pcieport 0000:c0:01.1: PCIe Bus Error: severity=Uncorrected (Fatal), type=Transaction Layer, (Requester ID)
> > > pcieport 0000:c0:01.1:   device [1022:1483] error status/mask=00004000/07a10000
> > > pcieport 0000:c0:01.1:    [14] CmpltTO                (First)
> >
> > That's sure looks like a device bug. You should not ever get time out
> > for a config space read.
> 
> Just to clarify, the above error was triggered by a write to the
> configuration space. In fact, all the errors we have observed so far
> were triggered by writes to unassigned PCI config space regions.

Yuk, devices really shouldn't refuse to respond to writes or reads :(

> So far, we have seen this issue on five PCIe devices across GPU and
> storage classes from two different vendors. 

Ugh, that's awful.

> > Alternatively you could handle this in qemu by sanitizing the config
> > space..
> 
> While it's possible to address this issue for QEMU-KVM guests by
> modifying QEMU, PCIe devices can also be assigned directly to
> user-space applications such as DPDK via VFIO. We thought addressing
> this at the VFIO driver level would help mitigate the issue in a
> broader context beyond virtualized environments.

VFIO can probably already trigger command timeouts if it tries hard
enough, as long as it is a contained AER I don't see that the kernel
*needs* to prevent it.. 

For virtualization I really do expect that any serious user will be
tightly controlling the config space and maybe this finding just
supports that qemu needs to be enhanced to have more configurability
here.

It certainly is easier to add an option to qemu to make it block
any address not in a cap chain than to add a bunch of PCI ID tables
and detection to the kernel..

Jason

      reply	other threads:[~2025-05-26 19:44 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-04-26 21:22 [RFC PATCH 0/2] vfio/pci: Block and audit accesses to unassigned config regions Chathura Rajapaksha
2025-04-26 21:22 ` [RFC PATCH 1/2] block accesses to unassigned PCI " Chathura Rajapaksha
2025-04-28 15:00   ` Bjorn Helgaas
2025-04-26 21:22 ` [RFC PATCH 2/2] audit " Chathura Rajapaksha
2025-04-28 15:05   ` Bjorn Helgaas
2025-05-16 20:41   ` [PATCH RFC " Paul Moore
2025-05-20 16:33     ` Chathura Rajapaksha
2025-05-20 18:08       ` Paul Moore
2025-04-28 13:24 ` [RFC PATCH 0/2] vfio/pci: Block and audit accesses to unassigned " Jason Gunthorpe
2025-04-28 20:25   ` Alex Williamson
2025-04-29 13:44     ` Jason Gunthorpe
2025-05-16 18:17       ` Chathura Rajapaksha
2025-05-16 18:35         ` Jason Gunthorpe
2025-05-17 17:14           ` Chathura Rajapaksha
2025-05-26 19:44             ` Jason Gunthorpe [this message]

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=20250526194424.GG12328@ziepe.ca \
    --to=jgg@ziepe.ca \
    --cc=Yunxiang.Li@amd.com \
    --cc=alex.williamson@redhat.com \
    --cc=audit@vger.kernel.org \
    --cc=avihaih@nvidia.com \
    --cc=bhelgaas@google.com \
    --cc=chath@bu.edu \
    --cc=chathura.abeyrathne.lk@gmail.com \
    --cc=eparis@redhat.com \
    --cc=giovanni.cabiddu@intel.com \
    --cc=kevin.tian@intel.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=paul@paul-moore.com \
    --cc=schnelle@linux.ibm.com \
    --cc=xin.zeng@intel.com \
    --cc=yahui.cao@intel.com \
    --cc=zhangdongdong@eswincomputing.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).