From VirtualSquare

UMview is essentially a System Call Virtual Machine. To accomplish its job to start a process within system call virtualization something like a Virtual Machine Monitor have to be between process looking for a new view of the underlying system and the operating system itself.

UMview is made of several tools that will be explained below.

Contents 1 Basic commands 1.1 umview 1.2 um_add_service 1.3 um_del_service 1.4 um_ls_service 1.5 um_lock_service 1.6 um_mov_service 2 Modules 2.1 lwipv6 2.1.1 Virtual interfaces creation 2.1.1.1 VDE network interface 2.1.1.2 Virtual Ethernet interface 2.1.1.3 Virtual IP point-to-point interface 2.2 umbinfmt 2.3 umdev 2.3.1 umdevmbr 2.3.2 umdevramdisk 2.3.3 umdevtap 2.3.4 UMdev test submodules 2.3.4.1 umdevnull 2.3.4.2 umdevtrivhd 2.4 umfuse 2.4.1 Overview 2.4.2 Usage 2.5 viewfs

[edit] Basic commands

[edit] umview

It is used to start a new command (passed as argument with it own additional optional arguments). Once started if there's not any module loaded it behaves like executing outside umview. When starting a non-interactive shell program within umview it may be useful to preload modules.

$ umview bash

• module preloading

preloaded modules can be specified with command line argument umview -p modulename[,param1,...,paramN]

$ umview -p lwipv6.so,vd0=/var/run/vde.ctl bash

• kernel optimization and additional features

Features like kernel optimization or module nesting are autodetected and enabled by default when available. It may be useful for debugging reasons to disable one or more of this options with flag parameters passed to umview.

• disable modules nesting

$ umview -x bash

• disable all kernel extensions

$ umview -n bash

• disable PTRACE_MULTI kernel extension

$ umview --nokmulti bash

• disable PTRACE_SYSVM kernel extension

$ umview --nokvm bash

• debugging

If umview was compiled with debugging symbols enabled it is possible to redirect all the debugging output to a file specified in the command line.

$ umview -o debugging_file.txt bash

[edit] um_add_service

Adds the specified service module to the umview chain of services. It must be run from the process launched within umview, so it permits to load a service module during execution inside umview.

$ um_add_service lwipv6.so,vd0=/var/run/vde.tmp

As additional option it is possible to specify the exact position of the module being loaded in the umview chain. This permits to choose the order followed by system call interception between service modules.

[edit] um_del_service

Removes the specified service module from umview chain. The service module to be removed can be specified by its position in the chain or by its hexadecimal signature.

$ um_ls_service
um_service 1  code 04 name "umdev"
um_service 2  code 01 name "umfuse fuse"

$ um_del_service -p 1    #  umdev service removed by position
$ um_del_service -c 01   # umfuse service removed by signature

[edit] um_ls_service

This command gives a list of the currently loaded umview service modules.

$ um_ls_service
um_service 1  code 04 name "umdev"
um_service 2  code 01 name "umfuse fuse"
um_service 3  code 02 name "light weight ipv6 stack"

[edit] um_lock_service

Disables loading and unloading of modules. It also permits to lock-and-hide currently loaded modules. In this way it is not possible to see which service modules are loaded.

$ um_ls_service
um_service 1  code 04 name "umdev"
um_service 2  code 01 name "umfuse fuse"
um_service 3  code 02 name "light weight ipv6 stack"

$ um_lock_service
$ um_add_service umbinfmt
umbinfmt init
umbinfmt fini
um_add_service: Bad address

$ um_del_service -p 1
um_del_service: Function not implemented

$ um_lock_service -i
um_list_service: Function not implemented

[edit] um_mov_service

To change the order of forwarding of system calls between service modules it is possible to move services up and down within the umview chain of modules. By default the order in which system calls are processed by modules is the same displayed by um_ls_service.

$ um_ls_service
um_service 1  code f9 name "Identity (server side)"
um_service 2  code fe name "/unreal Mapping to FS (server side)"
um_service 3  code 04 name "umdev"
um_service 4  code 02 name "light weight ipv6 stack"

$ um_mov_service -p 4 1

