[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH] Fix cpumap setting before passing to XEN

On Tue, Apr 26, 2016 at 11:54:32AM +0800, Zhenzhong Duan wrote:
> On 2016/4/25 21:26, Ian Jackson wrote:
> >Konrad Rzeszutek Wilk writes ("Re: [Xen-devel] [PATCH] Fix cpumap setting 
> >before passing to XEN"):
> >>On Wed, Apr 20, 2016 at 03:33:13PM +0100, Wei Liu wrote:
> >>>In principle I think having python binding and xl/libxl behave more or less
> >>>the same is the right direction. I'm a bit nervous about the change of
> >>>behaviour on the other hand.
> >>>
> >>>Let's wait for a few more days to see if other people have any comment on
> >>>this.
> >>Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx> ?
> >Does this bug report mean that `xm vcpu-pin ... all' has never
> >worked properly ?  Can that really be the case ?
> Xen 4.3 doesn't work, Xen 3.4 works.
> I have no Xen 4.4 around to test that, but checked code, it will not.
> Then I found below commit involved.
> commit 41abbadef60e5fccdfd688579dd458f7f7887cf5
> Author: Ian Jackson <ian.jackson@xxxxxxxxxxxxx>
> Date:   Wed May 29 15:48:11 2013 +0100
>     libxc: limit cpu values when setting vcpu affinity
>     When support for pinning more than 64 cpus was added, check for cpu
>     out-of-range values was removed. This can lead to subsequent
>     out-of-bounds cpumap array accesses in case the cpu number is higher
>     than the actual count.
>     This patch returns the check.
>     This is CVE-2013-2072 / XSA-56
>     Signed-off-by: Petr Matousek <pmatouse@xxxxxxxxxx>
> >
> >Also, xm exists in Xen 4.4 and earlier, only.  Xen 4.4 is no longer
> >supported upstream, so we would not apply this patch to Xen 4.4.  So
> >whatever we do, this is not going to fix any bug in `xm vcpu-pin' in
> >4.4.
> The only impact is upper layer or the user need to pass a correct cpumap
> param not beyond the real cpu map to avoid the error.
> But I am not clear if python binding is still used or will be removed just
> as Xend.

I don't think we have plan to remove it any time soon. On the other hand
because no in-tree component uses it so we don't know whether it works
in practice or not.

> >
> >This doesn't necessarily mean that I object to changing the behaviour
> >of the python xc module in still-supported Xen releases.  But I'm not
> >sure the reasoning behind the behaviour of the libxl bitmap functions
> >applies to the Python interface.
> >
> >Zhenzhong Duan, are you using an out-of-tree copy of xm and xend ?
> I am using xen-4.3.0-55.el6.47.33 which is Xen 4.3 variant

So what is the conclusion of this discussion so far? I admit I'm a bit
lost here.


> thanks
> zduan

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.