Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp2188926pxj; Sun, 9 May 2021 18:36:10 -0700 (PDT) X-Google-Smtp-Source: ABdhPJz6UOVquHfGUvKREn2UsFth2LOb1v/wkQ9FoxKNAh1yCUd458ZfdQMCSGjVx10CqmSBCZfV X-Received: by 2002:a92:c7a1:: with SMTP id f1mr19101008ilk.33.1620610569835; Sun, 09 May 2021 18:36:09 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1620610569; cv=none; d=google.com; s=arc-20160816; b=CLRRXS3KIEzblABJh1Ulge/bUR9KPtxsNYwM4Pw7NcuKB4x+cuDKB5UXwcAJjPUVwF 0jMp1vrvp1I1V5PLfiFrWwGZ8JB/QDcRDo5DA6FkMrBb9R5X9YUBI2rjLzf5Tb5Lay3i c3aqeDKJwJ3BQTN4JU1eiB9YaGKEpSL+E3Ct0mTgxQ743qocTT/p6SgH36Ow8vm03swH bRW3ZdHnYuXHQgAeBoDktfr82C+PtGEOipUeO4CtevkhXwopPETQiVv6hI0bTOL9CDos hSVDgq4UOPsdaBeHDnNEdUVYqZ+2n6IxVnt5qb0oCbSx+vyjczFFFnoSCLkJXqCmP6MT eZfA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :organization:references:in-reply-to:message-id:subject:cc:to:from :date:dkim-signature; bh=G6F/Zc94YePQW7AcfQRcHnmyKkKZaaJbaatLrem/2Q0=; b=xFZA6jt9H2QmjHFO7GjiFgMabK5TdkMItuXKwEiu2FzlUevpnMrZdtUdBrnJFa4Eh5 KVbhqWRHeWrxPpXZRrtd1pSI5r9tymjoPXII1mxrpZMtphspzfPtCTM8MSVtWN1NStdX mX9rKBfJ2u0RaxPsGkgO04Fyjx7zZkhEJO3nWjocPrkoLSv/zGLba2oDkYi+UX6/iJx9 wOIF10X1vFR2RRjCyiEWyG9/TLhqK8O299NL7XhTyV6x3GVh0WXnYRVMiPsBqtNyS4j4 61r+0CZ+sMIZs4gy7hDgIwYlZcPwmyBlCjZIxfZqw+AicG7F91M8ucUTR3V/jU7HJupi 5ydA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=FbUm5K8N; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id u9si2254427jak.104.2021.05.09.18.35.56; Sun, 09 May 2021 18:36:09 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=FbUm5K8N; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230073AbhEJBfQ (ORCPT + 99 others); Sun, 9 May 2021 21:35:16 -0400 Received: from us-smtp-delivery-124.mimecast.com ([170.10.133.124]:22010 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229666AbhEJBfP (ORCPT ); Sun, 9 May 2021 21:35:15 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1620610451; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=G6F/Zc94YePQW7AcfQRcHnmyKkKZaaJbaatLrem/2Q0=; b=FbUm5K8Nq9jsI6LxwgMgp6bTVrBmuRtAMH7XUeE+57Dmtv33pLlPX9yFLKS6fmiFQ5JglU QlFlR/Kxy2gbl4RKVhNmLQBqZ57GtS/1j6+D66DWPko+8TWhxTKJclv15RFNKwDFX2VJcN Z/LSVptteZgGH/DDH4MdJ8cHyUmogD0= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-554-ixLWuBhbNBWuRm1ScIgBgA-1; Sun, 09 May 2021 21:34:09 -0400 X-MC-Unique: ixLWuBhbNBWuRm1ScIgBgA-1 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id BE192107ACCA; Mon, 10 May 2021 01:34:08 +0000 (UTC) Received: from x1.home.shazbot.org (ovpn-113-225.phx2.redhat.com [10.3.113.225]) by smtp.corp.redhat.com (Postfix) with ESMTP id 3C3CD610D0; Mon, 10 May 2021 01:34:08 +0000 (UTC) Date: Sun, 9 May 2021 19:34:08 -0600 From: Alex Williamson To: Yuan Yao Cc: tkffaul@outlook.com, kvm@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] vfio/pci: Sanity check IGD OpRegion Size Message-ID: <20210509193408.22ae2b2a@x1.home.shazbot.org> In-Reply-To: <20210510011014.q6xfcmqopbqgepbq@yy-desk-7060> References: <162041357421.21800.16214130780777455390.stgit@omen> <20210510011014.q6xfcmqopbqgepbq@yy-desk-7060> Organization: Red Hat MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 10 May 2021 09:10:14 +0800 Yuan Yao wrote: > On Fri, May 07, 2021 at 12:53:17PM -0600, Alex Williamson wrote: > > The size field of the IGD OpRegion table is supposed to indicate table > > size in KB, but we've seen at least one report of a BIOS that appears > > to incorrectly report size in bytes. The default size is 8 (*1024 = > > 8KB), but an incorrect implementation may report 8192 (*1024 = 8MB) > > and can cause a variety of mapping errors. > > > > It's believed that 8MB would be an implausible, if not absurd, actual > > size, so we can probably be pretty safe in assuming this is a BIOS bug > > where the intended size is likely 8KB. > > > > Reported-by: Travis Faulhaber > > Tested-by: Travis Faulhaber > > Signed-off-by: Alex Williamson > > --- > > drivers/vfio/pci/vfio_pci_igd.c | 11 ++++++++++- > > 1 file changed, 10 insertions(+), 1 deletion(-) > > > > diff --git a/drivers/vfio/pci/vfio_pci_igd.c b/drivers/vfio/pci/vfio_pci_igd.c > > index 228df565e9bc..c89a4797cd18 100644 > > --- a/drivers/vfio/pci/vfio_pci_igd.c > > +++ b/drivers/vfio/pci/vfio_pci_igd.c > > @@ -86,7 +86,16 @@ static int vfio_pci_igd_opregion_init(struct vfio_pci_device *vdev) > > return -EINVAL; > > } > > > > - size *= 1024; /* In KB */ > > + /* > > + * The OpRegion size field is specified as size in KB, but there have been > > + * user reports where this field appears to report size in bytes. If we > > + * read 8192, assume this is the case. > > + */ > > + if (size == OPREGION_SIZE) > > Is "size >= OPREGION_SIZE" or "size >= smaller but still implausible value > (like 4096)" better for covering more bad BIOS implementation cases ? We haven't seen such cases and it seems like a BIOS implementation competent enough to use something other than the default size, probably might get the units correct for this field. Our footing for assuming this specific implementation error gets shakier if we try to apply it beyond the default size, imo. Thanks, Alex