$ um_ls_service 
um_service 1  code 02 name "light weight ipv6 stack"
um_service 2  code f9 name "Identity (server side)"
um_service 3  code fe name "/unreal Mapping to FS (server side)"
um_service 4  code 04 name "umdev"

[edit] Modules

Modules are like shared objects so needs to be loaded by umview like any other dynamic library. The path where umview modules reside should be added to ld.so cache or declared as shell environment variable LD_LIBRARY_PATH.

[edit] lwipv6

This service module realizes the interface between UMview and the Light Weight IPv6 stack. Once loaded into UMview every call that would go to the kernel networking stack is redirected to a virtual stack. In this way the process run within UMview has its own view of the network.

Since all the networking is managed by a user-level implemented stack it is possible to create new network virtual interfaces, assign different IP addresses, different routing rules. Such a local network stack behaves in a totally transparent way and thus usually networking applications like browsers, mail readers, and so on run within UMview without any modification.

[edit] Virtual interfaces creation

The virtual interfaces must be created during module initialization. They have to be stated via special service module parameters. Currently there are three types of virtual network interfaces supported. Usage with UMview within lwipv6 module is explained in detail in the following subsections.

IP addresses and routing can not be set with ifconfig or route commands since the rely on /proc filesystem instead of [AF_NETLINK] sockets for network configuration.

[edit] VDE network interface

VDE network interfaces can be created with both specifying or not the control socket of a vde_switch.

$ um_add_service lwipv6.so,vd0    # creates a new vde network interfaces connected to the standard vde_switch socket

Specifying as module parameter the interface name in the format vdn n will be the number of vde network interfaces that will be created and connected to the default vde_switch control socket.

$ um_add_service lwipv6.so,vd3

$ ip link show
1: lo0: <LOOPBACK,UP> mtu 0 
    link/loopback 
2: vd0: <BROADCAST> mtu 1500 
    link/ether 02:02:1e:20:0b:06 brd ff:ff:ff:ff:ff:ff
3: vd1: <BROADCAST> mtu 1500 
    link/ether 02:02:78:df:d4:06 brd ff:ff:ff:ff:ff:ff
4: vd2: <BROADCAST> mtu 1500 
    link/ether 02:02:4c:52:70:06 brd ff:ff:ff:ff:ff:ff

It is also possible to specify the desired control socket of a vde_switch to connect the virtual interface to.

$ um_add_service lwipv6.so,vd0=/some/vde_switch/control/socket/vde.ctl

[edit] Virtual Ethernet interface

The creation of virtual ethernet interfaces (called tap interfaces in Linux) results in the creation of tap interfaces both inside and outside UMview. This two interfaces created are connected together and represent another way of communicating between real and partially virtualized environments.

As for other virtual network interfaces in UMview they have to be created at service module loading instance. Again, specifying tpn as module parameter will create n tap interfaces within UMview.

$ um_add_service lwipv6.so,tp1

$ ip link show
1: lo0: <LOOPBACK,UP> mtu 0 
    link/loopback 
2: tp0: <BROADCAST> mtu 1500 
    link/ether 02:02:03:04:05:06 brd ff:ff:ff:ff:ff:ff

Let's have a look outside UMview. We'll see that a new tap interface have been created outside the partially virtualized environment.

$ ip link show
1: lo: <LOOPBACK,UP,10000> mtu 16436 qdisc noqueue 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc pfifo_fast qlen 1000
    link/ether 0c:0f:fe:e0:00:01 brd ff:ff:ff:ff:ff:ff
3: tap0: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc pfifo_fast qlen 500
    link/ether 7a:a8:3f:d4:bb:99 brd ff:ff:ff:ff:ff:ff

This picture shows the current configuration:

NOTE

Usage of tuntap interfaces require that the user has read and write access to the character special device /dev/net/tun.

[edit] Virtual IP point-to-point interface

Virtual IP point-to-point interfaces behavior with UMview is the same as Virtual Ethernet interfaces. The only exception is that with tap interfaces ethernet frames are transferred between interfaces whereas with virtual tun interfaces only IP frames can be read and written by applications from interfaces.

[edit] umbinfmt

