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 15:46:46 +0100 Message-ID: <55A53CF60200007800090D1C@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> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20150714141740.GJ4152@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 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. Otoh one wouldn't expect lists to grow too large on well behaved, properly operating systems. And hence for the sake of experimenting with the feature or even using it in known well behaved production environments it would seem reasonable to allow the feature to be there. Jan