Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp871184ybl; Wed, 11 Dec 2019 08:46:36 -0800 (PST) X-Google-Smtp-Source: APXvYqxYkOgoNYU9wgxGbO2FBxar7K/aQvgGoH0kbmACagePax6ec+G55MSHD2ShJ0VjJ64wzi0O X-Received: by 2002:a05:6830:4da:: with SMTP id s26mr2784821otd.141.1576082796310; Wed, 11 Dec 2019 08:46:36 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1576082796; cv=none; d=google.com; s=arc-20160816; b=KCEf60Hxc0LmyXPk0mb87kj+jxp/yFd5Eh0q0cRKu8BQnr2ohGK1EQO9tr90pDqGQn 4JmtmOH8OnIm1rUFAoX4hseIyPryVRp2ki9MNkdCRGqP3xTeoA3m3w1naD3OXlv09ZfG hhsc6RGr7BdgidWx0JrWDLpBpAc6yBQmPtnc20WiqVOevtzzvykM5ihakXX6BghYXQNS XHuMRJmAzZBnJt1OqoXAOpK8ylwJC7JMZHFfvPqYLnJqQYLCasGRKswwuQh6yKakp29f hCYsBcXd6Gcaev0I0vGua+eLJ/t4KVJkcCHAcymM4z3Sb4oB53oMMmsnsAXMa9S/NAp6 i7dA== 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 :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject; bh=4msNSOA3EKtE+eaCnvE8BpCgwdYk03dUDCtiCnyb2N8=; b=bN7h0XzxGD04Qhmiz/Z5smJbWbViMjUKNKAGWbKJjO9kUYkqC+6SI+enrZACnByRo3 YRH0ePjlVfopPM19XwLYKW9EYjNaMjlJUAsLS3FVSBVX3rYnKp8kGtT/QEmDYHUTaVXZ vHh/zKpnYQztLhpaLBrdDW+p/OK5B7UQOgnRBPpCc8hrHKcMBsI4Dc6wzZxV9unwAsh9 nU/Y0l7MwWDkQI9lal/WSw2D9FK1Qnv//XdPcNklL9D9XkRYlMRFyXjjrfsBVGx44bnY +M5adLSppUfTF7j0RNfPbx0Ni8Wtc/u6dy8oRjxo6m+rJNAoOfnJgWaDen8u6U9Px1LW UDHg== 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 16si1919010otk.151.2019.12.11.08.46.24; Wed, 11 Dec 2019 08:46:36 -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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2387409AbfLKPtR (ORCPT + 99 others); Wed, 11 Dec 2019 10:49:17 -0500 Received: from mx2.suse.de ([195.135.220.15]:51652 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S2388678AbfLKPtO (ORCPT ); Wed, 11 Dec 2019 10:49:14 -0500 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 3E48CAFA9; Wed, 11 Dec 2019 15:49:12 +0000 (UTC) Subject: Re: [PATCH v1] xen-pciback: optionally allow interrupt enable flag writes To: =?UTF-8?Q?Marek_Marczykowski-G=c3=b3recki?= Cc: xen-devel@lists.xenproject.org, Ross Lagerwall , YueHaibing , Simon Gaiser , Stefano Stabellini , Boris Ostrovsky , Juergen Gross , open list References: <20191203054222.7966-1-marmarek@invisiblethingslab.com> From: Jan Beulich Message-ID: <17bf38dc-a606-bb92-50a8-9bd8f269acc2@suse.com> Date: Wed, 11 Dec 2019 16:49:29 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <20191203054222.7966-1-marmarek@invisiblethingslab.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 03.12.2019 06:41, Marek Marczykowski-Górecki wrote: > QEMU running in a stubdom needs to be able to set INTX_DISABLE, and the > MSI(-X) enable flags in the PCI config space. This adds an attribute > 'allow_interrupt_control' which when set for a PCI device allows writes > to this flag(s). The toolstack will need to set this for stubdoms. > When enabled, guest (stubdomain) will be allowed to set relevant enable > flags, but only one at a time - i.e. it refuses to enable more than one > of INTx, MSI, MSI-X at a time. > > This functionality is needed only for config space access done by device > model (stubdomain) serving a HVM with the actual PCI device. It is not > necessary and unsafe to enable direct access to those bits for PV domain > with the device attached. For PV domains, there are separate protocol > messages (XEN_PCI_OP_{enable,disable}_{msi,msix}) for this purpose. > Those ops in addition to setting enable bits, also configure MSI(-X) in > dom0 kernel - which is undesirable for PCI passthrough to HVM guests. > > This should not introduce any new security issues since a malicious > guest (or stubdom) can already generate MSIs through other ways, see > [1] page 8. True, albeit this doesn't cover INTX_DISABLE. > Additionally, when qemu runs in dom0, it already have direct > access to those bits. True again, but any bug here (as in: too wide exposure) is a qemu bug (possibly security issue). The statement also isn't really correct for de-privileged qemu, I think (but I also think PCI pass-through doesn't work in that mode at all yet). On the whole this looks to be an acceptable approach to me. But I'm not the maintainer, so my opinion may not count much. Some issues with the implementation itself were already pointed out. Jan