From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jan Beulich" Subject: Re: Requesting for freeze exception for VT-d posted-interrupts Date: Tue, 14 Jul 2015 17:01:33 +0100 Message-ID: <55A54E7D0200007800090E1D@mail.emea.novell.com> References: <20150713110041.GD4108@zion.uk.xensource.com> <20150714092158.GB4152@zion.uk.xensource.com> <55A4FBEB020000780009090C@mail.emea.novell.com> <20150714141740.GJ4152@zion.uk.xensource.com> <55A53CF60200007800090D1C@mail.emea.novell.com> <20150714150258.GO4152@zion.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20150714150258.GO4152@zion.uk.xensource.com> Content-Disposition: inline List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Wei Liu Cc: Kevin Tian , Feng Wu , George Dunlap , "andrew.cooper3@citrix.com" , Yong Y Wang , "xen-devel@lists.xen.org" , Yang Z Zhang List-Id: xen-devel@lists.xenproject.org >>> On 14.07.15 at 17:02, wrote: > On Tue, Jul 14, 2015 at 03:46:46PM +0100, Jan Beulich wrote: >> >>> On 14.07.15 at 16:17, wrote: >> > On Tue, Jul 14, 2015 at 11:09:15AM +0100, Jan Beulich wrote: >> >> >>> On 14.07.15 at 11:21, wrote: >> >> > On Tue, Jul 14, 2015 at 05:51:02AM +0000, Wu, Feng wrote: >> >> >> Is it possible to get to 4.6 if making this feature default off? >> >> > >> >> > Note that I'm not the only one who makes the decision and I can't speak >> >> > for maintainers. The first thing you ought to do is to convince >> >> > maintainers, not me. >> >> > >> >> > If you ask for my opinion -- I don't see a point in releasing feature >> >> > with security flaw in design, even if it is off by default. >> >> >> >> It was actually me who suggested that by flagging this experimental >> >> and defaulting it to off, chances would increase for this to be allowed >> >> in without said issue fixed. >> > >> > Are you satisfied with that? Currently I only know from this email >> > there is concern with regard to security but I don't know what it is and >> > how big an impact it can possibly have. >> > >> > I could maybe go dig up that series and try to understand what is the >> > security implication, but it would take a long time and I'm not sure I >> > have the right technical background to make the call. >> >> The thing is that the way vCPU-s are being put on lists attached to >> pCPU-s, in a pathological case (which can be "helped" by a malicious >> tool stack) all vCPU-s could pile up on one such list. List traversal (in >> an interrupt handler) could then take (almost) arbitrarily long. > > You mentioned "malicious toolstack", does that mean this feature, if on, > doesn't expose new attack vector to malicious guest? I think getting a guest to affect this would be more involved, but I can't entirely exclude it. > And what do you mean by "malicious toolstack"? I don't see patches > related to toolstack. This is because the tool stack can control placement of vCPU-s on pCPU-s, not because new tool stack code is being added. Jan