From: Paul Moore <paul@paul-moore.com>
To: Chathura Rajapaksha <chathura.abeyrathne.lk@gmail.com>,
kvm@vger.kernel.org
Cc: Chathura Rajapaksha <chath@bu.edu>, William Wang <xwill@bu.edu>,
Alex Williamson <alex.williamson@redhat.com>,
Eric Paris <eparis@redhat.com>,
Niklas Schnelle <schnelle@linux.ibm.com>,
Xin Zeng <xin.zeng@intel.com>, Kevin Tian <kevin.tian@intel.com>,
Bjorn Helgaas <bhelgaas@google.com>,
Yahui Cao <yahui.cao@intel.com>,
Yunxiang Li <Yunxiang.Li@amd.com>,
Dongdong Zhang <zhangdongdong@eswincomputing.com>,
Avihai Horon <avihaih@nvidia.com>,
linux-kernel@vger.kernel.org, audit@vger.kernel.org
Subject: Re: [PATCH RFC 2/2] audit accesses to unassigned PCI config regions
Date: Fri, 16 May 2025 16:41:32 -0400 [thread overview]
Message-ID: <669e1abd542da9fbcfb466d134f01767@paul-moore.com> (raw)
In-Reply-To: <20250426212253.40473-3-chath@bu.edu>
On Apr 26, 2025 Chathura Rajapaksha <chathura.abeyrathne.lk@gmail.com> wrote:
>
> Some PCIe devices trigger PCI bus errors when accesses are made to
> unassigned regions within their PCI configuration space. On certain
> platforms, this can lead to host system hangs or reboots.
>
> The current vfio-pci driver allows guests to access unassigned regions
> in the PCI configuration space. Therefore, when such a device is passed
> through to a guest, the guest can induce a host system hang or reboot
> through crafted configuration space accesses, posing a threat to
> system availability.
>
> This patch introduces auditing support for config space accesses to
> unassigned regions. When enabled, this logs such accesses for all
> passthrough devices.
> This feature is controlled via a new Kconfig option:
>
> CONFIG_VFIO_PCI_UNASSIGNED_ACCESS_AUDIT
>
> A new audit event type, AUDIT_VFIO, has been introduced to support
> this, allowing administrators to monitor and investigate suspicious
> behavior by guests.
I try to encourage people to put a sample audit record in the commit
description as it helps others, even those not overly familiar with the
Linux kernel, know what to expect in the audit log and provide feedback.
> Co-developed by: William Wang <xwill@bu.edu>
>
> Signed-off-by: William Wang <xwill@bu.edu>
> Signed-off-by: Chathura Rajapaksha <chath@bu.edu>
> ---
> drivers/vfio/pci/Kconfig | 12 ++++++++
> drivers/vfio/pci/vfio_pci_config.c | 46 ++++++++++++++++++++++++++++--
> include/uapi/linux/audit.h | 1 +
> 3 files changed, 57 insertions(+), 2 deletions(-)
...
> diff --git a/drivers/vfio/pci/vfio_pci_config.c b/drivers/vfio/pci/vfio_pci_config.c
> index cb4d11aa5598..ddd10904d60f 100644
> --- a/drivers/vfio/pci/vfio_pci_config.c
> +++ b/drivers/vfio/pci/vfio_pci_config.c
> @@ -25,6 +25,7 @@
> #include <linux/uaccess.h>
> #include <linux/vfio.h>
> #include <linux/slab.h>
> +#include <linux/audit.h>
>
> #include "vfio_pci_priv.h"
>
> @@ -1980,6 +1981,37 @@ static size_t vfio_pci_cap_remaining_dword(struct vfio_pci_core_device *vdev,
> return i;
> }
>
> +enum vfio_audit {
> + VFIO_AUDIT_READ,
> + VFIO_AUDIT_WRITE,
> + VFIO_AUDIT_MAX,
> +};
> +
> +static const char * const vfio_audit_str[VFIO_AUDIT_MAX] = {
> + [VFIO_AUDIT_READ] = "READ",
> + [VFIO_AUDIT_WRITE] = "WRITE",
> +};
We generally don't capitalize things like this in audit, "read" and
"write" would be preferred.
> +static void vfio_audit_access(const struct pci_dev *pdev,
> + size_t count, loff_t *ppos, bool blocked, unsigned int op)
> +{
> + struct audit_buffer *ab;
> +
> + if (WARN_ON_ONCE(op >= VFIO_AUDIT_MAX))
> + return;
> + if (audit_enabled == AUDIT_OFF)
> + return;
> + ab = audit_log_start(audit_context(), GFP_ATOMIC, AUDIT_VFIO);
> + if (unlikely(!ab))
> + return;
> + audit_log_format(ab,
> + "device=%04x:%02x:%02x.%d access=%s offset=0x%llx size=%ld blocked=%u\n",
> + pci_domain_nr(pdev->bus), pdev->bus->number,
> + PCI_SLOT(pdev->devfn), PCI_FUNC(pdev->devfn),
> + vfio_audit_str[op], *ppos, count, blocked);
> + audit_log_end(ab);
> +}
In the commit description you talk about a general PCIe device issue
in the first paragraph before going into the specifics of the VFIO
driver. That's all well and good, but it makes me wonder if this
audit code above is better done as a generic PCI function that other
PCI drivers could use if they had similar concerns? Please correct
me if I'm wrong, but other than symbol naming I don't see anyting
above which is specific to VFIO. Thoughts?
Beyond that, I might also change the "access=" field to "op=" as we
already use the "op=" field name for similar things in audit, it would
be good to leverage that familiarity here. Similarly using "res=",
specifically "res=0" for failure/blocked or "res=1" allowed, would
better fit with audit conventions.
> diff --git a/include/uapi/linux/audit.h b/include/uapi/linux/audit.h
> index 9a4ecc9f6dc5..c0aace7384f3 100644
> --- a/include/uapi/linux/audit.h
> +++ b/include/uapi/linux/audit.h
> @@ -122,6 +122,7 @@
> #define AUDIT_OPENAT2 1337 /* Record showing openat2 how args */
> #define AUDIT_DM_CTRL 1338 /* Device Mapper target control */
> #define AUDIT_DM_EVENT 1339 /* Device Mapper events */
> +#define AUDIT_VFIO 1340 /* VFIO events */
If the audit code above becomes more generalized as discussed, I would
expect this to change to AUDIT_VFIO to AUDIT_PCI, or something similar.
--
paul-moore.com
next prev parent reply other threads:[~2025-05-16 20:41 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 ` Paul Moore [this message]
2025-05-20 16:33 ` [PATCH RFC " 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
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=669e1abd542da9fbcfb466d134f01767@paul-moore.com \
--to=paul@paul-moore.com \
--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=kevin.tian@intel.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=schnelle@linux.ibm.com \
--cc=xin.zeng@intel.com \
--cc=xwill@bu.edu \
--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).