Re: [PATCH 09/12] kvm-all: introduce limits for name_size and num_desc

[Vladimir Sementsov-Ogievskiy]

On 26.09.23 14:05, Peter Maydell wrote:
> On Mon, 25 Sept 2023 at 20:43, Vladimir Sementsov-Ogievskiy
> <vsementsov@yandex-team.ru> wrote:
> > Coverity doesn't like when the value with unchecked bounds that comes
> > from fd is used as length for IO or allocation. And really, that's not
> > a good practice. Let's introduce at least an empirical limits for these
> > values.
> >
> > Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru>
> > ---
> >   accel/kvm/kvm-all.c | 15 +++++++++++++++
> >   1 file changed, 15 insertions(+)
> >
> > diff --git a/accel/kvm/kvm-all.c b/accel/kvm/kvm-all.c
> > index ff1578bb32..6d0ba7d900 100644
> > --- a/accel/kvm/kvm-all.c
> > +++ b/accel/kvm/kvm-all.c
> > @@ -3988,6 +3988,9 @@ typedef struct StatsDescriptors {
> >   static QTAILQ_HEAD(, StatsDescriptors) stats_descriptors =
> >       QTAILQ_HEAD_INITIALIZER(stats_descriptors);
> >
> > +
> > +#define KVM_STATS_QEMU_MAX_NAME_SIZE (1024 * 1024)
> > +#define KVM_STATS_QEMU_MAX_NUM_DESC (1024)
>
> These seem arbitrary. Why these values in particular?
> Does the kernel have any limitation on the values it passes us?

Documentation doesn't say about limits

> Do we have any particular limit on what we can handle?

Hmm. At least, we don't arithmetic operations with these values to overflow. 
But in this case g_malloc0_n should crash anyway.

So we may rely on g_malloc0_n as on assertion that the values are good enough 
and further doubts are false-positives. Will drop this patch.

--
Best regards,
Vladimir