Re: [Xen-devel] [PATCH v5 12/17] xen/libxc: sched: DOMCTL_*vcpuaffinity works with hard and soft affinity

[George Dunlap <george.dunlap@xxxxxxxxxxxxx>]

On 12/03/2013 10:06 AM, Jan Beulich wrote:
> > > > On 03.12.13 at 11:02, "Jan Beulich" <JBeulich@xxxxxxxx> wrote:
> > > > > On 02.12.13 at 19:29, Dario Faggioli <dario.faggioli@xxxxxxxxxx> wrote:
> > > +                goto setvcpuaffinity_out;
> > > +
> > > +            /*
> > > +             * We both set a new affinity and report back to the caller what
> > > +             * the scheduler will be effectively using.
> > > +             */
> > > +            if ( vcpuaff->flags & XEN_VCPUAFFINITY_HARD )
> > > +            {
> > > +                ret = xenctl_bitmap_to_bitmap(cpumask_bits(new_affinity),
> > > +                                              &vcpuaff->cpumap_hard,
> > > +                                              vcpuaff->cpumap_hard.nr_bits);
> > There's no code above range checking vcpuaff->cpumap_hard.nr_bits,
> > yet xenctl_bitmap_to_bitmap() uses the passed in value to write into
> > the array pointed to by the first argument. Why is this not
> > xenctl_bitmap_to_cpumask() in the first place?
> And just to make it explicit - with fundamental flaws like this, I'm
> not certain anymore whether we really ought to rush this series
> in for 4.4.
I'm certainly getting nervous about the prospect.  However, the above 
bug would only be triggered by bad input from domain 0, right? I suppose 
even that would be a potential security issue in a highly disaggregated 
environment.
Other bugs in this patch would be similar.  This path is taken on domain 
creation IIUC; so bugs in this particular patch would probably either be 
unexpected behavior of the affinities, or failure to handle unusual 
input from a trusted source (domain 0).
 -George

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