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

Re: [PATCH v2 1/5] x86/pmstat: Check size of PMSTAT_get_pxstat buffers



On Tue, May 13, 2025 at 3:27 PM Jan Beulich <jbeulich@xxxxxxxx> wrote:
>
> On 12.05.2025 16:46, Ross Lagerwall wrote:
> > Check that the total number of states passed in and hence the size of
> > buffers is sufficient to avoid writing more than the caller has
> > allocated.
> >
> > The interface is not explicit about whether getpx.total is expected to
> > be set by the caller in this case but since it is always set in
> > libxenctrl it seems reasonable to check it.
>
> Yet if we start checking the value, I think the public header should also
> be made say so (in a comment).
>
> > --- a/xen/drivers/acpi/pmstat.c
> > +++ b/xen/drivers/acpi/pmstat.c
> > @@ -103,8 +103,10 @@ int do_get_pm_info(struct xen_sysctl_get_pmstat *op)
> >
> >          cpufreq_residency_update(op->cpuid, pxpt->u.cur);
> >
> > -        ct = pmpt->perf.state_count;
> > -        if ( copy_to_guest(op->u.getpx.trans_pt, pxpt->u.trans_pt, ct*ct) )
> > +        ct = min_t(uint32_t, pmpt->perf.state_count, op->u.getpx.total);
>
> With this, ...
>
> > +        if ( ct <= op->u.getpx.total &&
>
> ... this is going to be always true, isn't it? Which constitutes a violation
> of Misra rule 14.3.
>
> Also it would be nice if the min_t() could become a normal min(), e.g. by
> "promoting" op->u.getpx.total to unsigned int via adding 0U. This way it's
> clear there's no hidden truncation (or else there might be an argument for
> keeping the check above).
>
> > +             copy_to_guest(op->u.getpx.trans_pt, pxpt->u.trans_pt, ct * 
> > ct) )
> >          {
> >              spin_unlock(cpufreq_statistic_lock);
> >              ret = -EFAULT;
>
> Why would you constrain this copy-out but not the one just out of context
> below here? (The question is of course moot if the condition was dropped.)
>

Oh, I had intended this condition to be...

    if ( ct == op->u.getpx.total &&

... based on your previous comment about the difficulties of partially
copying a 2d array.

> An option may be to document that this array is copied only when the
> buffer is large enough.

I left the other alone since partially copying a 1d array makes sense.

If you would prefer, I can drop the condition and just let the caller
deal with the partially copied 2d array?

Thanks,
Ross



 


Rackspace

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