Linux kernel provides an extension module that allows to define new executable file formats without the need of recompile the whole kernel. This task is accomplished by an interface in /proc filesystem. What this UMview service module aims is to allow registration of new executable file formats at user-level.

The module works by overlaying a virtual /proc interface onto the same place where the real binfmt_misc /proc interface resides. First of all the umbinfmt module must be loaded into the UMview chain of services. Then umbinfmt virtual filesystem have to be mounted in /proc/sys/fs/binfmt_misc

$ um_add_service umbinfmt.so
umbinfmt init

$ mount -t umbinfmt none /proc/sys/fs/binfmt_misc

$ ls -l /proc/sys/fs/binfmt_misc
--w------- 1 root root 0 Jan  1  1970 register
-rw-r--r-- 1 root root 0 Jan  1  1970 status

Once the interface have been mounted it is possible to register new executable file format by writing a special string like :name:type:offset:magic:mask:interpreter: to /proc/sys/fs/binfmt_misc/register.

 $ echo ':foo:E::foo::/usr/bin/bar:' > /proc/sys/fs/binfmt_misc 

Further details about binfmt_misc linux kernel extension at [1]

[edit] umdev

Devices are seen by processes as special files that are able to process specific I/O control calls as well as normal I/O transfers operations. UMdev is the service module that adds to UMview virtual device support.

Each virtual device is provided by UMdev submodules designed to provide the appropriate set of ioctl. To load new virtual devices UMdev uses mount system call and command. In this way UMdev gives to submodules the ability to define and attach to filesystem special files.

[edit] umdevmbr

This submodule provides the ability to create virtual devices able to manage Master Boot Record (MBR) partition tables. Thus it is possible to mount real hard disk images to be seen as virtual devices accessible for read and write operations at user-level. Withing UMview, with umdev service module loaded it is possible to map a regular file to a special file to get it acting as a block device.

$ hexdump -C test.img
0000000 0000 0000 0000 0000 0000 0000 0000 0000
*
1388000

$ mount -t umdevmbr test.img test_hd

Now it is possible to manage partition table of test_hd with tools like fdisk and others. Once done it is possible to access device and partitions, create new filesystems or do any i/o control operation on them.

$ sfdisk -l test_hd
Disk test_hd: 2 cylinders, 255 heads, 63 sectors/track
Units = cylinders of 8225280 bytes, blocks of 1024 bytes, counting from 0

   Device Boot Start     End   #cyls    #blocks   Id  System
 test_hd1          0+      1       2-     16033+  83  Linux
 test_hd2          0       -       0          0    0  Empty
 test_hd3          0       -       0          0    0  Empty
 test_hd4          0       -       0          0    0  Empty

One primary partition have been created on test_hd. It is possible to make a new filesystem by accessing it as test_hd1.

$ mkfs.ext3 test_hd1
mke2fs 1.40-WIP (14-Nov-2006)
Filesystem label=
OS type: Linux
Block size=1024 (log=0)
Fragment size=1024 (log=0)
4016 inodes, 16032 blocks
801 blocks (5.00%) reserved for the super user
First data block=1
Maximum filesystem blocks=16515072
2 block groups
8192 blocks per group, 8192 fragments per group
2008 inodes per group
Superblock backups stored on blocks: 
        8193

Writing inode tables: done                            
Creating journal (1400 blocks): done
Writing superblocks and filesystem accounting information: done

[edit] umdevramdisk

This submodule of UMdev is used to create virtual ramdisk devices. As ramdisk devices provided optionally by linux this submodule takes a segment of the active system memory and makes it available as a virtual block devices, with the difference that withing umview it is possible to create new virtual ramdisks at user level.

$ um_add_service umdev
$ mount -t umdevramdisk -o size=100M,mbr none test_rd
$ /sbin/mkfs.ext2 test_rd
[...]
$ um_add_service umfuse
$ mount -t umfuseext2 -o rw+ test_rd /tmp/mnt
renzo@rd235:~$ ls /tmp/mnt
lost+found
$

Notice that in the mount options it is possible to specify ramdisk size and if the virtual device has to be able to manage a master boot record. In this case partitions creating will be allowed.

[edit] umdevtap

This module provides virtual tun/tap device interface. Currently under development.

[edit] UMdev test submodules

[edit] umdevnull

