On 2/7/19 8:30 PM, Peter Maydell wrote: > Currently QEMU has 9 uses of variable length arrays > (found using -Wvla): > > hw/block/dataplane/virtio-blk.c:62:25: warning: variable length array > used [-Wvla] > unsigned long bitmap[BITS_TO_LONGS(nvqs)]; > ^ > hw/i386/multiboot.c:364:18: warning: variable length array used [-Wvla] > char kcmdline[strlen(kernel_filename) + strlen(kernel_cmdline) + 2]; > ^ > hw/i386/xen/xen-hvm.c:618:25: warning: variable length array used [-Wvla] > unsigned long bitmap[DIV_ROUND_UP(npages, width)]; > ^ > hw/intc/xics.c:604:18: warning: variable length array used [-Wvla] > uint8_t flags[ics->nr_irqs]; > ^ > hw/net/fsl_etsec/rings.c:383:18: warning: variable length array used [-Wvla] > uint8_t padd[etsec->rx_padding]; > ^ > hw/ppc/pnv.c:130:26: warning: variable length array used [-Wvla] > uint32_t servers_prop[smt_threads]; > ^ > hw/ppc/spapr.c:162:26: warning: variable length array used [-Wvla] > uint32_t servers_prop[smt_threads]; > ^ > hw/ppc/spapr.c:163:27: warning: variable length array used [-Wvla] > uint32_t gservers_prop[smt_threads * 2]; > ^ > linux-user/syscall.c:3478:23: warning: variable length array used [-Wvla] > struct sembuf sops[nsops]; > ^ > > Should we be looking to get rid of these and turn on the -Wvla > warning? I know the Linux kernel has recently decided to do this
Yes please! > (some rationale at the start of https://lwn.net/Articles/749064/). > Now that doesn't necessarily apply to us as a userspace program, > but on the other hand if any of these were allowing the guest to > determine the size of an on-stack array that would not be great. > (The linux-user one is bogus in that way, though not a security issue > as the guest code there has full control anyway.) The manpage says "[The semaphore] limit should not be raised above 1000". > > Opinions? I admit that to some extent this is just my sense of > tidiness thinking that if we only have a handful of uses of > something we should squash that down to zero :-) None of these case have strong justification to use the stack rather than the heap (and the rest of the codebase heavily uses the heap). > > thanks > -- PMM >
