From: Wei Liu <wei.liu2@citrix.com>
To: "Wu, Feng" <feng.wu@intel.com>
Cc: "Tian, Kevin" <kevin.tian@intel.com>,
Wei Liu <wei.liu2@citrix.com>,
George Dunlap <george.dunlap@eu.citrix.com>,
"andrew.cooper3@citrix.com" <andrew.cooper3@citrix.com>,
"Wang, Yong Y" <yong.y.wang@intel.com>,
"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
Jan Beulich <JBeulich@suse.com>,
"Zhang, Yang Z" <yang.z.zhang@intel.com>
Subject: Re: Requesting for freeze exception for VT-d posted-interrupts
Date: Fri, 17 Jul 2015 10:28:39 +0100 [thread overview]
Message-ID: <20150717092839.GH12455@zion.uk.xensource.com> (raw)
In-Reply-To: <E959C4978C3B6342920538CF579893F002615D93@SHSMSX104.ccr.corp.intel.com>
On Wed, Jul 15, 2015 at 10:48:31PM +0000, Wu, Feng wrote:
>
>
> > -----Original Message-----
> > From: Wei Liu [mailto:wei.liu2@citrix.com]
> > Sent: Wednesday, July 15, 2015 11:47 PM
> > To: Jan Beulich
> > Cc: Wei Liu; andrew.cooper3@citrix.com; George Dunlap; Wu, Feng; Tian, Kevin;
> > Zhang, Yang Z; Wang, Yong Y; xen-devel@lists.xen.org
> > 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@citrix.com> wrote:
> > > > On Tue, Jul 14, 2015 at 03:46:46PM +0100, Jan Beulich wrote:
> > > >> >>> On 14.07.15 at 16:17, <wei.liu2@citrix.com> wrote:
> > > >> > On Tue, Jul 14, 2015 at 11:09:15AM +0100, Jan Beulich wrote:
> > > >> >> >>> On 14.07.15 at 11:21, <wei.liu2@citrix.com> 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.
>
I haven't seen a new version that has all comments addressed, so I'm
sorry to say this feature is going to miss 4.6.
Do keep up with your good work and make it happen in 4.7.
Wei.
> Thanks,
> Feng
>
> >
> > Wei.
> >
> > > Jan
next prev parent reply other threads:[~2015-07-17 9:28 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-13 6:55 Requesting for freeze exception for VT-d posted-interrupts Wu, Feng
2015-07-13 9:05 ` Jan Beulich
2015-07-13 11:00 ` Wei Liu
2015-07-14 5:51 ` Wu, Feng
2015-07-14 9:21 ` Wei Liu
2015-07-14 10:09 ` Jan Beulich
2015-07-14 14:17 ` Wei Liu
2015-07-14 14:46 ` Jan Beulich
2015-07-14 15:02 ` Wei Liu
2015-07-14 16:01 ` Jan Beulich
2015-07-15 15:46 ` Wei Liu
2015-07-15 22:48 ` Wu, Feng
2015-07-17 9:28 ` Wei Liu [this message]
2015-07-13 15:38 ` Dario Faggioli
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150717092839.GH12455@zion.uk.xensource.com \
--to=wei.liu2@citrix.com \
--cc=JBeulich@suse.com \
--cc=andrew.cooper3@citrix.com \
--cc=feng.wu@intel.com \
--cc=george.dunlap@eu.citrix.com \
--cc=kevin.tian@intel.com \
--cc=xen-devel@lists.xen.org \
--cc=yang.z.zhang@intel.com \
--cc=yong.y.wang@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.