Received: by 2002:ac0:946b:0:0:0:0:0 with SMTP id j40csp642524imj; Wed, 13 Feb 2019 14:50:12 -0800 (PST) X-Google-Smtp-Source: AHgI3Ib6qECM9dU+7J/mUPmFa9muVFc22OZA0QcvBzCADKAXjZUTS49O99UVHnsGBDziH5QDf1vY X-Received: by 2002:a62:2bc4:: with SMTP id r187mr578430pfr.25.1550098212851; Wed, 13 Feb 2019 14:50:12 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1550098212; cv=none; d=google.com; s=arc-20160816; b=SXarieRrhzHpDM1Sb/AH0k++tilWBesI4fjuMa8c/aSYqSiS3qnXiQw7/Mt++MaTNx DkK0KY49un2hNTCGSk5uH4nyukDupHSPZCdEzN3f4qFxF6tzYDXs9TuPqzCgPCQHyxUX aLYc0pJPSyU+Zr94fSveqUVJqNt6U4100kYwbfdDK/QkFDycpvkHqruHHzTvvgY0mqOZ 3Gq9pbjPHcivlT/6oLw9LOqo37m9yo0Hf55Y9dOJ3L4PwXtaBcXpvHAL7cbiM8dkUBhj h4ncanaAtDGHCYZliYM8KziVnNZ0KiaWE5TeTD7dQDOpH2ucBx70Pcm4mHviTQzDiRoV 2Y4Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date; bh=P0E2GWtkrX4M1kv7JyDhiiAQPWvKOVbo1lr/Dr61Y84=; b=tEtE+WJCxbdUdDPsv1/hTgLZqqUMlU/6fpmDamx8zTr4z31bmlLAY2LOPCc6RNFMOk 2B/ZoyikosGmlhaz6VJ/gW+3PAiQ0abd8+LwsbvVmzVZBWh9o4Jwk7/tZOoRYMqde85g 3qZtUgS39gBEmiIBXh1/nCVaBwme5vE8Xmv64AC1kKDCsa/JZTStbIWuw2UJRno7by6e Zj6MuXxeoDHwbKIrXjRh7T5MDG3+1kpxZ7xv/L6vypdzUo0c9O2l5UxubI3rUB0RTdnR 8qqWsXB4XH1wIPNL9HQIdkVodBy9uX6fzLsH2xh003k5ogZsXxLin7iJN75IAMuLcPeo zfaQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id q22si561847plr.61.2019.02.13.14.49.55; Wed, 13 Feb 2019 14:50:12 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2388651AbfBMRMA (ORCPT + 99 others); Wed, 13 Feb 2019 12:12:00 -0500 Received: from mx1.redhat.com ([209.132.183.28]:54672 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729760AbfBMRL7 (ORCPT ); Wed, 13 Feb 2019 12:11:59 -0500 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 5C8DF300ADE; Wed, 13 Feb 2019 17:11:59 +0000 (UTC) Received: from w520.home (ovpn-116-24.phx2.redhat.com [10.3.116.24]) by smtp.corp.redhat.com (Postfix) with ESMTP id 9811D19C7B; Wed, 13 Feb 2019 17:11:58 +0000 (UTC) Date: Wed, 13 Feb 2019 10:11:58 -0700 From: Alex Williamson To: Konrad Rzeszutek Wilk Cc: Eric Auger , eric.auger.pro@gmail.com, linux-kernel@vger.kernel.org, kvm@vger.kernel.org Subject: Re: [PATCH] vfio_pci: Enable memory accesses before calling pci_map_rom Message-ID: <20190213101158.707d963d@w520.home> In-Reply-To: <20190213162821.GC22883@char.us.oracle.com> References: <20190213101406.3934-1-eric.auger@redhat.com> <20190213162821.GC22883@char.us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.29]); Wed, 13 Feb 2019 17:11:59 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 13 Feb 2019 11:28:21 -0500 Konrad Rzeszutek Wilk 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 > > --- > > 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 > >