Re: [Xen-devel] Requesting for freeze exception for VT-d posted-interrupts

["Wu, Feng" <feng.wu@xxxxxxxxx>]

> -----Original Message-----
> From: Wei Liu [mailto:wei.liu2@xxxxxxxxxx]
> Sent: Wednesday, July 15, 2015 11:47 PM
> To: Jan Beulich
> Cc: Wei Liu; andrew.cooper3@xxxxxxxxxx; George Dunlap; Wu, Feng; Tian, Kevin;
> Zhang, Yang Z; Wang, Yong Y; xen-devel@xxxxxxxxxxxxx
> Subject: Re: Requesting for freeze exception for VT-d posted-interrupts
> 
> On Tue, Jul 14, 2015 at 05:01:33PM +0100, Jan Beulich wrote:
> > >>> On 14.07.15 at 17:02, <wei.liu2@xxxxxxxxxx> wrote:
> > > On Tue, Jul 14, 2015 at 03:46:46PM +0100, Jan Beulich wrote:
> > >> >>> On 14.07.15 at 16:17, <wei.liu2@xxxxxxxxxx> wrote:
> > >> > On Tue, Jul 14, 2015 at 11:09:15AM +0100, Jan Beulich wrote:
> > >> >> >>> On 14.07.15 at 11:21, <wei.liu2@xxxxxxxxxx> 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.
> >
> 
> I fished out the thread and tried my best to digest that.
> 
> It does seem that it requires tool stack help to pin too many vcpus to a
> pcpu to trigger a problem.  Another possibility I can think of is that
> the scheduler piling too many vcpus on one pcpu.
> 
> All in all, neither of the above two approaches can be used directly by
> a malicious guest, so the concern with regard to security is not as big
> as I thought.
> 
> Jan, I agree with you this feature should be marked as experimental if
> we are to merge it for 4.6.
> 
> Wu, note the decision has not been made because the patch series is not
> in shape yet, in theory you do have time to address all issues by
> Friday if you want to try. I will revisit this on Friday.

Wei, Thanks a lot for your analysis, I will try my best to address the issues
before Friday.

Thanks,
Feng

> 
> Wei.
> 
> > Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel