[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20190213101158.707d963d@w520.home>
Date: Wed, 13 Feb 2019 10:11:58 -0700
From: Alex Williamson <alex.williamson@...hat.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>
Cc: Eric Auger <eric.auger@...hat.com>, eric.auger.pro@...il.com,
linux-kernel@...r.kernel.org, kvm@...r.kernel.org
Subject: Re: [PATCH] vfio_pci: Enable memory accesses before calling
pci_map_rom
On Wed, 13 Feb 2019 11:28:21 -0500
Konrad Rzeszutek Wilk <konrad.wilk@...cle.com> wrote:
> On Wed, Feb 13, 2019 at 11:14:06AM +0100, Eric Auger wrote:
> > pci_map_rom/pci_get_rom_size() performs memory access in the ROM.
> > In case the Memory Space accesses were disabled, readw() is likely to
> > crash the host with a synchronous external abort (aarch64).
>
> Ouch. Is there an CVE for this?
>
> Also I think this can cause x86 machines to blow up.
>
> See https://xenbits.xen.org/xsa/advisory-120.html
The far more common response to a target abort on x86 is simply a -1
return. Device assignment quickly becomes unfeasible in the general
case, as outlined in the above link by restricting only to SR-IOV VFs,
if we try to claim there is no possible way that the device cannot
trigger a fatal error on the host. Systems implementing APEI pretty
much guarantee that by escalating device specific faults to fatal
errors and removing the host OS from the error handling path. Some
platforms will even trigger a fatal error for a DMA outside of the
range mapped for the device by the IOMMU. We can't probe for this
behavior to restrict the devices, we cannot know how DMA is programmed
for every device in order to babysit it, nor can we guarantee that the
PCI config space command register is the only way a device manages
access to I/O resources hosted on the device. Restricting user access
to the command register therefore seems like a false sense of security,
potentially with behavioral issues to the user.
It would be great if we always had a hook into the error handling path
such that we could declare this as a user generated fault, kill the
user process, and keep running, but we're limited by the error handling
capabilities of the hardware and the degree to which the
platform/firmware allows OS control of that error handling. Thanks,
Alex
> >
> > In case memory accesses were disabled, re-enable them before the call
> > and disable them back again just after.
> >
> > Signed-off-by: Eric Auger <eric.auger@...hat.com>
> > ---
> > drivers/vfio/pci/vfio_pci.c | 14 ++++++++++++++
> > 1 file changed, 14 insertions(+)
> >
> > diff --git a/drivers/vfio/pci/vfio_pci.c b/drivers/vfio/pci/vfio_pci.c
> > index ff60bd1ea587..96b8bbd909d7 100644
> > --- a/drivers/vfio/pci/vfio_pci.c
> > +++ b/drivers/vfio/pci/vfio_pci.c
> > @@ -706,8 +706,10 @@ static long vfio_pci_ioctl(void *device_data,
> > break;
> > case VFIO_PCI_ROM_REGION_INDEX:
> > {
> > + bool mem_access_disabled;
> > void __iomem *io;
> > size_t size;
> > + u16 cmd;
> >
> > info.offset = VFIO_PCI_INDEX_TO_OFFSET(info.index);
> > info.flags = 0;
> > @@ -723,6 +725,13 @@ static long vfio_pci_ioctl(void *device_data,
> > break;
> > }
> >
> > + pci_read_config_word(pdev, PCI_COMMAND, &cmd);
> > + mem_access_disabled = !(cmd & PCI_COMMAND_MEMORY);
> > + if (mem_access_disabled) {
> > + cmd |= PCI_COMMAND_MEMORY;
> > + pci_write_config_word(pdev, PCI_COMMAND, cmd);
> > + }
> > +
> > /* Is it really there? */
> > io = pci_map_rom(pdev, &size);
> > if (!io || !size) {
> > @@ -731,6 +740,11 @@ static long vfio_pci_ioctl(void *device_data,
> > }
> > pci_unmap_rom(pdev, io);
> >
> > + if (mem_access_disabled) {
> > + cmd &= ~PCI_COMMAND_MEMORY;
> > + pci_write_config_word(pdev, PCI_COMMAND, cmd);
> > + }
> > +
> > info.flags = VFIO_REGION_INFO_FLAG_READ;
> > break;
> > }
> > --
> > 2.20.1
> >
Powered by blists - more mailing lists