On Thu, May 07, 2015 at 02:12:07PM +0200, David Borman wrote:
> Am 5/7/2015 um 11:23 AM schrieb Stefan Hajnoczi:
> >The network stack is very flexible, so many configurations are possible.
> >
> >A popular bridged Ethernet configuration is:
> >
> >guest <-> vhost_net.ko <-> tap <-> software bridge <-> eth0
> >
> >The flow is:
> >1. Packet is received on physical eth0
> OK
> >2. Packet is given to software bridge and the destination MAC address is
> > used to determine the bridge port for forwarding.
> Is the layer 2 bridge design a fully IEEE 802.1D standard compliant
> implementation?
I don't know. It's the standard Linux software bridging code which
lives in net/bridge/.
> >3. Packet is forwarded to the tap device on the host that is associated
> > with the guest.
> Can you describe this step with a bit more details?
This is still the Linux software bridging code.
I realize that the sentence is a bit confusing. Remove "on the host"
and it should be clearer. That just meant this is happening in the host
kernel (Linux's software bridging code).
And the bridge knows which bridge port to forward the packet to based on
the destination MAC address (see Step 3).
> >4. vhost_net reads the packet from the tap device into guest memory and
> > then signals the guest.
> How can the external host process (where vhost_net is part of) write into a
> emulated Guest RAM Memory at all?
> Or is this a BIOS or Ethernet Firmware specific task
The host has full access to the contents of guest memory.
A bit more detail: the vhost_net kernel module has access to the
userspace memory ranges where guest memory lives (this is set up by the
QEMU userspace process). This is necessary so it can receive packets
into the virtio-net rx ring (the buffers live in guest memory).
The code for this is drivers/vhost/{net.c,vhost.c}.
> >5. Guest notices the received packet and its virtio_net driver hands the
> > packet to the guest network stack.
> What is the event or callback inside the "Guest" who react on this
> notfification? it must something outside the guest os, right?
The vhost_net.ko module signals an eventfd file descriptor which has
been registered with the kvm.ko module as an irqfd. irqfd means that
writes to the file descriptor inject interrupts into the guest.
So vhost_net causes the interrupt to be injected. The guest runs the
interrupt handler just like a physical machine handling interrupts.
The mechanism is in arch/x86/kvm/ and you can read the Intel/AMD manuals
to learn about how injecting interrupts into guests works.
> >If the guest relies on its own firewall then packets are transferred
> >into the guest. Once they are inside the guest the host no longer cares
> >about them and they are in guest memory. Whether or not the guest
> >decides to drop them makes no difference to the host.
> Hmm, is there a possible callback or api feature where a host c programm can
> communicate with the Host OS/KVM extensions, forcing the host
> firewall to drop the packet earlier on host level?
Sure, the host can install firewall rules to drop packets before they
would be forwarded to the guest. This is not KVM-specific, it's
standard Linux netfilter usage.
> Can someone craft a dos/ddos attack against the host at all and is this
> allready a common problem?
> More specific: What happends if someone targets a running KVM guest os (a
> ordinary KVM-vServer at some ISP) with lots of packets, flooding the
> Host/Guest databuffers at
> the L2 Bridgelevel with random crap data? Are there some underrun/overrun
> checks to avoid such situations or is the hypervisor taking steps to
> mitigate something like this?
Packets get dropped at both host and guest levels if queue sizes or
memory are exhausted.
From the virtualization angle, the limited resource is the virtio-net rx
ring, which has a finite size. If the ring is exhausted then vhost_net
stops attempting to receive data from the tap device. This causes the
tap device rx queue to fill up and eventually drop packets.
Plus there are the other components like the bridge and physical
interfaces. All of these are standard Linux networking objects.
Stefan
Attachment:
pgpdCqWm8fYaN.pgp
Description: PGP signature
