[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. Wei. > thanks > zduan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |