Thanks Stefan.
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?
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?
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
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?
All of these components can be swapped out: software bridge vs
OpenVSwitch, software bridge vs macvtap, vhost_net vs NIC emulation in
QEMU, bridging vs NAT, etc. If you are just learning about this, focus
on the one configuration you care about and ignore all others for now.
Iam a c guy myself and iam just curious and trying to figure out how the
flow is implemented, so iam obsessed with details and specs ;d
You can use firewall rules on the host on any of the 3 network
interfaces (physical eth0, software bridge interface, or tap). If the
packets are dropped by the host then the guest will not see them.
OK.
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?
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?
Cheers,
David
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
