Skip to main content

Virtual Networking

Introduction​

Network setup has two distinct meanings when applied to Corellium Applications. First, is how the various compute and server nodes that combine form the application are networked together which is documented in Networking. Second, how the virtual network or networks created by the application operate and are managed which is documented here.

Overview​

Virtual Networking, or how virtual hardware devices are networked together, in the Corellium application is based on the Project. Each project defines a network at both layer 2 and layer 3. Each project defines a Linux Kernel bridge to which all virtual hardware devices are connected thus defining a layer 2 network. More relevantly to most users the configuration of project defines which DHCP server responds to the Virtual Hardware on boot, thus defining a layer 3 network. The net result is that for most users the Project can be though of as a layer 3 network configured as per Managing Projects. For users with more demanding requirements on networking see the Implementation Details section below.

Communications between the project network, other project networks, other networks, and the internet are controlled by the networking mode of the application in Networking. The three fundamental networking models define that:

  • In NAT Mode - The default for public cloud installs.
    • There is no connection from one Project network to another Project network
    • Individual VMs can reach any networks the host is connected to via host NAT.
    • External devices cannot access any project network unless specifically configured via:
      • Per VM port-forwarding
      • Per Project VPN connection
  • In Bridged Mode - The default for on prem installs.
    • All project networks are bridged into a single layer 3 network.
    • All project networks are bridged to the host's layer 3 network.
    • Only non routable addresses are filtered.
  • In Routed Mode - The default for disconnected operation.
    • Each project network is independent of all other networks.
    • No outbound access from the project network unless routes are manually added.
    • No inbound access to hte project network other than from the compute node unless configured.

Implementation Details​

warning

This description assumes familiarity with Linux Kernel Routing as defined and configured using the iproute2 package, see the manpage or HOWTO or Advanced HOWTO for a deep dive.

Iproute2 commands can easily move your application outside of a supported configuration. Further any and all changes implemented using the iproute2 suite of commands are likely to break the Corellium application to the pont of needing a power cycle to recover and are likely to be visible to your corporate network administrator. As such we recommend checking twice before hitting return to the same degree that you would on a corporate router.

Virtual Hardware Representation​

For purposes of virtual networking each virtual hardware device is represented in Dom0 by 3 or more elements. The service node is represented by a Linux Kernel Network bridge created with /sbin/brctl addbr cinst-#-br where the number assigned sequentially as virtual hardware are created. Numbers are reused as hardware is deleted. The primary wireless interface of the virtual hardware is represented by /dev/chiw# and the primary wired by /dev/chie#. By default the number of these interfaces are the same as the number of the cinst. The chi devices are statically allocated at install time and match the number of available devices in project configuration. The chi devices are moved into the netns of the project and the cinst is allocated when the virtual hardware is created. Additionally a veth pair is created using /sbin/ip netns exec <netns> /sbin/ip link add cinst-<#>-x type veth peer name cinst-<#>-y to connect the cinst bridge to the project bridge.

The DHCP server is consulted for addresses. Assuming the server has been configured to use internal addresses of the form X.Y.Z.Q/16, the first virtual hardware allocated to a project will be allocated address X.Y.Z+1.1/16 for the cinst-0-br (service node) and X.Y.Z.1/16 for the wireless interface chiw0, if a wired interface X.Y.Z.2/16 for the ethernet chie0 interface. The second virtual hardware device created in the project will get the next sequential final octet or octets. If the address space is not a /16 or larger smaller netmask will be assigned, once the size drops below /22 the cinst and chi addresses will be interleaved sequentially. When configured for NAT mode all projects will allocate from the same X.Y.Z, in bridged and routed modes projects will increment the third octet, the X.Y.Z., thus the service nodes will be X.Y.X.Z+3 and the chi devices X.Y.Z+2 and so on.

When an OS running on the target requests an address from DHCP it will receive the address previously allocated for the relevant chi device.

Project Representation​

Each project is represented in Dom0 by a network namespace created with /sbin/ip netns add corellium-project-<UUID> inside of which is a Linux Kernel Network bridge, the "project bridge" mentioned above. This bridge links all the instance bridges in the project to form a logical network. The instance bridge also serves as the DHCP server, the network gateway, or both for the instances in the project depending on the network mode of the Corellium Application.

Representation of Network Modes​

The most complex part of the virtual network configuration is how the projects interact with each other and/or the outside world. In Bridge and NAT modes each project bridge is connected via a veth pair to per project bridges in the global name space. In Bridge mode these external bridges are then bridged together with the physical interface of the host. In routed mode the kernel is configured to drop all traffic between external bridges and the physical interface unless the user explicitly creates routes. NAT mode is rather different in that it creates an integration bridge that is connected via IP masquerading to the physical interface but instead of per project external bridges, the integration bridge is represented in each project by a veth pair and kernel routing is configured inside of the project to route between the project bridge and the veth end point.

Bridge Mode Networking​

Bridge Mode Networking

Routed Mode Networking​

Routed Mode Networking

NAT Mode Networking​

NAT Mode Networking

Implications for Custom IP Addressing​

For most users all of the detail is irrelevant. Many customer will simply use the defaults and never search for this page. Some customers require custom IP ranges to build out a second network. For example some automotive applications will statically map IP addresses to zones in the car. In this case a project can be used to represent the car and the ECUs will be able to communicate as if connected in the vehicle. In cases where allocating the virtual ECUs in the right order to match up with the DHCP assigned addresses is difficult the fact that the project is configured with kernel bridges can be leveraged for custom network configuration. Specifically if the vehicle addressing uses a different subnet than the project, simply statically assign the addresses as per the vehicle specification and the bridge will happy transport the packets within the network. Note that may make mapping from Service Node IP address to vehicle address more difficult. Complete control and flexibility is required see the Ethernet over CoreModel support in the CoreModel Library.