From: "Roger Pau Monné" <roger@xenproject.org>
To: Jan Beulich <jbeulich@suse.com>
Cc: Stewart Hildebrand <stewart.hildebrand@amd.com>,
"Daniel P. Smith" <dpsmith@apertussolutions.com>,
xen-devel@lists.xenproject.org
Subject: Re: [PATCH v5 1/9] vpci: move BAR mapping permissions checks
Date: Thu, 23 Jul 2026 16:57:04 +0200 [thread overview]
Message-ID: <amIrwLuIdOBaAi9d@macbook.local> (raw)
In-Reply-To: <0255d2bf-748e-444b-8c09-f69925ec88c4@suse.com>
On Thu, Jul 23, 2026 at 04:44:26PM +0200, Jan Beulich wrote:
> On 08.07.2026 23:02, Stewart Hildebrand wrote:
> > There's no need to defer the permissions checks. Perform them right away
> > in modify_bars().
> >
> > As a result of the move, the permissions checks will now cover the whole
> > BAR before any holes are removed.
>
> Is this a good idea though? A really good toolstack would avoid granting
> access to e.g. the MSI-X table.
>
> > Carry over the domain_crash() in the error path for domUs.
>
> I don't think this is warranted.
>
> > --- a/xen/drivers/vpci/header.c
> > +++ b/xen/drivers/vpci/header.c
> > @@ -58,24 +58,6 @@ static int cf_check map_range(
> > * offset of the current address from the BAR start.
> > */
> > unsigned long map_mfn = start_mfn + s - start_gfn;
> > - unsigned long m_end = map_mfn + size - 1;
> > -
> > - if ( !iomem_access_permitted(map->d, map_mfn, m_end) )
> > - {
> > - printk(XENLOG_G_WARNING
> > - "%pd denied access to MMIO range [%#lx, %#lx]\n",
> > - map->d, map_mfn, m_end);
> > - return -EPERM;
> > - }
> > -
> > - rc = xsm_iomem_mapping_vpci(XSM_HOOK, map->d, map_mfn, m_end, map->map);
> > - if ( rc )
> > - {
> > - printk(XENLOG_G_WARNING
> > - "%pd XSM denied access to MMIO range [%#lx, %#lx]: %d\n",
> > - map->d, map_mfn, m_end, rc);
>
> I realize you literally only take what's here, but ...
>
> > @@ -369,6 +351,28 @@ static int modify_bars(const struct pci_dev *pdev, uint16_t cmd, bool rom_only)
> > return -EINVAL;
> > }
> >
> > + if ( !iomem_access_permitted(pdev->domain, start, end) )
> > + {
> > + printk(XENLOG_G_WARNING
> > + "%pd denied access to MMIO range [%#lx, %#lx]\n",
> > + pdev->domain, start, end);
> > + if ( !is_hardware_domain(pdev->domain) )
> > + domain_crash(pdev->domain);
> > + return -EPERM;
> > + }
> > +
> > + rc = xsm_iomem_mapping_vpci(XSM_HOOK, pdev->domain, start, end,
> > + !!(cmd & PCI_COMMAND_MEMORY));
> > + if ( rc )
> > + {
> > + printk(XENLOG_G_WARNING
> > + "%pd XSM denied access to MMIO range [%#lx, %#lx]: %d\n",
> > + pdev->domain, start, end, rc);
>
> ... is the logging of rc actually useful? Afaict it's only ever going to be
> -EPERM.
I think Flask can also return -EACCES, not that it's very relevant I'm
afraid. It's likely too late now, but those XSM checks should instead
return a bool to avoid this kind of confusion with the returned
error? (or whether diverse return codes are indeed expected).
Thanks, Roger.
next prev parent reply other threads:[~2026-07-23 14:57 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-08 21:02 [PATCH v5 0/9] vpci: allow queueing of mapping operations Stewart Hildebrand
2026-07-08 21:02 ` [PATCH v5 1/9] vpci: move BAR mapping permissions checks Stewart Hildebrand
2026-07-23 14:44 ` Jan Beulich
2026-07-23 14:57 ` Roger Pau Monné [this message]
2026-07-23 15:06 ` Jan Beulich
2026-07-23 20:09 ` Daniel P. Smith
2026-07-08 21:02 ` [PATCH v5 2/9] vpci: make BAR mapping more resilient for the hardware domain Stewart Hildebrand
2026-07-23 14:55 ` Jan Beulich
2026-07-08 21:02 ` [PATCH v5 3/9] vpci: only check BAR validity once Stewart Hildebrand
2026-07-23 15:46 ` Jan Beulich
2026-07-08 21:02 ` [PATCH v5 4/9] vpci/msix: move MSI-X hole punching as a result of memory decoding enable Stewart Hildebrand
2026-07-23 15:59 ` Jan Beulich
2026-07-08 21:02 ` [PATCH v5 5/9] vpci: simplify handling of memory decoding and ROM enable writes Stewart Hildebrand
2026-07-08 21:02 ` [PATCH v5 6/9] vpci: create mem local variables Stewart Hildebrand
2026-07-08 21:02 ` [PATCH v5 7/9] vpci: split vpci_process_pending() Stewart Hildebrand
2026-07-08 21:02 ` [PATCH v5 8/9] vpci: allow queueing of mapping operations Stewart Hildebrand
2026-07-08 21:02 ` [PATCH v5 9/9] vpci: don't pass command value to modify_bars() Stewart Hildebrand
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=amIrwLuIdOBaAi9d@macbook.local \
--to=roger@xenproject.org \
--cc=dpsmith@apertussolutions.com \
--cc=jbeulich@suse.com \
--cc=stewart.hildebrand@amd.com \
--cc=xen-devel@lists.xenproject.org \
/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.