The virtual null device similar to linux /dev/null is also available when umdev service module is loaded. As usual a new virtual null device can be attached to filesystem via mount command. Notice that a debug message is emitted for each I/O request to the virtual null device.

$ mount -t umdevnull none null
$ ls -l null
crw------- 0 render render 0, 0 Jan  1  1970 null

$ cat /dev/urandom > null
null_open c 0 0 flag 8001
null_write c 0 0 len 4096
null_write c 0 0 len 4096
[...]
null_write c 0 0 len 4096
null_write c 0 0 len 4096
null_release c 0 0 flag 0

[edit] umdevtrivhd

This submodule is a simple example of ramdisk implemented as a character device. Once mounted a new special file representing the virutal device it is possible to make usual I/O operations like it was a real character device, up to 64 kilobytes.

$ mount -t umdevtrivhd none chardev
$ dd if=/dev/urandom of=chardev
129+0 records in
128+0 records out
65536 bytes (66 kB) copied, 0.165209 seconds, 397 kB/s

$ cat chardev | md5sum
fe09c11f6a9d9e8d55fc7623ef026798

$ dd if=chardev of=chardev_content
128+0 records in
128+0 records out
65536 bytes (66 kB) copied, 0.17301 seconds, 379 kB/s

$ md5sum chardev_content
fe09c11f6a9d9e8d55fc7623ef026798

[edit] umfuse

[edit] Overview

Adds to UMview virtual filesystems support. The name UMfuse comes from FUSE (Filesystem in userspace). The idea behind FUSE is the implementation of filesystem support in userspace. A filesystem implementation for FUSE is just a program that uses a specific interface provided by the FUSE library. When a filesystem implemented via FUSE is mounted every action to that filesystem is captured by a kernel module (developed for FUSE) and forwarded to the user level filesystem implementation.

UMfuse keeps the same interface of FUSE. Moreover, FUSE modules are source level compatible with UMfuse ones, with the only difference that UMfuse modules are dynamic libraries instead of a program which uses the FUSE library. Thus it is possible to compile a shared object from the same source code and obtain both FUSE and UMfuse modules with minor changes that enable UMfuse modules to manage several mounted filesystem at a time.

[edit] Usage

As usual the appropriate service module must be loaded into the UMview chain of services.

$ um_add_service umfuse

From now on every mount request starting with a umfuse prefix is forwarded to UMfuse that loads the appropriate library. The little example below shows how it is possible to mount an ext2 filesystem within a disk image mounted as a virtual block device.

$ mount -t umdevmbr hd_image.img /dev/disk

$ sfdisk -l /dev/disk
Disk /dev/disk: 2 cylinders, 255 heads, 63 sectors/track
Units = cylinders of 8225280 bytes, blocks of 1024 bytes, counting from 0

   Device Boot Start     End   #cyls    #blocks   Id  System
/dev/disk1          0+      1       2-     16033+  83  Linux

$ mount -t umfuseext2 -o rw+ /dev/disk1 /mnt
$ ls /mnt
drwx------ 2 render render 12288 Jan 28 19:42 lost+found

NOTES

• UMfuse supports two access control methods to the mounted filesystems. Default method known as Omnipotent Mode gives no restrictions to filesystem access: everything that is permitted by the UMfuse filesystem implementation is permitted to the user.

• The other access method is called Human Mode. When working in this mode (enabled via mount options) a permission check is done before proceeding with system calls on the filesystem. Default user and group IDs are those of the user running UMview but they can be overridden using uid and gid at mount time.

$ mount -t umfuseext2 -o human,rw+ /dev/disk1 mnt/
UmFUSE Human mode

[edit] viewfs

ViewFS is a module (still under development) that supports filesystem reorganization. Its main features are:

• Possibility to hide files, directories and hierarchies.
• Moving files and directory without affecting the real underlying filesystem
• Permissions redefinition
• Copy-on-write access to files, and directories to allow write access to read-only entities.
• Merging of real and virtual directories.

With ViewFS allow the user to give to processes a new view of the filesystem that is made of some kind of patchwork of tiles taken from existing filesystems. Possible applications are unlimited since almost everyting in linux operating system can be represented via filesystem interface.