On Fri, Mar 23, 2018 at 08:38:57PM +0000, Tim Shearer wrote:
> > But port 0x80 should not be used if CONFIG_KVM_GUEST=y. What driver is
> > running in the guest, is it something that is distributed with CentOS?
> >
> > Also, I see that your trace has RIP values 0x483213 and 0x483215, can
> > you identify the corresponding source code?
> >
>
> Hi Paolo,
>
> I got a useful backtrace from the guest, which is running a packet forwarding app based on the DPDK (dpdk.org). The packet receive routine writes to 0xc070 using glibc's "outw_p" function which does an additional write to I/O port 80. Take a look at the assembly (from /usr/include/sys/io.h):
>
> outw_p (unsigned short int __value, unsigned short int __port)
> {
> __asm__ __volatile__ ("outw %w0,%w1\noutb %%al,$0x80": :"a" (__value),
> "Nd" (__port));
> }
>
> (It's irrelevant, but 0xc070 is the Virtio Ethernet device's base address (memory mapped via UIO), plus the "VIRTIO_PCI_QUEUE_NOTIFY" offset.)
>
> It does this write for every packet that's received, causing a flood of KVM userspace context switches. It appears that this implementation was completely rewritten and the ioport stuff removed by the 16.11 DPDK release, but, given the fact the project is six years old, there are likely to be many DPDK-based VNFs floating around that could potentially be impacted.
>
> How about I supersede the patch with one that disables the VMX IO port 0x80 passthrough by default (i.e. leaving the security fix in place), but allowing it to be enabled via a "port80_passthrough" module parameter?
That is certainly one way. But I would suggest you change it to allow a list of ports. So you
could do 80, 23, etc.. That way if there are other issues in the future we already have
the ways to fix this.
Also another fix is to just binarily patch that DPDK code. That is use objdump to find this 'outb %al,0x80' and patch
it over with 'nop'.
> Thanks,
> Tim
