From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cooper Subject: Re: [PATCH v3 10/10] x86/MSI-X: provide hypercall interface for mask-all control Date: Thu, 11 Jun 2015 10:51:57 +0100 Message-ID: <55795A3D.7060304@citrix.com> References: <55719F9D0200007800081425@mail.emea.novell.com> <5571A3F202000078000814CA@mail.emea.novell.com> <557964870200007800083706@mail.emea.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Z2z9b-0007ps-Vq for xen-devel@lists.xenproject.org; Thu, 11 Jun 2015 09:52:08 +0000 In-Reply-To: <557964870200007800083706@mail.emea.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich , Roger Pau Monne , Wei Liu , Ian Campbell , Ian Jackson , Stefano Stabellini , Konrad Rzeszutek Wilk Cc: xen-devel , dgdegra@tycho.nsa.gov, Keir Fraser List-Id: xen-devel@lists.xenproject.org On 11/06/15 09:35, Jan Beulich wrote: >>>> On 05.06.15 at 13:28, wrote: >> Qemu shouldn't be fiddling with this bit directly, as the hypervisor >> may (and now does) use it for its own purposes. Provide it with a >> replacement interface, allowing the hypervisor to track host and guest >> masking intentions independently (clearing the bit only when both want >> it clear). > Originally I merely meant to ping the tools side changes here > (considering that the original issue has been pending for months, > delayed by various security issues as well as slow turnaround on > understanding the nature and validity of that original issue, I'd > _really_ like to see this go in now), but thinking about it once > again over night I realized that what we do here to allow qemu > to be fixed would then also be made use of by the kernels > running pciback: While Dom0 fiddling with the MSI-X mask-all bit > for its own purposes is at least not a security problem, it doing > so on behalf of (and directed by) a guest would be as soon as > the hypervisor side patches making use of that bit went in. > > While I continue to be of the opinion that all direct writes to > interrupt masking bits (MSI-X mask-all, MSI-X per-entry mask, > MSI per entry mask) outside of the hypervisor are wrong and > should be eliminated, the scope of the problem now clearly > going beyond qemu made me reconsider whether we shouldn't, > as advocated by Stefano, follow the trap-and-emulate route > instead. This would not only mean adding code to x86's existing > port CF8/CFC intercepts, but also write-protecting the MMCFG > pages for all PCI devices being MSI or MSI-X capable, emulating > writes with inspection / modification of writes to any of the mask > bits located in PCI config space. (A subsequent optimization to > this may then be a hypercall to do config space writes, > eliminating the emulation overhead, accompanied by a bitmap > indicating which devices' CFG space can be written directly.) > > For a (from now on) timely resolution of the original problem I'd > really appreciate opinions (or alternative suggestions). A very definite +1 from me. I have previously suggested as much. ~Andrew