Traditionally, UML has had the following design

• each UML process gets a process on the host
• there is a special thread, the tracing thread, which does system call tracing on the UML processes
• the tracing thread nullified system calls, and caused the process to enter the UML kernel, which is mapped into the upper part of its address space

This was forced by the limited support for UML in Linux and has a number of problems

• The UML kernel is present in the address space of each of its processes, and, by default, is writeable. This is obviously a security problem, since, with write access to kernel data, a process can break out to the host. UML's 'jail' mode fixes this problem by making UML data readonly while a process is running, but this imposes a huge performance penalty. Also, the kernel is still there, and can be read, so this isn't acceptable for honeypots, since a bad guy can easily tell that the system is a UML.
• UML uses signals to force control to the UML kernel during a system call or interrupt. Signal delivery and return are slow, and impose a noticable performance hit.

During the fall of 2002, I started fixing these problems by adding support in the host Linux for features that would solve these problems. The result is now stable, and is being used by a number of people with good results.

In short, the changes cause the UML kernel to run in an entirely different host address space from its processes. This solves the security and honeypot fingerprinting problems by making the UML kernel totally inaccessible to UML processes. Their address spaces are identical to what they would be on the host. This also provides a noticable speedup by eliminating the signal delivery that used to happen for every UML system call.

The old mode is now called 'tt mode', for Tracing Thread, and the new mode is called 'skas mode', for Separate Kernel Address Space.

This is simple - you shouldn't really notice any difference, except for performance. Inside UML, skas mode causes no changes in functionality. For most uses, you should see a noticable improvement in performance. My favorite benchmark, a kernel build, is almost twice as fast with skas mode as with tt mode, and is within 30% of the host's time. Bill Stearns saw a script's running time drop from ~50 seconds to ~14 seconds, almost a quadrupling in speed.

You will notice some differences on the host. If you run ps, you will notice only four processes per UML rather than the dozens that you see in tt mode. They are

• The UML kernel thread, which runs in the separate kernel address space, executes kernel code, and does system call interception on UML processes
• The UML userspace thread, which runs all UML process code and switches between host address spaces on each UML context switch
• The ubd driver asynchronous IO thread
• The write SIGIO emulation thread

If you are running many UMLs on the host, and you convert them over to skas mode, you will also notice a large reduction in the host load. The UML server that I am most familiar with, which runs 25-30 UMLs at any given time, reduced its typical load average from 2 - 5 with tt mode to .1 - .5 with skas mode.

I know of only one bug in the current skas patch, which only affects running nested UMLs as far as I know. I have been running the skas3 patch continuously since the fall with no problems. Other people have, as well, and I've heard of no problems from them. It's SMP-safe, and it's running stably on SMP hosts.

There is going to be a skas4 patch at some point. There will be no real functional changes. The bug mentioned above will be fixed, and a performance tweak or two will be added.

The major change will be the interface to the new stuff. Currently, new address spaces are created by opening /proc/mm, and they are modified by writing to the returned file descriptor. Linus hates this interface (and I wasn't very fond of it, either). After some discussion, he proposed adding two new system calls, one which creates new address spaces, and another which executes an arbitrary system call in the context of one of these address spaces.

The skas4 patch will implement these new system calls, and UML will use them at that point. After that, when the patch has had some testing, I will think about how and when to get it into the main kernel pools.